I fail to see how this kind of exploit can be done using by injecting the code you show, but the
solution protecting from SQL injection should be universal and protect from any kinds of injection. In other words, you should not allow the user to inject anything which could become a part of SQL code, but allow the user to provide only the data. Even if the user supply some string which can be interpreted as a fragment of SQL code, this string will be interpreted as string data, which would have no a way to sneak into code.
With ASP.NET, specifically, you should understand that a user can send any input which your server-side code-behind handler can accept, totally bypassing HTML forms or any other client-side mechanism, such as Ajax. Such bypassing can be done by complete simulation of such malicious client behavior by directly forming HTTP request. With .NET, for example, this is quite elementary, based on available BCL code.
You should never repeat the common mistake: composing an SQL statement out of string fragment using string concatenation or
string.Format with user-supplied data. As
the only mechanism of parametrization based on user input,
parametrized statements should be used:
http://en.wikipedia.org/wiki/SQL_injection#Parameterized_statements[
^].
Please see how it can be done with ADO.NET:
http://msdn.microsoft.com/en-us/library/ms254953.aspx[
^],
http://msdn.microsoft.com/en-us/library/yy6y35y8.aspx[
^].
—SA
Submit an article or tip