使用 Javascript 或 C# 防止 SQL 注入的最佳方法？

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

提问by Daniel Upton

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

我目前正在编写一个应用程序，它在前端使用 ajax，在后端使用 ASP.NET (C#)。

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

应用程序的一小部分对后端代码执行 AJAX 调用（以从 SQL 数据库中获取条目）

How can i prevent SQL of JScript injection?

如何防止 SQL 的 JScript 注入？

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.

我知道用 javascript 验证通常是不安全的，因为 javascript 可以关闭，但由于这是一个 AJAX 调用，所以如果用户关闭了 javascript，AJAX 将永远不会运行。

Whats the best way of validating or escaping the input?

验证或转义输入的最佳方法是什么？

Like Add_Slashes() in PHP?

像 PHP 中的 Add_Slashes() 吗？

Thanks

谢谢

Daniel

丹尼尔

回答by Pekka

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

无论传入呼叫来自何处，都需要在服务器端进行针对 SQL 注入的保护。

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

基于 Javascript 的卫生方法总是无用的，因为 Javascript 在客户端运行，因此可以伪造。

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.

这也适用于 AJAX 调用：客户端不需要关闭 JavaScript；他们只需要操纵他们从您的网站下载的 Javascript 代码来伪造验证。

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

永远，永远，永远不要依赖客户端数据卫生。

回答by Lucero

Use parametrized queries, never build SQL code strings.

使用参数化查询，永远不要构建 SQL 代码字符串。

回答by TalentTuner

I think use Parametirized Query instead of Adhoc SQL

我认为使用参数化查询而不是 Adhoc SQL

回答by awrigley

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.

ajax 调用不可避免地会访问服务器，因此请在那里验证用户输入以避免 sql 注入攻击。

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.

在服务器上，如果您使用 LINQ to SQL 或实体来更新数据库，您将获得免费的参数化查询，从而避免 SQL 注入攻击。

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

永远不要，永远不要写简单的 sql 字符串并将其传递给数据库，除非您明确使用参数化查询。

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

但是只要使用 LINQ，您就可以保证自己（和您的客户！）的安全。

回答by Markus Winand

Using Bind Parameters is theway to prevent SQL injection:

使用绑定参数是在防止SQL注入方式：

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

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.

它是确定执行客户端验证，以及，但只是为了提高可用性。

回答by Jon Hanna

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

Javascript 验证缺乏安全性与 Javascript 可能被关闭的事实无关。

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.

Javascript 可能被关闭意味着一个诚实的错误可能会做错事，或者导致默认服务器消息而不是有用的消息。虽然他们可能会意外触发安全问题（我实际上是作为用户这样做的，更糟糕​​的是我的输入是有效的，但我输入的其中一个人的名字中有一个'，下面有更多内容）。这会影响诚实但不完美的用户，而不是饼干。

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

破解者应该能够在大约 30 秒内重播具有不同值的 AJAX 请求，包括在另一个窗口中在社交媒体网站上制造愚蠢威胁所花费的时间。这在技术上并不困难。这就是为什么 Javascript 验证没有安全价值的原因，它只是为了使对诚实错误的验证更加用户友好（通过更直接的响应，并能够将注意力集中在不正确的领域）。

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

此外，这通常不是验证问题，而是编码问题。有些人试图通过禁止可能导致它们的序列来“修复”SQL 注入攻击，这通常意味着禁止撇号字符。然后他们将此逻辑放在可能合理包含撇号的字段上。特别是，永远不要对名称字段这样做；人们真的不喜欢被告知他们的名字是“错误的”，更糟糕的是，这会让人感觉像是种族主义或文化不敏感，因为您会在很多情况下发现它们，例如法语或爱尔兰语名称，但不常出现在英语或德语名称中（是的，我知道诺曼人起源的英文名字经常有它们，但我也听到有人在他们的名字中有撇号的人抱怨愚蠢的种族主义网站不会让他们正确输入他们的名字，

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

验证 Javascript 中的明显错误作为改进 UI 的一种手段。

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

验证服务器上的明显错误既是改进 UI 的手段，也是捕获攻击的手段。

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 Parameterswith ADO.NET rather than building SQL yourself (there are other advantages to this too).

以正确的方式将数据传递到其他层。就 SQL 而言，这意味着编码字符串定界符（同样，这'是最常见的情况，但某些数据库也可以使用其他一些定界符），为此最好的方法是通过为您这样做的库。在 C# 的情况下，这意味着使用ParametersADO.NET 而不是自己构建 SQL（这也有其他优点）。

回答by Erlend

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.

要回答您的问题，避免这些问题的最佳方法是双重的。首先验证服务器端的数据（确保数字确实是数字等）。然而，验证不足以避免这些问题。名称“O'Brian”是有效名称的一个示例，因此它会通过验证，但它可能会导致 javascript 或 SQL 语句出现问题。

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

所以下一部分是上下文感知编码。在 SQL 语句中粘贴数据时，您需要对 SQL 进行转义/编码。做到这一点最简单和最安全的方法是使用参数化查询，其中一切都为您处理。更多信息：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_SheetUse AntiXSS for escaping/encoding for web: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=f4cd231b-7e06-445b-bec7-343e5884e651

当数据发送回客户端时，您需要针对返回数据的格式对数据进行转义/编码。为避免脚本注入，您需要知道是否在 json 字符串中转义，在 HTML 中转义 -属性等等等等。看到这里了解如何逃脱的不同的上下文信息：http://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet使用AntiXSS转义/编码网址：HTTP：/ /www.microsoft.com/downloads/en/details.aspx?FamilyID=f4cd231b-7e06-445b-bec7-343e5884e651