Malicious Injection — It's Not Just For SQL Anymore

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."

Comments

It may sound trite, but...

[PHAEDRU5]

I blame Microsoft for a lot of these vulnerabilities.

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...

[ArsenneLupin]

Um you can just as easily reverse engineer a mysql or postgresql database through sql injection attacks also. What's your point?

Actually, you can't. There are several things about SQL-Server databases that makes buttfucking them particularly easy:

• Very helpful error messages when attempting to cast strings to integers. This makes it quite easy to read all kinds of errors from the database by doing stuff such as select top 1 convert(int, name) from sysobjects ==> this will give you the name of first table in a nice error message. Other databases, such as mysql will just display "data conversion error", or something similar, without giving you the value.
• Presence of sysobjects and syscolumns tables. Mysql doesn't have these, so there is no easy way to find out the schema.
• Very helpful error messages displayed for group by ... having ... queries, which make it even easier to reverse engineer the schema. So you just sneak in ' having 1=1-- into your query, and out pops the name of the first table and column selected by that statement. Continue with ' group by tbl1.col1 having 1=1-- and out pops another column. Continue adding columns to the group by clause ' group by tbl1.col1,tbl2.col2 having 1=1--- until you've got the whole select part, and when you've got that, it's usually pretty easy to see what needs to be typed to insert a nice piece of ass into the site.
• Possibility to concatenate statements in one query: select id from customer where login='myname' ; update customer set access_level=operator where login='myname' -- and password = 'x'. Mysql and postgresql would barf when fed such a composite statement, whereas SQL server would happily execute it. Such composite statements are essential for most defacements.

Interestingly enough, these vulnerabilities are specific to SQL server. Other Microsoft offerings such as Access (Jet database engine) don't share those:

• No verbose error messages for failed type casts.
• msysobjects table protected in default setup
• Generic error message for bad group by's
• No support for composite statements

So, if you have to use a Microsoft product for your web site, at least use access. Not only is it cheaper, it's also more secure (even if only by chance...)

Phishers like frame injections

[miller60]

Phishers have been known to use frame injections to insert their content into framesets, allowing them to grab login info from within the bank's own web site. It's not nearly as fancy as an SQL injection, but it's sure malicious and quite difficult for victims to recognize.

Email header injection attack

[DeadSea]

Another example of an injection attack allow an attacker to send spam through a contact form that doesn't normally allow the recipient to be specified by the user.

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:

To: webmaster@example.com
From: thewebserver@example.com
Subject: $subject

$message

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:

Buy my weight loss pills!
CC: spammee1@example.com, spammee2@example.com

Which is why I would suggest using a contact form such as the one that I have written that has already thought about this sort of thing.

Wash it before you eat it

[Jhan]

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

[moco]

Then your program needs to be aware of LDAP, SQL, XML and XPATH syntax. Validating user input, as in using regular expressions, will protect you from "FutureML" injection attacks without the need of knowing how "FutureML" will work. In my opinion validating user input IS the correct way of doing it.

Re:More old news

[Anonymous Coward]

IMHO checking what characters you want included in your values (e.g. only digits, only alphanumeric) is much better than trying to weed out characters from a list you can think of. There may be several ways to sneak in unwanted characters due to all the encoding methods being used.

Re:More old news

[Anonymous Coward]

WRONG! The solution is to NOT paste together "programs" (literal or figurative [i.e. SQL]) by combining your stuff and user's stuff!

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.