- Topics Mentioned
- Certification(s):
- Certified Ethical Hacker
- Software:
- SQL Server 2008
Watch these Ethical Hacking videos, and you’ll understand skills like network sniffing, social engineering, distributed DoS, and more. With these tactics of ethical hacking you’ll learn security techniques through the mind of an attacker.
Transcription
Sometimes you may want to actually stealth, or change a little bit of how you’re doing things to obscure the attack, or to thwart any kind of intermediate protection. Instead of just typing spaces into the URL, you might use percent two zero, or some escape codes. You saw the use, actually, of always true statements. One equals one, or A equals A, or parameter name equals parameter name. That’s always going to be the same. Occasionally, you can use comment fields to actually obscure the attack. You’ll just stick a comment at the end of a line of SQL code, because maybe the SQL server is not expecting that. You are using spaces and quotes, trying to escape those or use those to hide the attack.
SQL Injection Code Obfuscation
Those are all really common attack methods for SQL injection code obfuscation, if you will. I think that’s the best way to say it. You’re trying to obfuscate the fact that you’re attacking the SQL server from the web app and the web server, so that this command is sent straight into the SQL database without any scrubbing or analysis.
Why do SQL Attacks Work?
Why do SQL attacks work? I hear this all the time. Ultimately, it comes down to thinking about how this stuff works. The web front end is trusted by the database. The database trusts anything coming from the web front end and you really have two root causes in all this.
No Sanitization
First of all, the most obvious one that we’ve talked about a couple of times here is no sanitization. The web front end and the web app are not checking for SQL code in the parameters. If they’re expecting a username in the form of an email name, mikedan@example.com, and they receive mikedan@example.com semicolon drop table users, then the web front end some component of it, whether it’s a specific security module or a part of the web server or a part of the web app, or maybe all of those things should be looking for that kind of attack.
They should be looking for that kind of, “I don’t expect this here. Maybe I should get rid of it, or maybe I should reject the connection entirely, or maybe I should go ring a bell for an administrator to come by.” Removing it entirely is this concept of sanitization. It means looking at it and saying, “OK, I’ll just delete everything that shouldn’t be in this field. If there’s only letters, numbers and an ‘@’ symbol here, and I see a semicolon, I’m going to delete the semicolon. Or, I’m going to delete the semicolon and everything after it.”
Least Privilege
That is the most common violation. Another root cause, here, is the violation of the principle of least privilege. The principle of least privilege, you probably remember, is the concept that the connection, or the security context here, should do the minimum amount of work necessary, or have the minimal amount of privilege necessary to complete whatever the job is.
The fact that the web front end has a highly privileged connection to the database, (not the user context, not even a typical user context, or even a slightly privileged user context, but an administrative level or a management level context to the database) is a violation of the principle of lease privilege. It’s usually both of these together that actually combine to enable SQL injection attacks.
Discussion