使用 Javascript 或 C# 防止 SQL 注入的最佳方法？
我目前正在编写一个应用程序，该应用程序在前端使用 ajax，在后端使用 ASP.NET (C#)。
应用程序的一小部分对后端代码进行 AJAX 调用（以从 SQL 数据库获取条目）
如何防止JScript注入的SQL？
我知道使用 javascript 进行验证通常是不安全的，因为 javascript 可以关闭，但由于这是一个 AJAX 调用，因此如果用户关闭了 javascript，AJAX 将永远不会运行。
验证或转义输入的最佳方法是什么？
就像 PHP 中的 Add_Slashes() 一样？
谢谢
丹尼尔
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
无论传入呼叫来自何处，都需要在服务器端进行针对 SQL 注入的防护。
基于Javascript的卫生方法总是无用的，因为Javascript运行在客户端，因此可以被伪造。
这也适用于 AJAX 调用：客户端不需要关闭 JavaScript；他们只需要操纵从您的网站下载的 Javascript 代码即可进行虚假验证。
永远、永远、永远不要依赖客户端数据清理。
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.
使用参数化查询，切勿构建 SQL 代码字符串。
Use parametrized queries, never build SQL code strings.
我认为使用参数化查询而不是 Adhoc SQL
I think use Parametirized Query instead of Adhoc SQL
无论你做什么，你总是必须在服务器上运行验证代码。
ajax 调用不可避免地会访问服务器，因此请验证用户输入以避免 SQL 注入攻击。
在客户端验证用户输入的唯一原因是避免调用服务器，例如，用户没有填写必填字段。
在服务器上，如果您使用 LINQ to SQL 或实体来更新数据库，您将获得免费的参数化查询，从而避免 SQL 注入攻击。
永远不要编写纯 sql 字符串并将其传递到数据库，除非您明确使用参数化查询。
但只要使用 LINQ，您就可以保证自己（和您的客户！）的安全。
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.
使用绑定参数是防止 SQL 注入的方法：
http://use-the-index-luke.com/where-clause/bind-parameters
也可以执行客户端验证，但只是提高可用性。
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.
Javascript 验证缺乏安全性与 Javascript 可能被关闭这一事实无关。
Javascript 可能会被关闭，这意味着无心的错误可能会造成一些错误，或者导致默认的服务器消息而不是有用的消息。虽然他们可能会意外触发安全问题（我实际上以用户身份这样做过，但更糟糕的是我的输入是有效的，但我输入的其中一个人的名字中有一个
'，更多内容见下文）。这会影响诚实但不完美的用户，而不是破解者。破解者应该能够在大约 30 秒内重放具有不同值的 AJAX 请求，其中包括在另一个窗口中在社交媒体网站上发出愚蠢威胁所花费的时间。这在技术上并不困难。这就是为什么 Javascript 验证没有安全价值，只是为了使对诚实错误的验证更加用户友好（通过更立即的响应，并能够将焦点直接关注到不正确的字段）。
此外，这通常不是验证问题，而是编码问题。有些人试图通过禁止可能导致 SQL 注入攻击的序列来“修复”SQL 注入攻击，这通常意味着禁止撇号字符。然后他们将此逻辑放入可能合理包含撇号的字段中。特别是，切勿对名称字段执行此操作；人们真的不喜欢被告知他们的名字是“错误的”，更糟糕的是，这可能让人感觉像是种族主义或文化不敏感，因为你会在法国或爱尔兰名字中发现很多这样的名字，但在英语或德国名字中却不常见（是的，我知道诺曼起源的英文名字经常有它们，但我也听到名字中带有撇号的人抱怨愚蠢的种族主义网站，该网站不允许他们正确输入他们的名字，这可能是提出这个名字的最糟糕的时机诺曼人作为更正）。
验证 Javascript 中是否存在明显错误，以此作为改进 UI 的一种方法。
验证服务器上是否存在明显错误，这既是改进 UI 的方法，也是捕获攻击的方法。
以正确的方式将数据传递到其他层。就 SQL 而言，这意味着对字符串分隔符进行编码（同样，
'是最常见的情况，但某些数据库也可以使用其他分隔符），为此，最好的方法是通过库这对你来说是这样的。对于 C#，这意味着将Parameters与 ADO.NET 一起使用，而不是自己构建 SQL（这还有其他优点）。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 usingParameterswith ADO.NET rather than building SQL yourself (there are other advantages to this too).这里有两个经常混合的概念。验证和编码/转义。添加斜杠是尝试对上下文的数据进行编码。验证是为了确保数据根据域是有效的。
要回答您的问题，避免这些问题的最佳方法是双重的。首先在服务器端验证数据（确保数字确实是数字等）。然而验证并不足以避免这些问题。名称“O'Brian”是有效名称的示例，因此它会通过验证，但可能会导致 javascript 或 SQL 语句出现问题。
所以下一部分是上下文感知编码。将数据粘贴到 SQL 语句中时，需要对 SQL 进行转义/编码。最简单、最安全的方法是使用参数化查询，一切都会为您处理。
详细信息：http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
数据被发送回客户端，您需要对返回数据的格式进行转义/编码。为了避免脚本注入，您需要知道是否在 HTML 属性内的 json 字符串内进行转义等等。有关如何针对不同上下文进行转义的信息，请参阅此处： 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
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