March 16, 2007 - 10:15 UTC - Tags: javascript security sql injection
I was looking through my log and found a referer entry where somone had searched google with the search term "javascript+validation+to+avoid+SQL+injection". It seems some developers still don't understand that trying to lock up an application on the client side using javascript is impossible. It is like trying to avoid burglaries to your home by locking the doors to the homes of every thief around.
Some example techniques for circumventing javascript validation are:
There is no client side security in web applications. _Client side_ javascript validation is purely cosmetic. It helps make the application more user friendly, and avoids stressing the server with erronous data from users without evil intentions. _Client side_ javascript validation has nothing to do with security.
Update 2010-05-30: There are now several frameworks that run javascript on the serverside, and in this scenario the search may be valid. I suggest though that you include the framework name in your search. And of course remember to do the validation server side. But actually validation is not the correct way to avoid sql-injection. You avoid it by escaping the data before sticking it in the query. See "Why input validation is not the solution for avoiding SQL injection and XSS" and part one and two of the security craftsman series.
Some example techniques for circumventing javascript validation are:
- disabling javascript in your browser
- Changing the data using a proxy
- Changing the data using a browser plugin (e.g. Firefox: Live HTTP headers)
There is no client side security in web applications. _Client side_ javascript validation is purely cosmetic. It helps make the application more user friendly, and avoids stressing the server with erronous data from users without evil intentions. _Client side_ javascript validation has nothing to do with security.
Update 2010-05-30: There are now several frameworks that run javascript on the serverside, and in this scenario the search may be valid. I suggest though that you include the framework name in your search. And of course remember to do the validation server side. But actually validation is not the correct way to avoid sql-injection. You avoid it by escaping the data before sticking it in the query. See "Why input validation is not the solution for avoiding SQL injection and XSS" and part one and two of the security craftsman series.
May 10, 2008 - 23:18 UTC
Brat
But...
No arguements. But your point "to avoid stressing the server with erronous (sic) data from users without evil intentions" is enough reason to enable JS validation for a wide variety of issues. No doubt additional checking needs to be done on the server, but don't automatically assume that someone searching for a leg up on JS validation code is an idiot.
May 11, 2008 - 13:47 UTC
Re: But...
I never said you shouldn't use javascript validation. And I never called the person in question an idiot. And I'm sorry if you feel offended. But my only point was, you cannot use javascript validation to lock down you application. It has to be done server side. And as for the person in question searching for a leg up on JS validation, there is no way you can avoid SQL injection from javascript unless your application uses javascript server side (which at least one java-framework does). But in most applications that is impossible to achieve.
January 5, 2009 - 08:56 UTC
Server Side Validation is a must
I agree with the author, that javascript validation is just merely cosmetic and actually cannot avoid SQL injection. Server side validation is a must in this context.
May 11, 2009 - 12:01 UTC
\'
evil \'ex\'
December 21, 2009 - 01:48 UTC
Nah Uhhh!
Sorry to resuscitate this thread, but I'm looking for exactly that for mobile programming, webOS (Palm) in particular which is written in entirely JS.So something like magicquotes would be GREAT for javascript. I'll scour elsewhere for the help, but here's my 2c.
June 1, 2010 - 23:06 UTC
At the time of writing almost no serverside frameworks were written using javascript. Allthough lately more and more frameworks have been appearing. So yes, this post is a little dated.
Instead of searching for the above though, I would recommend searching for "avoiding sql injection in <framework>" instead.
Instead of searching for the above though, I would recommend searching for "avoiding sql injection in <framework>" instead.
June 1, 2010 - 23:15 UTC
Oh, and just to be clear - "magicquotes" is an escaping function, not a validation function. See the update to the post.
October 13, 2010 - 21:28 UTC
Parameterization is the answer to SQL Injection. If user entries are passed as parameters to sp_executesql, and not embedded in the query command itself, the user entries are not executed as part of the command. No escaping required.
http://www.sommarskog.se/dynamic_sql.html#SQL_injection
http://www.sommarskog.se/dynamic_sql.html#SQL_injection
June 15, 2011 - 05:39 UTC
dafasf
About Erlend
Security guy with some thoughts on secure development.
Tag cloud
Categories
Blogroll
