Fending off SQL Injection Attacks plus a nice SP to help you along the way
This topic comes up lots of recent and always surprises me that awareness levels are still quite low.
Adrian (thanks Adrian) from DFEEST in Adelaide sent me a link that discusses SQL Injection attacks (this is a universal DB attack); you can find the article at https://www.sitepoint.com/article/sql-injection-attacks-safe. On this site there is a useful SP you can add to your system for general purpose string cleaning…
CREATE FUNCTION dbo.CleanString (@Clean varchar(8000))
RETURNS varchar(8000) AS
BEGIN
set @Clean=REPLACE(@Clean,'''',' '); -- Remove single quote
set @Clean=REPLACE(@Clean,'^',' '); -- Remove caret
set @Clean=REPLACE(@Clean,'#',' '); -- Remove hash
set @Clean=REPLACE(@Clean,'select',' '); -- Remove select
set @Clean=REPLACE(@Clean,'drop',' '); -- Remove drop
set @Clean=REPLACE(@Clean,';',' '); -- Remove semi colon
set @Clean=REPLACE(@Clean,'--',' '); -- Remove double dash
set @Clean=REPLACE(@Clean,'insert',' '); -- Remove insert
set @Clean=REPLACE(@Clean,'delete',' '); -- Remove delete
set @Clean=REPLACE(@Clean,'xp_',' '); -- Remove extended stored procedure prefix
return @Clean;
END
So this plus the following guidance particularly for web apps:-
- validateRequest is on true by default and most cases this should be fine – it raises an error if a form post contains any HTML whatsoever.
- Use HtmlEncode when reflecting any user input back to the browser
- Validate for known good data
- Use ASP.NET Validators – remember these act client side in IE 5 and above but always execute server side so you MUST check “Page.Isvalid()” is true.
- Use Regular expressions to validate – check out https://www.regxlib.com/ for Regular Expression samples. If you hate regex then validate with your own code
- Validate strings in SQL Server with the above stored proc
- Connect your app to the database with the minimum privileges required and ideally just execute rights on the Stored Procs required to get the work done.
Comments
Anonymous
May 31, 2005
Hi - just wondering why, if you're using stored procedures with parameters (which I believed then mitigated the risk of any SQL injection attacks, unless you use something like an EXEC command), you'd need to use the sp you describe?Anonymous
May 31, 2005
http://www.amazon.com/exec/obidos/tg/detail/-/0735621217/103-1374625-4726253?%5Fencoding=UTF8&v=glance
http://www.microsoft.com/learning/syllabi/en-us/2840afinal.mspx
http://adelaide.aspect.edu.au/enrol.asp?courseid=302
http://www.microsoft.com/learning/exams/70-340.asp
http://www.microsoft.com/learning/exams/70-330.aspAnonymous
May 31, 2005
I am very surprised that people are still using string concatenation to build SQL queries. I've always used stored procedures or SQL statements with '?' or '@name' placeholders that are substituted automatically (and safely) via the development platform's Command and Parameter objects. If I encounter any complex problem where the obvious solution is to use string concatenation, I find a better way to structure the query. Please correct me if I am wrong about all this.Anonymous
June 01, 2005
The comment has been removedAnonymous
June 01, 2005
The "Why WSE" link fixed, doh, sorry about that. Alas, the new blog system doesn't allow for long URLs:-( So you can find the article half way down the page or here http://msdn.microsoft.com/webservices/building/wse/default.aspx?pull=/library/en-us/dnwse/html/whywse.asp
The article was written by Benjamin MitchellAnonymous
March 13, 2007
PingBack from http://winblogs.security-feed.com/2005/05/31/fending-off-sql-injection-attacks-plus-a-nice-sp-to-help-you-along-the-way/Anonymous
July 09, 2007
PingBack from http://www.ben-rush.net/blog/PermaLink,guid,dd5a6b96-b8c6-479b-99f0-638c7a3d8a32.aspxAnonymous
June 01, 2009
PingBack from http://paidsurveyshub.info/story.php?id=76382