Slashdot Log In
Malicious Injection — It's Not Just For SQL Anymore
Posted by
ScuttleMonkey
on Wed Nov 22, 2006 02:51 PM
from the injections-that-aren't-fun dept.
from the injections-that-aren't-fun dept.
nywanna writes "When most people think of malicious injection, they think of SQL injection. The fact is, if you are using XML documents or an LDAP directory, you are just as vulnerable to a malicious injection as you would be using SQL. Bryan Sullivan looks at the different types of malicious code injections and examines the very basics of preventing these injections."
Related Stories
[+]
IT: How Prevalent Are SQL Injection Vulnerabilities? 245 comments
Krishna Dagli writes to tell us of an investigation, by Michael Sutton, attempting to get an estimate of how widespread SQL-injection vulnerabilities are among Web sites. Sutton made clever use of the Google API to turn up candidate vulnerable sites. You might quibble with his methodology (some posters on the blog site do), but he found that around 11% of sites are potentially vulnerable to SQL injection attacks. He believes the causes for this somewhat alarming situation include development texts that teach programmers insecure SQL syntax, and point-and-click tools that allow the untrained to put up database-backed sites.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
pr0n (Score:5, Funny)
Come on now, considering your audience, you might want to re-think that statement.
Re:pr0n (Score:5, Funny)
Yeah. Malicious Injection was a pretty good flick. I can't wait for Malicious Injection: The SQL.
Parent
Re: (Score:3, Funny)
Available soon on VHS, DVD and ODBC...
Re: (Score:3, Insightful)
This has been true since the dawn of programming. NEVER trust the user. Oh before it was just entering text when the program expected an integer, or a negative value when it expected a positive etc. Now we don't get "? Redo from start" errors that crash the BASIC programs. But it's essentially the same thing. Never expect the user will cooperate with the program. Especially a program that is available to potentially
Old news (Score:4, Insightful)
More old news (Score:4, Insightful)
From TFA:
Seems simple enough, but it's amazing how often this is ignored or implemented badly.
Parent
Re:More old news (Score:4, Informative)
If your parameter is a VALUE, it must remain a VALUE when you compose a command and proper escaping is the correct, reliable way.
Validating input may be helpful as another layer of security, but it's not the "only right way", it's not even the *right* way (in most cases).
Parent
Re:More old news (Score:4, Informative)
Here are mine that aren't garbage:
> 1) Use stored procedures!!!!!!!
"EXEC dbo.stored_procedure 'Oops'; DROP DATABASE foo; --'"
> 2) escape your escape characters. i.e. in most statments a "'" is stored as "\'" so escape the \ so its stored as "\\'", it will invalidate the SQL statment because SQL will read it as "\'" instead of just "'"
Not sure what you're talking about, but a literal apostrophe is quoted by doubling it in SQL. ' -> ''. However, don't quote -- you'll get it wrong. Use a proper mechanism instead, like prepared statements.
> 2.5) an alternate to escaping characters is to just strip characters unnecessary to be passed with your stored procedure. i.e. strip all quotes, strip all double quotes, strip all equals signs, bash signs, etc.
That's a great idea, until you need to store unicode or have a customer named "O'Reilly".
> 3) Do not send SQL parameters to your page in GET statements!!!!!! Either use session variables or POST statements, session variables are best.
Right, there's no way anyone can see hidden form fields! They're magical! (Also, session variables aren't "best". If you find the need to store SQL in a variable, your program is terribly designed and you need to rethink it. In this day and age of stored procedures and ORMs, you probably shouldn't have ANY SQL in your code.)
4) You should be secure, but if your not comfortable doing that, then provide additional validation.
Always validate -- it saves work later. If a user types 2-1234 as his phone number, and you store that, you won't be able to call him later, completely defeating the purpose of asking him for the data.
If you're not sure that you can remember to validate everything, use a language that taints incoming data and kills the program when you use it. In perl, turning on taint mode will prevent the common pattern of:
my $value = CGI->param('foo');
$dbh->do("SELECT * FROM foo WHERE bar = $value");
and even:
$sth = $dbh->prepare('SELECT * FROM foo WHERE bar = ?');
$sth->execute($value);
Since you didn't validate $value, you can't use it (correctly or incorrectly).
Hope this helps.
Parent
Re:More old news (Score:4, Informative)
I'd also like to add the PHP website has a great little artical on how to eliminate SQL Injection in php code:
Here is their artical [php.net]
Just make sure you have PHP updated because of the recent vulnerabilities in htmlentities() and htmlspecialchars() functions as noted here [iss.net]
Parent
My rock-solid solution to the injection problem... (Score:5, Funny)
XML Logic Is Flawed (Score:5, Informative)
Bob
Re:XML Logic Is Flawed (Score:4, Insightful)
Parent
Re:XML Logic Is Flawed (Score:4, Insightful)
Bob
Parent
Validate this (Score:4, Insightful)
RE: validating input fields...
I can't help but feel that most developers have at least a little common sense and do something along those lines anyway.
I often write little validate_input(char *string, char *format) that checks all input string from a user are simple, but more often than not very effective. How is this any different from using white and black lists. Any coder worth their salt would do something to stop malicious input, but no one in completely infallible.
Security of anything in this world is near on impossible. Hackers will get around anything given time.
Re:Validate this (Score:5, Informative)
> I can't help but feel that most developers have at least a little common sense and do something along those lines anyway.
I hope that most developers have the common sense to take the correct approach: avoid injection problems by proper quoting! There is no need to validate the data, you just have to make sure that it stays data when you parse it on. Just use the proper library functions, and you will be fine (especially if you use hex encoding
White lists are a good idea if you don't trust you quoting, or if you need to verify the input for another reason. Black lists are most certainly not a good idea. Just imagine that the web shop tries to sell a product called "Selecta[tm]", but you block all attempts to buy it because it matches your black word "SELECT"
P.S.: Anybody with an apostrophe in their name naturally develops an unsatisfiable urge to kill web programmers.
Parent
It may sound trite, but... (Score:4, Interesting)
I recently attended a Microsoft-sponsored seminar on web site security at the DeVry Institute in Decatur, GA.
One of the speakers was a man from SPI Dynamics (sorry, forgot his name). He demonstrated how Microsoft's tools make it very easy to expose a database to the web, but how the same tools make exploiting the database very easy. He demonstrated an application that used SQL injection to first reverse-engineer the schema of an exposed database, and then the data in the database. It was quite a revelation.
Re:It may sound trite, but... (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
If you only knew the POWER of languages (Score:4, Informative)
Heh, remember when we had binary file formats and protocols, fixed-length fields (didn't need delimiters), and there was no parsing or worrying about "escaping" data? We didn't have these problems.
Anyway, I like this article because it admits that whitelists are better than blacklists. You have to validate data: make sure it is known to be non-harmful, rather than looking for whatever problems that you have imagined so far. You'll never guess all the things that can go wrong; you just know what is right.
Phishers like frame injections (Score:5, Interesting)
Defensive Programming (Score:3, Funny)
Email header injection attack (Score:5, Interesting)
A webmaster hosts a contact form on his website that allows users to fill out a form to contact him. He allows the user to specify a subject and a message but the recipient is hard coded to webmaster@example.com.
The message ends up looking like this:
Where $subject and $message are captured from the user on the website.If the $subject is not properly sanitized, a bot could submit it with a new line in it and be able to start a new line in the headers of the email. That new line could be, for example, a large CC list of people to spam with his message:
Which is why I would suggest using a contact form such as the one that I have written [ostermiller.org] that has already thought about this sort of thing.
Wash it before you eat it (Score:4, Interesting)
It's a simple matter of hygiene:
Wash it before you eat it.
All data read from external sources must be validated before being used. In some languages/frameworks this is as hard as nails (ie. I programmed a pretty large web application with only straight CGI programs written in pure Unix/C), in some you have help (Perl with taint), in some it's kinda-sorta-almost not an issue (PHP with Agavi and Creole).
If I had to choose, I would have to say that the middle way, the Perl way, is the best. It does not pretend to solve all your problems for you, even when it can't really. Rather it brings the problems at hand to your attention. Problems surface, fix problems, code gets better.
How I'd do stuff (Score:4, Informative)
Anyway, my suggestion has always been to do something like the following:
Inputs to your program
|||
Corresponding Input filters
|||
Your program
|||
Corresponding Output filters
|||
Outputs from your program
|||
Stuff receiving the outputs
You have a different "input filter" for each class of input so that your program can handle those inputs correctly.
Then you have a different output filter (e.g. SQL bind vars, HTML, XML) so that the stuff receiving your outputs (browser, database, viewer, etc) will handle them correctly.
NEVER do stuff like magic quotes (PHP is one of the worst and most braindead language in popular use) - mixing input and output filtering is so wrong it isn't funny (there are so many other things PHP does wrong that it's almost criminal).
Depending on the circumstances your program could output a single quote ' differently e.g. %27 for a cgi parameter, '' for Oracle data and \' for MySQL data (BTW MySQL is the PHP of databases). So it should be obvious that "one size fits all" doesn't work.
By filtering I mean quoting/encoding sanity checking etc - whatever it takes to get the data in a suitable form (with hopefully minimal data loss/corruption).
Re:Ignorance (Score:4, Insightful)
I suppose an apt analogy would be saying that it's ok to allow infectious material into a building as long as it is first correctly sealed in a bio-safe container - well that's true as long as you're sure the janitor isn't going to open it up later that evening and use it for a cookie jar.
Parent