Slashdot Mirror
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."
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.
Push Button, Receive Bacon
Shell scripts have been vulnerable to similar "injection" exploits since the invention of CGI.
From TFA:
Seems simple enough, but it's amazing how often this is ignored or implemented badly.
I hear there's rumors on the Slashdots
...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.
"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!
Overuse of the Pumping Lemma causes blindness
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
Listen to my latest album here
I swear that malicious code ejects to my speaker, DVD drawer, printer...and it is funny, NOT!
Help end the use of Sigs. Tomorrow
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.
Signature v3.0, now with 42% less memory usage.
By the looks of the server, I would say DOS attacks are more common
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.
668: Neighbour of the Beast
Have we lost our Sanity already? Any user input should be scrubbed sanitized and checked before using it for security and making sure it won't break your application because of the expected input.
-- Brought to you by Carl's JR
Never heard of the term "malicious injection". All these attacks would fall under the category of "Code Injection" and all code injection attacks could be prevented with diligent Input Validation. --Ram ------ "All problems in computer science can be solved by another level of indirection" -Butler Lampson
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
RichM
Data Center Knowledge
"It's not just for breakfast anymore."
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
And then you hoped that the users do not manage to insert commas or newlines into your input fields?
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.
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 that has already thought about this sort of thing.
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.
I choose to remain celibate, like my father and his father before him.
FTA: ...
> Many people mistakenly think that they are safe from malicious code injection attacks because they have firewalls or SSL encryption.
> While establishing a list of "bad" input values that should be blocked (a blacklist) may seem like an appropriate first step, this approach is extremely limited.
I laughed at these two sentences. Are there really people who need to be told this?
Evidently, the key to understanding recursion is to begin by understanding recursion. The rest is easy.
Did anyone else just get an image of a guy running around with a syringe laughing maniacally?
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
Each value was put in "quotes"...
I wonder how many AJAX apps have "injection" problems? If developers aren't properly validating the inputs from xmlhttprequest on the server side there's potential for mischief.
Was your previous employer Diebold by any chance?
Don't let your apps access your DB with global permissions.
Obviously make sure data is scrubbed prior to putting it anywhere near a query, but make sure you have an account which can only read, an account which can only write/update tables, and a final one which can delete records in tables.
The end result is that even if an ingenious user finds a way to get a DROP statement past your scrubbing, they won't be able to do anything useful in most cases since the account running the query only has permission to read. As for deleting tables, they won't have permissions to do that in any instance.
How many people can read hex if only you and dead people can read hex?
Comment removed based on user account deletion
Developers Developers Developers!
If you develop software that follows the usual layered model (web, business, persistence), you have code in place to isolate the web bit from the database bit. MS tools sort of shortcut the web/database bit, making it easier to exploit what's in the database.
Hope this helps.
668: Neighbour of the Beast
I agree completely. I failed to express this idea in my original post. I apologize.
668: Neighbour of the Beast
It is well known amongst the more experienced software developers out there that all user input to ANY software system should be considered suspect and therefore must be checked for invalid inputs, boundary, and special cases. The solution has been around for decades, but it is really surprising how many developers out there have NOT heard of regular expressions or do not know how to properly use them. There are some cases, usually when widely variant free-form input is required, that are difficult to use with regular expresssions, but for the most part they have proven to be remarkably effective in my own experience and I use them regularly (pun intended) in my website and application development. If you have not gotten in on the regular expression game then consider picking up the O'Reilly Mastering Regular Expressions book or visiting Regular-Expressions.info before building your next project. The project you save might be your own!
I may have had my head in the embedded world for too long recently,
and not be up to date on the latest web programming... but...
Who the hell puts anything code related (and count SQL in this)
into text that a user can see?
Collect variables, validate them on the client side,
revalidate on the server side, and on the server side form the SQL or
whatever. Code related to operating on data belongs on the server
side exclusively -- thats the model. Or at least it used to be.
What kind of dumbass puts sql into the source of the page? WTF?
``Malicious Injection It's Not Just For SQL Anymore''
Malicious injection has never been just for SQL. Format string vulnerabilities (where format strings are passed into a program from untrustworthy sources), cross-site scripting vulnerabilities, and many other injection vulnerabilities have existed for a long time, probably longer than SQL injection vulnerabilities have.
Please correct me if I got my facts wrong.
... I'm not quite satisfied with the preventative measures. While input validation helps reduce the number of input validation mistakes, disallowing all meta/control characters in input, may leave a pretty limited application. I would combine input validation with proper character escaping. For SQL, use prepared statements. LDAP, escape all meta characters (,|,* etc. For XML, escape Xpath meta characters.
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.
Please correct me if I got my facts wrong.
Both are not necessarily unrelated. Guess what picture most often shows up at sites vulnerable to SQL injection that happen to be linked from Slashdot...
Hint: it's not a photo of the vulnerable server.
No matter what sort of input devide you use, does the following not seem to hold true:
Lets say you are running a simple capture of FName,LName,Address,City,St,Zip, let each be an input to a PHP Script beased on a web form.
Your SQl statement will consist of the following in the PHP Script: .= "values($FName,$LName,$Address,$City,$State,$Zip)" ;
$Query = "insert into NewContact (Firstname,Lastname,Address,City,State,zip)";
$Query
Now scrubbed or unscrubbed how can this insert result in anything other then bad data in the table? Even supposing you tried to write an entire script in say the address field, how can it possibly be executed? Does not "values" make a one to one correlation to the input mechanism? I have always believed, that anything in the "values" parens is only validated for data type correctness, ie: string -v- number etc and not if it a properly formatted query.
Hey KID! Yeah you, get the fuck off my lawn!
So far everyone seems to be focusing on "input" and forgetting about "output", or even mixing the two.
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).
Use sp_execsql rather than EXEC to create parameterised stored procedures on the fly rather than concatenating within the procedure - a poor example, but it's easy to understand:
e.g.
CREATE PROCEDURE SearchCompanies
@CustomerName nvarchar(100),
@ShowDeleted int
AS
DECLARE @Query nvarchar(4000)
SET @Query = 'SELECT * FROM dbo.Customers WHERE CustomerName = @CustomerName'
IF @ShowDeleted
BEGIN
SET @Query = @Query + ' AND Deleted = 1'
END
EXEC sp_execsql @Query, N'@CustomerName nvarchar(100)', @CustomerName
as long as i get a sweet after i dont care
Positive matching is much easier to code, test, and eliminate maliciousness. It's finite. This is a good thing.
Negative matching is relatively infinite. Negative matching is why most spam filters can't stop spam reliably. Blacklists collapse under their own weight.