Protection from SQL injection

Question

Is there a function which accepts a string as a parameter and returns a "cleaned" string, so as to support protection from SQL injection?

Answer 1

You need to use parameters, LINQ to SQL or Entity Framework.

LINQ to SQL

http://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx

Entity framework

http://msdn.microsoft.com/en-us/data/ef.aspx

SQL Parameters

http://www.dotnetperls.com/sqlparameter

Answer 2

You can add parameters with AddWithValue method like this:

SqlCommand cmd = new SqlCommand("Select * From Test Where TestID = @TestID");
cmd.Parameters.AddWithValue("@TestID", 5);

Answer 3

No function will be perfect or foolproof. You should really aim to protect against SQL injection through other means (i.e., stored procedure, SQL parameterisation, etc.).

Although this function is fairly effective :)

string CleanString(string s)
{
    return string.Empty;
}

Answer 4

I don't think a function that clever enough exists to find if there is a possibility of SQL injection or not.

But the best thing is to avoid all the possibilities. For example, using type-safe SQL parameters for data access.

Please have a look:

• SQL Injection Attacks and Some Tips on How to Prevent Them

• How can I avoid SQL injection attacks in my ASP.NET application?

• How To: Protect From SQL Injection in ASP.NET

Answer 5

Have a look at the answers on this question at Security Stack Exchange - the most appropriate path for you may be OWASP's ESAPI - their Enterprise Security API, which has functionality for Java EE, .NET, ASP Classic, PHP, ColdFusion CFML, Python, JavaScript, Objective-C, Force com, Ruby, Swingset, C, C++ and Perl is:

a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development. Allowing for language-specific differences, all OWASP ESAPI versions have the same basic design: There is a set of security control interfaces. They define for example types of parameters that are passed to types of security controls. There is a reference implementation for each security control. The logic is not organization‐specific and the logic is not application‐specific. An example: string‐based input validation. There are optionally your own implementations for each security control. There may be application logic contained in these classes which may be developed by or for your organization. An example: enterprise authentication.

And also read this document: SQL Injection Prevention Cheat Sheet

Answer 6

I strongly believe on using parameters to avoid SQL injection. You can write a stored procedure or parametrized query to avoid it.

Parameters has many benefits besides SQL injection, such as it can handle lot of issues with dates and numbers...