0

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

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Nurlan
  • 2,706
  • 19
  • 45
  • 63

6 Answers6

7

You can add parameters with AddWithValue method like this:

SqlCommand cmd = new SqlCommand("Select * From Test Where TestID = @TestID");
cmd.Parameters.AddWithValue("@TestID", 5);
Marc Gravell
  • 976,458
  • 251
  • 2,474
  • 2,830
pilavust
  • 528
  • 1
  • 7
  • 19
4

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

Community
  • 1
  • 1
JohnnBlade
  • 4,233
  • 1
  • 20
  • 22
  • 1
    make that "or a library that will do this for you, such as... {blah}" and it would be better; this isn't unique to L2S/EF ;p – Marc Gravell Aug 10 '12 at 09:29
2

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;
}
Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
podiluska
  • 50,144
  • 7
  • 94
  • 100
  • LOL))))) I am using HttpContext.Current.Server.HtmlEncode(). Does this protect? – Nurlan Aug 10 '12 at 09:34
  • No. It will protect against some forms of XSS attacks (which are different), but not all, and is no protection against SQL injection – podiluska Aug 10 '12 at 09:36
1

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:

Community
  • 1
  • 1
huMpty duMpty
  • 14,061
  • 13
  • 55
  • 93
1

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

Community
  • 1
  • 1
Rory Alsop
  • 1,444
  • 28
  • 35
0

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...

Peter Mortensen
  • 30,030
  • 21
  • 100
  • 124
Akash KC
  • 15,511
  • 5
  • 36
  • 58