Malicious Injection — It's Not Just For SQL Anymore 119
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."
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.
Phishers like frame injections (Score:5, Interesting)
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.
Re:Ignorance (Score:2, Interesting)
Re:More old news (Score:1, Interesting)
Re:More old news (Score:2, Interesting)
Forget making quotes illegal (the irish will thank you) and forget trying to second-guess every possible problem by escaping the all the stuff YOU are smart enough to forsee problems with (leaving holes for people smarter than you).
Just ensure that your programs and user inputs never get mixed together. For example, use parameterized SQL. Or put user input into a file and read it, instead of the ever-lame eval("var='"+userinput+"';") type of approach.
Re:It may sound trite, but... (Score:3, Interesting)
Actually, you can't. There are several things about SQL-Server databases that makes buttfucking them particularly easy: