Best Way to Prevent SQL Injection Using Javascript or C#?

I'm currently writing an application which uses ajax on the front end and ASP.NET (C#) on the back end..

A Small Part of the application does an AJAX call to the backend code (to get entries from the SQL database)

How can i prevent SQL of JScript injection?

I know it is generally unsecure to validate with javascript because javascript can 开发者_运维技巧be turned off but as this is an AJAX call so if the user has javascript turned off the AJAX will never run.

Whats the best way of validating or escaping the input?

Like Add_Slashes() in PHP?

Thanks

Daniel

Protection against SQL injection needs to take place on server side, regardless where the incoming call comes from.

Javascript-based sanitation methods are always useless because Javascript runs on client side, and therefore can be forged.

This also applies for AJAX calls: The client doesn't need to turn JavaScript off; they just need to manipulate the Javascript code they download from your site to fake validation.

Never, ever, ever rely on client side data sanitation.

Use parametrized queries, never build SQL code strings.

I think use Parametirized Query instead of Adhoc SQL

Whatever you do, you ALWAYS have to run validation code on the server.

The ajax call inevitably hits the server, so validate user input there for avoiding sql injection attacks.

The only reason for validating user input on the client is to avoid a call to the server, eg, a user didn't fill in a required field.

On the server, if you use LINQ to SQL or Entities to update the database, you get free parametrized queries which avoid SQL Injection attacks.

Never, EVER write plain strings of sql and pass that to the database, unless you EXPLICITLY use parametrized queries.

But just use LINQ and you will keep yourself (and your client!) safe.

Using Bind Parameters is the way to prevent SQL injection:

http://use-the-index-luke.com/where-clause/bind-parameters

It is ok to perform client side validation as well, but just to improve usability.

The lack of security of Javascript validation has got nothing to do with the fact that Javascript might be turned off.

That Javascript might be turned off means that an honest mistake may do something wrong, or result in a default server message rather than a helpful one. While they could accidentally trigger a security issue (I have actually done this as a user, the worse bit is my input was valid, but one of the people whose names I was entering had a ' in it, more on that below). This affects honest but imperfect users, not crackers.

A cracker should be able to replay an AJAX request with different values in around 30seconds, including time spent making stupid threats on social media sites in another window. It's not technically difficult. That's why Javascript validation has no security value, and is solely to make the validation for honest mistakes more user-friendly (by having a more immediate response, and being able to direct focus to the incorrect field).

Further, this is generally not a matter of validation, but of encoding. Some people try to "fix" SQL injection attacks by banning the sequences that can cause them, which most often means banning apostrophe characters. Then they put this logic onto fields that might reasonably contain apostrophes. In particular, never do this with name fields; people really don't like being told that their name is "wrong" and at worse it can feel like racism or cultural insensitivity, since you will find them a lot in e.g. French or Irish names but not so often in English or German names (yes I know English names of Norman origin often having them, but I have also heard people with apostrophes in their names ranting about the stupid racist website that won't let them input their name correctly, which is probably the worse time to bring up the Normans as a correction).

Validate for the obviously wrong in Javascript as a means to improve UI.

Validate for the obviously wrong on the server as both a means to improve UI and a means to catch attacks.

Pass your data to other layers in the correct manner. In terms of SQL this would mean encoding string delimiters (again, ' is the most common case, but some other delimiters are possible with some databases), for which the best means of doing so is through a library that does so for you. In the case of C# this would mean using Parameters with ADO.NET rather than building SQL yourself (there are other advantages to this too).

There are two concepts that are often mixed here. Validation and encoding/escaping. Adding a slash is an attempt to encode data for a context. Validation is about making sure the data is valid according to the domain.

To answer your question, the best way to avoid these problem is twofold. First validate the data on server-side (make sure a number is indeed a number etc.). However validation is not enough to avoid these problems. The name "O'Brian" is an example of a valid name, so it would pass validation, but it may cause problems in javascript or in a SQL-statement.

So the next part is context-aware encoding. When sticking the data in a SQL statement, you need to escape/encode for SQL. The easiest and safest way to do this, is to use parameterized queries, where everything is handled for you. More info: http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

When the data is sent back to the client, you need to escape/encode the data for the format you are returning the data in. To avoid script injection you need to know if you are escaping inside a json-string, inside an HTML-attribute etc. etc.. See here for information about how to escape for the different contexts: http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet Use AntiXSS for escaping/encoding for web: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=f4cd231b-7e06-445b-bec7-343e5884e651