By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,130 Members | 2,141 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,130 IT Pros & Developers. It's quick & easy.

Injection Attack

P: n/a
What is the best way to protect a site against it? Does anyone have a RegEx
to help validate user input?

TIA!
Nov 19 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Usually people use parameterized queries to avoid injection attacks.

If you are taking people's queries and running them directly, you are going
to have a hell of a time finding a regular expression to validate a sql
statement - it is way too complicated. I think you need a parser for that.

"TCORDON" <tc******@hotmail.com> wrote in message
news:Og**************@TK2MSFTNGP10.phx.gbl...
What is the best way to protect a site against it? Does anyone have a
RegEx to help validate user input?

TIA!

Nov 19 '05 #2

P: n/a
If you are connected to SQL Server, create stored procedures. That is the
EASIEST way to protect, as all input will be parsed as text, not as SQL.

Other suggestions:
1. Reduce the amount of text allowed to the max size of the parameter. You
have to do this both in the control and on the server side. This does not
eliminate injection, but it makes it much harder. Consider:

Password; {box here only allows 8 characters - max PWD size}

User enters: ' OR 1=1 --

On a longer field, one could still inject, but this string sent would
obviously not be from your form, so you would automatically reject it.

2. Check for single quotes in a string. They should not be allowed in most
form elements where injection is possible. If you turn a single quote into
two single quotes (necessary for input anyway), before you build the string,
you will reduce your exposure, as well.

string input = txtInput.Text.Replace("'","''");

NOTE: NEVER return the input to the user without HTML encoding. While not
SQL injection, some hacks insert JavaScript into a form to get information.
This can only be done when you return user input without encoding. Do not do
it.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside the box!
*************************************************
"TCORDON" <tc******@hotmail.com> wrote in message
news:Og**************@TK2MSFTNGP10.phx.gbl...
What is the best way to protect a site against it? Does anyone have a
RegEx to help validate user input?

TIA!

Nov 19 '05 #3

P: n/a
There are lots of injection attacks. If you're talking about SQL, then use
parameterized SQL as others have suggsted. If you're talking about cross
site scripting then all data that a user has passed to you that you are going
to render should be HtmlEncode'd. There's also a ViewState injection attack
and you can mitigate against this via enabling the EnableViewStateMac option
in web.config (the default is false). Here are the docs for that:

http://msdn.microsoft.com/library/de...asp?frame=true

-Brock
DevelopMentor
http://staff.develop.com/ballen
What is the best way to protect a site against it? Does anyone have a
RegEx to help validate user input?

TIA!


Nov 19 '05 #4

P: n/a
One regular expression will not combat the wide variety of attacks. There
are several phases to protecting your site:
1. using validation to block some of the attacks and to log them. Fields
that have very strongly patterned data - dates, numbers, phone numbers - all
can be blocked with normal validators like CompareValidator
(Operator=DataTypeCheck) and RegularExpressionValidator (for the phone
number example). Free-form text fields are much harder to validate because
SQL was built upon the English language. So you might block "Drop me off"
because you are looking for the DROP Table command. Certainly, you don't
want to block free-form text that has a single quote because it's so often
used.
ALWAYS use server side validation to detect attacks because the hacker will
turn off javascript to work around any client-side scripts.
2. Neutralize all inputs. Assume the text gets passed your validators. For
SQL Injection, the recommendation is to make sure no SQL statements are
built on your page. Instead, use stored procedures and pass all parameters
using the SQLParameter objects of ADO.NET. Internally ADO.NET prepares all
inputs so they cannot cause an attack. (Effectively, single quotes are
treated as text instead of string delimiters.)
For Cross-site scripting attacks, use HtmlEncode before writing any text
from the user to the web form.
3. Don't allow the user to see exception error messages. Exceptions reveal
juicy information about your site's structure that hackers use to further
attack you. Log all exceptions and give the user a friendly page telling
them that there was an error.

FYI: I am the author of VAM: Visual Input Security
(http://www.peterblum.com/vise/home.aspx), the only full system for blocking
and neutralizing SQL Injection and Cross-site scripting attacks on ASP.NET
web sites. It includes validators that can handle free-form text,
neutralization tools, logging and an auditing feature to confirm all inputs
on your page have defenses.

--- Peter Blum
www.PeterBlum.com
Email: PL****@PeterBlum.com
Creator of "Professional Validation And More" at
http://www.peterblum.com/vam/home.aspx

"TCORDON" <tc******@hotmail.com> wrote in message
news:Og**************@TK2MSFTNGP10.phx.gbl...
What is the best way to protect a site against it? Does anyone have a
RegEx to help validate user input?

TIA!

Nov 19 '05 #5

P: n/a
You should use ADO.NET parameter objects. They will protect you from SQL
Injection Attacks.

Here's more info:
http://msdn.microsoft.com/library/de...classtopic.asp

http://msdn.microsoft.com/library/de...isualbasic.asp

--
I hope this helps,
Steve C. Orr, MCSD, MVP
http://SteveOrr.net
"TCORDON" <tc******@hotmail.com> wrote in message
news:Og**************@TK2MSFTNGP10.phx.gbl...
What is the best way to protect a site against it? Does anyone have a
RegEx to help validate user input?

TIA!

Nov 19 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.