Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Malicious Injection — It's Not Just For SQL Anymore

ScuttleMonkey posted more than 7 years ago | from the injections-that-aren't-fun dept.

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

cancel ×

119 comments

pr0n (4, Funny)

macadamia_harold (947445) | more than 7 years ago | (#16954778)

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 (5, Funny)

spellraiser (764337) | more than 7 years ago | (#16954844)

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

Re:pr0n (1)

DaveM753 (844913) | more than 7 years ago | (#16955240)

Malicious squirrel injections? Dude, that's sick!

Re:pr0n (2, Funny)

Dunbal (464142) | more than 7 years ago | (#16955408)

I can't wait for Malicious Injection: The SQL.

      Available soon on VHS, DVD and ODBC...

Re:pr0n (0)

Anonymous Coward | more than 7 years ago | (#16956412)

I must say, quite a funny and original!

Re:pr0n (1)

ACMENEWSLLC (940904) | more than 7 years ago | (#16956522)

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

That has to be the funniest thing I have heard all day. I can just see that on a T-Shirt.

Re:pr0n (0)

Anonymous Coward | more than 7 years ago | (#16956554)

spellraiser, that comment made me laugh out loud! Thanks for that!

Seriously (1)

drpimp (900837) | more than 7 years ago | (#16955180)

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.

Re:Seriously (2, Insightful)

Dunbal (464142) | more than 7 years ago | (#16955360)

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:Seriously (1)

afidel (530433) | more than 6 years ago | (#16959276)

Yeah a LOT of that article read like CGI-101 from the mid 90's. Hell he even mentioned finger, a program most people who haven't been doing web stuff that long probably don't have a clue about.

Re:Seriously (1, Troll)

deadlinegrunt (520160) | more than 7 years ago | (#16955448)

Oh c'mon and get real - good coding practices went out with C every since we learned we could blame the language instead of the application of it. You aren't trying to say this can affect all the latest languages as well? The mind boggles...

/sarcasm

Re:Seriously (1)

Schraegstrichpunkt (931443) | more than 7 years ago | (#16957846)

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

This statement is almost always wrong. While there are occasionally cases where certain information simply cannot be represented in a particular (poorly-designed) system, most of the time you need to properly encode the data, rather than "checking" it for "dangerousness".

Re:pr0n (0)

Anonymous Coward | more than 7 years ago | (#16956212)

Gotta love the hot beef injection

Re:pr0n (0)

Anonymous Coward | more than 7 years ago | (#16956670)

A.I.D.S = Ass Injected Death Syndrome. Its what I thought

Re:pr0n (0)

Anonymous Coward | more than 7 years ago | (#16957842)

Cue jokes about Steve Ballmar, Malicious Injection and Squirting in 3, 2, 1...

Re:pr0n (1)

ArsenneLupin (766289) | more than 7 years ago | (#16962534)

Cue jokes about Steve Ballmar, Malicious Injection and Squirting in 3, 2, 1...
Although I like Steve's "camp" style, he's a tad old even for my taste.

Sheep and goats (0)

Anonymous Coward | more than 7 years ago | (#16962530)

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

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.

Old news (3, Insightful)

kill-1 (36256) | more than 7 years ago | (#16954806)

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

More old news (3, Insightful)

spellraiser (764337) | more than 7 years ago | (#16954908)

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.

Re:More old news (3, Informative)

Vihai (668734) | more than 7 years ago | (#16955374)

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.

...but unfortunately it's mostly WRONG. In many cases, the real way to defend against injections is to ESCAPE values before composing strings, this is mostly the case with SQL (where prepared queries and the help of a good prepare/execute API is very much helpful) but it's not limited to it.

If your parameter is a VALUE, it must remain a VALUE when you compose a command and proper escaping is the correct, reliable way.

Validating input may be helpful as another layer of security, but it's not the "only right way", it's not even the *right* way (in most cases).

Re:More old news (1, Informative)

Anonymous Coward | more than 7 years ago | (#16955686)

When your value is supposed to be an integer number, for example some itemnumber on the site, checking if it contains only digits (and maybe a minus sign) will not only protect you from runtime errors, it protects you against any possibility of injection at the same time.

Re:More old news (1, Informative)

Anonymous Coward | more than 7 years ago | (#16955940)

That's just one example.

Here's my tips for preventing SQL injection.
1) Use stored procedures!!!!!!!
2) escape your escape characters. i.e. in most statments a "'" is stored as "\'" so escape the \ so its stored as "\\'", it will invalidate the SQL statment because SQL will read it as "\'" instead of just "'"
2.5) an alternate to escaping characters is to just strip characters unnecessary to be passed with your stored procedure. i.e. strip all quotes, strip all double quotes, strip all equals signs, bash signs, etc.
3) Do not send SQL parameters to your page in GET statements!!!!!! Either use session variables or POST statements, session variables are best.
4) You should be secure, but if your not comfortable doing that, then provide additional validation.

Re:More old news (1, Interesting)

Anonymous Coward | more than 7 years ago | (#16956700)

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 (3, Informative)

J0nne (924579) | more than 7 years ago | (#16957178)

3) Do not send SQL parameters to your page in GET statements!!!!!! Either use session variables or POST statements, session variables are best.

Using POST instead of GET doesn't make *any* difference. You can fake a POST request just as easily as a GET request. Please stop telling people that a POST is more secure...

Re:More old news (1)

Alphager (957739) | more than 7 years ago | (#16957232)

3) Do not send SQL parameters to your page in GET statements!!!!!! Either use session variables or POST statements, session variables are best.
You know that POST's can be faked as easily as a GET, right? This hint is a classic example of security by obscurity.

Re:More old news (3, Informative)

jrockway (229604) | more than 7 years ago | (#16957350)

> Here's my tips for preventing SQL injection.

Here are mine that aren't garbage:

> 1) Use stored procedures!!!!!!!

"EXEC dbo.stored_procedure 'Oops'; DROP DATABASE foo; --'"

> 2) escape your escape characters. i.e. in most statments a "'" is stored as "\'" so escape the \ so its stored as "\\'", it will invalidate the SQL statment because SQL will read it as "\'" instead of just "'"

Not sure what you're talking about, but a literal apostrophe is quoted by doubling it in SQL. ' -> ''. However, don't quote -- you'll get it wrong. Use a proper mechanism instead, like prepared statements.

> 2.5) an alternate to escaping characters is to just strip characters unnecessary to be passed with your stored procedure. i.e. strip all quotes, strip all double quotes, strip all equals signs, bash signs, etc.

That's a great idea, until you need to store unicode or have a customer named "O'Reilly".

> 3) Do not send SQL parameters to your page in GET statements!!!!!! Either use session variables or POST statements, session variables are best.

Right, there's no way anyone can see hidden form fields! They're magical! (Also, session variables aren't "best". If you find the need to store SQL in a variable, your program is terribly designed and you need to rethink it. In this day and age of stored procedures and ORMs, you probably shouldn't have ANY SQL in your code.)

4) You should be secure, but if your not comfortable doing that, then provide additional validation.

Always validate -- it saves work later. If a user types 2-1234 as his phone number, and you store that, you won't be able to call him later, completely defeating the purpose of asking him for the data.

If you're not sure that you can remember to validate everything, use a language that taints incoming data and kills the program when you use it. In perl, turning on taint mode will prevent the common pattern of:

my $value = CGI->param('foo');
$dbh->do("SELECT * FROM foo WHERE bar = $value");

and even:

$sth = $dbh->prepare('SELECT * FROM foo WHERE bar = ?');
$sth->execute($value);

Since you didn't validate $value, you can't use it (correctly or incorrectly).

Hope this helps.

Re:More old news (3, Informative)

liquidpele (663430) | more than 7 years ago | (#16959922)

Thank you for typing all that so I didn't have to :)

I'd also like to add the PHP website has a great little artical on how to eliminate SQL Injection in php code:
Here is their artical [php.net]

Just make sure you have PHP updated because of the recent vulnerabilities in htmlentities() and htmlspecialchars() functions as noted here [iss.net]

Re:More old news (2, Informative)

runcible (306937) | more than 7 years ago | (#16961746)

Yeah...PHP.



Don't worry about injection vulnerabilities in LAMP -- just don't forget to use mysql_real_escape_string() and not mysql_escape_string()!



The next rev will no doubt include mysql_really_real_escape_string().

Re:More old news (0)

Anonymous Coward | more than 7 years ago | (#16962128)

As funny as that is, it's excellent advice

Re:More old news (1)

bad-badtz-maru (119524) | more than 7 years ago | (#16957588)


Using bound parameters, as the previous post suggested, is the correct way to mitigate SQL injection.

Re:More old news (1)

Directrix1 (157787) | more than 7 years ago | (#16956252)

Mod this person up. He's absolutely correct. You don't clean your input, you just prepare it for how you intend on working with it.

Re:More old news (3, Informative)

TheRealBurKaZoiD (920500) | more than 7 years ago | (#16960204)

Wrong. For God's sake, you dweeby little junior programmers need to do some research before you open your damn mouths.

Escaping values only brings up new vulnerabilities. In database servers these are known as SQL truncation, and are the byproduct of buffer overruns in system functions (such as QUOTENAME and PATINDEX in T-SQL). These truncation attacks affect even parameterized queries, and the ubiquitous sp_executesql system stored procedure. I won't go into the details. All the info you need is is BOL, so look it up for yourself.

The real problem (again, in database servers) is dynamic SQL. That, and incorrect security permissions (some dbas need to be beaten with a stick), but I'm not here to teach a SQL Administration class. Many, many dynamic SQL statements, because they are only filtering the data set, can be re-written as a non-dynamic SQL stored procedure, but still afforded their dynamic nature. For example, this vulnerable stored procedure:

create proc sp_get_product
@prod varchar(255) = null
as
declare @sql varchar(1000)
set @sql = 'SELECT PRODUCTID, PRODUCTNAME, CATEGORY, PRICE FROM PRODUCTION'
if @prod is not null set @sql = @sql + ' PRODUCTNAME LIKE ''' + @PRODNAME + '''
exec(@sql)

can be re-written to:

create proc sp_get_product
@prod varchar(255) = null
as
select productid, productname, category, price
from product
where productname like coalesce(@prod, productname)

Coalesce returns the first non-null argument in it's argument list. If @prod has a value, the resulting dataset is filtered on it. If @prod is null, then the entire dataset will be returned because productname will filter on it's own value. Only near-infinite where clauses can't be done this way.

Also, production database server accounts should have no access to any database objects. They should only be able to run stored procedures, and that's it.

You're advice about "escaping" values is just as bad as those computer science professors in college that say "re-writing your conditional statements to automatically exclude bad data will eliminate the need to validate the data that makes it through."

Goddammit. Comments (and articles) like this make me so fucking mad.

Re:More old news (0)

Anonymous Coward | more than 7 years ago | (#16955386)

Malicious injection?

CmdrTaco gave me a delicious beef injection last night and finished me off with a dutch rudder

Re:More old news (1)

Kjella (173770) | more than 7 years ago | (#16956598)

Well, the odds are just uneven. Imagine two equally bright guys can think of 50 exploits each of a total of 100. The chances of defending against that attack is 0.5^50 = none. Even if we assume one bright guy who'll think of 90 defenses and a stupid guy thinking of 10 attackes, you'll still only have a 0.9^10 = 35% chance of defending yourself. Good security means doing everything right all the time, something humans aren't particularly good at. Plus, it's not like most coders go into the war battle hardened. They've played around with it, done assignments at school, worked on some closed off development systems and their insecure practises work fine. It would be nice if all coders were excellent, but they aren't.

Re:More old news (2, Interesting)

Anonymous Coward | more than 7 years ago | (#16958170)

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.

My rock-solid solution to the injection problem... (5, Funny)

Anonymous Coward | more than 7 years ago | (#16954960)

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

Re:My rock-solid solution to the injection problem (1)

pe1chl (90186) | more than 7 years ago | (#16955746)

And then you hoped that the users do not manage to insert commas or newlines into your input fields?

He thought of that... (2, Funny)

martinmarv (920771) | more than 7 years ago | (#16957580)

Each value was put in "quotes"...

Re:My rock-solid solution to the injection problem (0)

Anonymous Coward | more than 6 years ago | (#16958718)

Was your previous employer Diebold by any chance?

know your system (2, Insightful)

jeepee (607566) | more than 7 years ago | (#16954986)

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

Try Again (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#16955002)

When I think of malicious injection, I think of more biological things. Malicious code injection is one of the last things that comes to mind.

XML Logic Is Flawed (5, Informative)

CowboyBob500 (580695) | more than 7 years ago | (#16955036)

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

Re:XML Logic Is Flawed (3, Insightful)

Ant P. (974313) | more than 7 years ago | (#16955520)

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

Re:XML Logic Is Flawed (3, Insightful)

CowboyBob500 (580695) | more than 7 years ago | (#16956282)

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

Bob

Re:XML Logic Is Flawed (1, Informative)

Anonymous Coward | more than 7 years ago | (#16956488)

I recommend some therapy at www.thedailywtf.com [thedailywtf.com] The truth is: a lot of insane programs are out there

Re:XML Logic Is Flawed (0)

Anonymous Coward | more than 7 years ago | (#16959692)

Eh? Xpath doesn't mean having an in-memory XML document. There are XML databases (Xindiche or however it's spelt -- the Apache one) that can be queried via Xpath.

The predictable following question is who would use an XML database when there are SQL databases -- well, they're for different types of data. SQL is rigidly structured into columns and tables (with hierarchy through foreign keys of numbers referring to other record Ids), whereas if the data is semi-structured with a taxonomy (multiple paragraphs or tables or lists) then trying to select the first 30 words regardless of structure is something that'd be bloody difficult in SQL but easy via XPath.

Are there any dangerous SQL ejections? (0, Offtopic)

BrentRJones (68067) | more than 7 years ago | (#16955056)

I swear that malicious code ejects to my speaker, DVD drawer, printer...and it is funny, NOT!

Re:Are there any dangerous SQL ejections? (0)

Anonymous Coward | more than 7 years ago | (#16962548)

I swear that malicious code ejects to my speaker, DVD drawer, printer...and it is funny, NOT!
Next time use a handkerchief... What will people think when they'll see those white stains all over your place?

Validate this (4, Insightful)

gigne (990887) | more than 7 years ago | (#16955082)

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 (1)

drinkypoo (153816) | more than 7 years ago | (#16955174)

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.

Maybe most do, but there's been TONS of unvalidated input in programs since the dawn of time and there are no signs that will stop any time soon.

Re:Validate this (4, Informative)

thsths (31372) | more than 7 years ago | (#16955452)

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

Re:Validate this (1)

pe1chl (90186) | more than 7 years ago | (#16955830)

I hope that most developers have the common sense to take the correct approach: avoid injection problems by proper quoting

And I would hope that developers (especially language developers) would realize that the really correct approach is not to glue SQL statements together from fixed strings and quoted arguments, but to use prepared statements with placeholders and arguments passed as a list.

This is no problem with languages providing a full API to SQL, but in kludges like PHP it has been difficult for a long time. That is why you see so many SQL injection problems in PHP pages. It is a problem of the language, which lures naive programmers into buggy solutions.

Re:Validate this (1)

Dragonslicer (991472) | more than 7 years ago | (#16956086)

PHP has had a good API that includes support for prepared statements for a while now.

http://www.php.net/pdo [php.net]

Re:Validate this (1)

joebp (528430) | more than 7 years ago | (#16957092)

Now consider why a language who's sole use is doing this sort of thing didn't have it from the start. The answer is that PHP was not designed with security in mind. It was designed to be easy to use.

Re:Validate this (1)

bad-badtz-maru (119524) | more than 7 years ago | (#16957716)


The reason it didn't have it from the start is probably due to the same factors that led to nearly all of the major exploit classes... no one thought of the issue that resulted in the exploits. If we start way back in the beginning ("Smashing the Stack for Fun and Profit") there just wasn't much consideration given to the idea that data could result in malicious code execution.

Re:Validate this (1)

pe1chl (90186) | more than 7 years ago | (#16958372)

I think it wasn't designed. It was started as a toy project for a Personal Home Page.

Re:Validate this (1)

thsths (31372) | more than 7 years ago | (#16957216)

> And I would hope that developers (especially language developers) would realize that the really correct approach is not to glue SQL statements together from fixed strings and quoted arguments

To be fair, the original article is about XPath and LDAP injection. As far as I know, there is no alternative to "brutal" string operations here. Around SQL you have a number of (not nice but) working data binding APIs, but for many new languages you do not have that (yet).

Sometimes you have to use quoting, and you want to make sure that your quoting function is absolutely correct. This is difficult because of encoding, locale, fonts etc. So the best solution is to use the quoting function provided by the API :-)

Re:Validate this (1)

johneee (626549) | more than 7 years ago | (#16957328)

Which is exactly the problem I had in the past with a website I built using Typo3 (which is in general a reasonably good CMS)

The client was having problems editing a certain record in the db, and after much investigation I discovered that any record that had the words "insert into" in it would make the submit form die completely. Annoying to say the least.

I'll leave it to your imaginations as to what kind of web site would have the term "insert into" in news articles so as to leave my client's anonymity remain.

Re:Validate this (1)

daliman (626662) | more than 7 years ago | (#16959762)

So, so true.

Re:Validate this (1)

computational super (740265) | more than 7 years ago | (#16957200)

I can't help but feel that most developers have at least a little common sense and do something along those lines anyway.

If you do it with uncommon sense, though, it can go horribly wrong [thedailywtf.com] ...

I think DOS attacks are more common (1)

genevaroth (685479) | more than 7 years ago | (#16955086)


By the looks of the server, I would say DOS attacks are more common

It may sound trite, but... (3, Interesting)

PHAEDRU5 (213667) | more than 7 years ago | (#16955092)

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... (4, Insightful)

bdigit (132070) | more than 7 years ago | (#16955512)

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

Re:It may sound trite, but... (1)

phorm (591458) | more than 7 years ago | (#16956342)

It think that it's a case of the tools themselves being made to simplify things, or to easily expose data, but often being overused or improperly used so that too much data is exposed, or it is exposed to the wrong people.

I think the point is that... (2, Informative)

PHAEDRU5 (213667) | more than 7 years ago | (#16960756)

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.

Re:It may sound trite, but... (1)

HAL9000_mirror (1029222) | more than 7 years ago | (#16955674)

As much as I would like to blame M$, Code Injection attacks have nothing to do with M$ or ANY operating system for that matter. It is the application developers' laziness to not validate input from external entity. Many attacks could be almost completely avoided with input validation including buffer overflow, cross-site scripting...

--Ram

I agree (1)

PHAEDRU5 (213667) | more than 7 years ago | (#16960800)

I agree completely. I failed to express this idea in my original post. I apologize.

Re:It may sound trite, but... (2, Insightful)

ehrichweiss (706417) | more than 7 years ago | (#16955884)

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:It may sound trite, but... (-1, Troll)

Anonymous Coward | more than 7 years ago | (#16956388)

Ah, DeVry, a bastion of knowledge, engenuity, and innovation.

Re:It may sound trite, but... (0)

Anonymous Coward | more than 7 years ago | (#16956584)

I blame Microsoft for a lot of these vulnerabilities.

Don't forget George Bush and global warming. Try to keep all your bogeymen together, and put them back in your toy chest when you're done playing with them.

Call it code injection (1)

HAL9000_mirror (1029222) | more than 7 years ago | (#16955216)

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

Re:Call it code injection (1)

pseudorand (603231) | more than 7 years ago | (#16955392)

> All problems in computer science can be solved by another level of indirection" -Butler Lampson

Except, of course, the problem of too many levels of indirection makeing either coding or running the code to slow.

Re:Call it code injection (1)

Gospodin (547743) | more than 7 years ago | (#16957880)

Except, of course, the problem of too many levels of indirection makeing either coding or running the code to slow.

But that's not a problem in computer science - it's a problem in software engineering. :P

If you only knew the POWER of languages (3, Informative)

Sloppy (14984) | more than 7 years ago | (#16955276)

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.

Re:If you only knew the POWER of languages (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16955494)

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:If you only knew the POWER of languages (1)

pushf popf (741049) | more than 7 years ago | (#16955622)

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.

No kidding. I remember when everything in the world didn't need to be an "Application Framework" and code was fast and small and reliable and easy to fix.

Phishers like frame injections (4, Interesting)

miller60 (554835) | more than 7 years ago | (#16955458)

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 [netcraft.com] . It's not nearly as fancy as an SQL injection, but it's sure malicious and quite difficult for victims to recognize.

Re:Phishers like frame injections (1)

Phrogman (80473) | more than 7 years ago | (#16955892)

Ah I hadn't thought of this (but then I don't Phish), do Mozilla or IE7 warn the user if they browse an SSL address through frames? If not then they should...

Defensive Programming (3, Funny)

davidwr (791652) | more than 7 years ago | (#16955466)

"It's not just for breakfast anymore."

Ignorance (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16955772)

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 (1)

pe1chl (90186) | more than 7 years ago | (#16956096)

I would call your second solution the only correct solution, and the first one a dangerous solution in the hands of the naive implementer.
One should only attempt that when the language provides a quoting function like addslashes in php, so that you at least can leave the task of identifying the quotation marks to someone who knows a bit about thinks like UTF and other tricks to hide them.

Re:Ignorance (2, Interesting)

moco (222985) | more than 7 years ago | (#16956472)

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:Ignorance (4, Insightful)

bluebox_rob (948307) | more than 7 years ago | (#16956506)

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:Ignorance (1)

CoughDropAddict (40792) | more than 7 years ago | (#16957806)

The only correct solution of this problem is proper quoting/escaping.

In the case of SQL, a much better solution is using bind variables. In addition to being totally invulnerable to injection attacks, they improve the efficiency of your queries (since the database engine can recognize when queries differ only in data, and cache its plan).

Email header injection attack (5, Interesting)

DeadSea (69598) | more than 7 years ago | (#16955910)

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 [ostermiller.org] that has already thought about this sort of thing.

Re:Email header injection attack (1)

pe1chl (90186) | more than 7 years ago | (#16956456)

Of course when you code safety-first, you both will avoid the use of variables in the headers (i.e. do not make the subject variable) and the parsing of the headers by the MTA (i.e. give the destination address to sendmail instead of calling it with the -t flag and find the addresses from the headers).

Re:Email header injection attack (1)

cmburns69 (169686) | more than 7 years ago | (#16958060)

Of course, this isn't a huge issue as most mail protocols don't actually route/deliver mail based on the headers. For example, in the SMTP and ESMTP protocols, there is no differentiation between a "To", "CC", and "BCC" addresses.

Of course, it would make the email look ugly, but it wouldn't actually go to the spammed people.

Wash it before you eat it (3, Interesting)

Jhan (542783) | more than 7 years ago | (#16956242)

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.

Untrusthworthy user shocks millions; news at 11 (1)

Workaphobia (931620) | more than 7 years ago | (#16956278)

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?

Re:Untrusthworthy user shocks millions; news at 11 (1)

GrumpySimon (707671) | more than 6 years ago | (#16959010)

unfortunately yes.

Run away! (1)

TheSpoom (715771) | more than 7 years ago | (#16957118)

Did anyone else just get an image of a guy running around with a syringe laughing maniacally?

What about AJAX injection? (1)

krid (26077) | more than 7 years ago | (#16957854)

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.

Simple solution... (1)

jacksonj04 (800021) | more than 7 years ago | (#16959538)

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.

Developers (1)

Doogzee (765929) | more than 7 years ago | (#16959974)

Developers Developers Developers!

Check All User Input w/Regular Expressions (2, Informative)

CodeBuster (516420) | more than 7 years ago | (#16960948)

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 [amazon.com] book or visiting Regular-Expressions.info [regular-expressions.info] before building your next project. The project you save might be your own!

Bad basic designs? (0)

Anonymous Coward | more than 7 years ago | (#16961692)

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?

It Has Never Been Just For SQL (1)

RAMMS+EIN (578166) | more than 7 years ago | (#16962476)

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

Good article, but... (1)

RatRagout (756522) | more than 7 years ago | (#16962486)

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

Validation Is Not the Solution (2, Insightful)

RAMMS+EIN (578166) | more than 7 years ago | (#16962518)

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 [inglorion.net] .

I fail to see how this CANNOT be avoided! (1)

FlyingGuy (989135) | more than 7 years ago | (#16962580)

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:
$Query = "insert into NewContact (Firstname,Lastname,Address,City,State,zip)";
$Query .= "values($FName,$LName,$Address,$City,$State,$Zip)" ;

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...