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

pr0n

[macadamia_harold]

When most people think of malicious injection, they think of SQL injection.

Come on now, considering your audience, you might want to re-think that statement.

Re:pr0n

[spellraiser]

Yeah. Malicious Injection was a pretty good flick. I can't wait for Malicious Injection: The SQL.

My rock-solid solution to the injection problem...

[Anonymous Coward]

...is to replace database storage, xml, and ldap with comma-delimited text files on anonymous ftp. In fact, my last job fired me for gross incompetence because the other programmers were jealous of the simplicity of my solution.

XML Logic Is Flawed

[CowboyBob500]

In his XML example with XPath injection he states that running a certain query can return the entire order history of all customers. That may be true, but if the application is returning an XML document containing the entire order history of all customers for each customer request before running an XPath query, then I think the application has more problems than being vulnerable to XPath injection.

Bob

Validate this

[gigne]

FTA
RE: validating input fields...

To be completely thorough, a developer should set up both white- and blacklists in order to cover all bases.

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

[thsths]

>> To be completely thorough, a developer should set up both white- and blacklists in order to cover all bases.
> 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.

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.

Re:It may sound trite, but...

[bdigit]

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

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.

Re:Ignorance

[bluebox_rob]

I think you're right - as long as you are sure that you know what's going to be done with the data after its been written away to your database. You might have your escaping/quoting routine solidly implemented for all inputs to your system, but the trainee down the hall who writes the reporting application that parses the table once a month might not be so savvy - the cunningly crafted SQL injection attack that your quoting has preserved and saved away into the db could wreak havoc when it gets read out again at the other end. The same goes for any HTML/XML that has been saved away, and then gets blindly written out by a web developer on the Order Summary page, or merged into some larger XML document without proper checks.

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.