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

Old news

[kill-1]

Shell scripts have been vulnerable to similar "injection" exploits since the invention of CGI.

More old news

[spellraiser]

From TFA:

The only real way to defend against all malicious code injection attacks is to validate every input from every user.

Seems simple enough, but it's amazing how often this is ignored or implemented badly.

know your system

[jeepee]

"including LDAP injection and XPath injection. While these may not be as well-known to developers, they are already in the hands of hackers, and they should be of concern."

How come they are not well known to developers. Last time I checked if I dont use ldap somewhere along my lines
of codes I'm not in trouble of a ldap injection. Know your systems and check yours inputs! god damn!

Re:know your system

[msobkow]

Personally I have never understood why people try to hack utilities like XPath into database equivalents. But I guess if you learn how to use a hammer and screwdriver, you might well refuse to learn how to handle a wrench because you can "make" things work with the wrong tools.

Or perhaps it's a negative side-effect of object reuse fanatics who don't consider that reusability does not necessarily mean eliminating alternate implementations, but enforcing an appropriately designed and narrowed interface instead of specific implementations.

Imagine a rich reuse library that included not just default implementations, but specialized implementations that took advantage of particular tools and technologies to tweak performance, scalability, security, and reliability. ie. Instead of a generic JDBC connection with DbIO objects and methods, you could have the generic interface with specific implementations for Sybase ASE, DB/2 UDB, Oracle, PostgreSQL, SQLServer, etc. Some might not even use JDBC behind the interface. Some might rely on stored procs, others might rely on product-specific features like PostgreSQL table inheritance.

In any case, I'm reasonably certain such generic interface implementations would be much less vulnerable to injections, because even if the code were sloppy, the attacker would have to know which implementation they're attacking, not just which technology.

Personally I ALWAYS validate and quote data appropriately. A couple decades of database, systems, applications, and distributed software development teaches painful lessons through late night and weekend debugs.

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:Seriously

[Dunbal]

Any user input should be scrubbed sanitized and checked before using it

      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 malicious people out on the internet.

Re:If you only knew the POWER of languages

[Anonymous Coward]

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.

That's not exactly true. There are multiple ways to break parsers by entering bogus data even into fixed length fields. For example, there were several bugs in password and user configuration utilities that took advantage of the parser not correctly handling delimiters embedded in user input. Some even took advantage of the difference in delimiters between the input screen and the backend. For example, web forms don't allow tabs as delimiters, but if the backend uses tabs then it would be problem. This won't occur if a webpage is used to input the data, but it was a trivial matter to write a script that could send the incorrect delimiters.

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?

Re:XML Logic Is Flawed

[Ant P.]

Yeah, but XPath can be done server-side just like SQL.

Ignorance

[Anonymous Coward]

I am really worried about the ignorance of the author (and many script writers, too). There is absolutely no need for validating user inputs, for black or white lists or whatever. The only correct solution of this problem is proper quoting/escaping. Most syntaxes (and this includes SQL, XML, XPath and LDAP) allow the quoting of otherwise significant characters in string literals. For SQL for example, simply double all single quotes in the string and use a pair of quotes around the string. That way, no attacker will ever be able to inject SQL code. Or better, use a proper DB access layer that allows the use of placeholders, like PreparedStatement in Java's JDBC. Then this kind of attack becomes a non-issue.

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.

Re:It may sound trite, but...

[ehrichweiss]

Don't blame them on M$(though I would love to do so myself) they're actually not even the fault of XML or even SQL. Instead they're due to the programming language interface whether that is PHP, REXX, Perl, etc. Look carefully and you'll realize that the languages make it incredibly difficult to delimit certain variables that happen to be assigned things like quotation marks, etc. even with the usage of single and double quotes. For example variable1="this is the first line's message".variable2."and it's going to be hard for the language to figure out what to do about those single quotes if it thinks that single quotes are also delimiters". You can escape the chars but it doesn't make it any better usually. I'm not citing the best of examples but if I dig through some of the code I've had to debug that was written by others, I could show you a nightmare for the coder, much less the security conscious.

Re:XML Logic Is Flawed

[CowboyBob500]

But not over an XML representation of the entire damn customer orders table. That's insane.

Bob

Validation Is Not the Solution

[RAMMS EIN]

There is a solution to injection vulnerabilities, but it's not validation. Sure, if you validate everything properly, you won't suffer from injection vulnerabilities. However, writing the code for that is cumbersome and error-prone, and thus, in practice, we see that values are not or not properly validated.

The solution I've been championing is structured composition. Instead of verifying that the input won't alter the structure of whatever you're composing, you use APIs that ensure that this won't happen. Some examples of this, as well as other bug-eliminating language/library features, can be found in my essay Better Languages for Better Software.