当今最流行的攻击之一是跨站点脚本攻击 (XSS)，它更多的是对应用程序用户的攻击，而不是对应用程序本身的攻击，但它仍然利用服务器端应用程序漏洞。结果可能是毁灭性的，并可能导致信息泄露、身份欺骗和特权提升
阅读这个文档我看到很多关于在管理服务器端之前清理/验证输入的建议。
嗯，据我所知，使用存储过程（用于数据库端）和.NET（管理和获取响应）我很确定。
您能否向我展示存储过程和 .NET 都可能失败（没有清理/验证）以及我可能“不安全”的场景？
正如我所说，我的意思是“安全”，而不是数据的持久性/准确性！我同意清理输入......
One of the most prevalent attacks today is cross-site scripting (XSS), which is more of an attack on your application's users than on the application itself, but it exploits server-side application vulnerabilities all the same. The results can be devastating and can lead to information disclosure, identity spoofing, and elevation of privilege
Reading this document I see many suggestions about Sanitizing/Validation input on server side before manage them.
Well, for what I know, using Stored Procedures (for the DB side) and .NET (to manage e get the responses) I'm quite sure.
Can you show to me a scenario where both Stored Procedures and .NET could fail (without Sanitizing/Validation) and where I can be "unsafe"?
As I say, I mean "security", not persistence/accuracy of data! There I agree on Sanitizing input...
发布评论
评论（3）
我知道我的答案引用了java，但我觉得它至少会提供一些上下文（响应很大的另一个原因评论）为什么我们也需要服务器/客户端输入卫生。
从您引用的文档中：
如果您没有在客户端/服务器端限制/验证此字符串/类型的长度，复杂的攻击者可能会通过提供长字符串输入来破坏您的系统。事实上，这是 Java 中的一个问题（不确定它是否适用于 .NET/IIS，假设这是因为 .NET 使用哈希码来实现相等，我也可能是错的）。
有趣的是，我们几天前在 SO 。
如果可以将字符串大小限制为限制字符。您可以安全地避免这些问题。
I know my answer references java, but I felt it will provide at least some context (another reason response is big for comment) why we need server/client side input sanitation also .
From the document you referenced:
If you haven't constrained/validated length of this string/type either on client side/ server side, sophisticated attacker may disrupt your system by providing long input of strings. Indeed this is an issue in Java (not sure it applies for .NET/IIS, assuming it is because .NET uses hashcode for equality, I may be wrong too).
Here is interesting we had couple of days ago here at SO.
If you can constraint String size as limit characters. You can safely avoid these issues.
如果您将数据传递给标准 .NET Framework 对象，那么这些对象应该自行处理。您应该将需要清理的数据视为 .NET 不知道如何处理的所有数据。即.NET 框架不知道其用途的数据。
例如，.NET 框架不会知道字符串值将用作社会保险号。如果您将其直接传递给第三方系统或存储在数据库中然后稍后传递，您将需要清理并验证输入以检查社会安全号码是否在预期范围内格式。如果不这样做，您的系统可能会因为第三方系统中的安全漏洞而容易受到攻击。例如，输入包含某些字符的社会安全号码可能会导致第 3 方系统崩溃，进而可能会在您的系统尝试与已关闭的服务进行通信时造成拒绝服务。这种情况只是多种可能性之一，它不一定会导致 DOS 攻击，但最终您需要验证和清理输入以防范未知情况。
正如您特别提到的 XSS，这是标准 .NET Web 控件实际上容易受到攻击的漏洞，除非请求验证的默认选项处于活动状态（请参阅 http://www.asp.net/whitepapers/request-validation）。这是因为 .NET Web 控件在设置 Text 属性时不会自动对字符进行 HTML 编码。因此，如果您在未启用请求验证的情况下运行站点，则应确保所有输出都已正确编码（这是输出清理的一种形式）。如果我选择使用 MVC 框架而不是 Web 表单进行开发，因为它可以轻松使用 HTML 输出清理（例如，使用 <%: %> 括号将自动对 HTML 编码输出）。这使您的应用程序能够正确处理在输入中输入的恶意（和非恶意）
Web 应用程序中常见的另一种清理方法是正确格式化将注入 JavaScript 的字符串（例如单引号和双引号字符）。简而言之，您正在防止用户通过输入插入恶意 JavaScript，该输入将显示给另一个用户并在未正确清理的情况下执行，并且执行时请求将以新用户身份运行，该新用户可能具有更高的安全级别在应用程序中，可能会发生各种损坏。
If you're passing your data to standard .NET Framework objects then these should handle their own sanitisation. You should think of the data that you need to sanitise as all the data that .NET does not know how to deal with. i.e. data that the .NET framework does not know what it will be used for.
For example, the .NET framework will not know that a string value is to be used as a social security number. If you're passing this to a 3rd party system, either directly or stored in a database and then passed at a later time, you're going to want to sanitise and validate the input to check that the social security number is in the expected format. Failure to do this could make your system vulnerable to attack because of security vulnerabilities in the 3rd party system. e.g. a social security number was entered containing certain characters may make the 3rd party system crash and in turn this could create a denial of service with your system as it is trying to communicate with a service that is down. This scenario is just one of many possibilities, it doesn't necessarily have to result in a DOS attack, but ultimately you're going to want to validate and sanitise input to guard against the unknown.
As you specifically mention XSS, this is a vulnerability that the standard .NET web controls are actually vulnerable to, unless the default option of Request Validation is active (see http://www.asp.net/whitepapers/request-validation). This is because the .NET web controls do not automatically HTML encode characters when setting the Text property. So if you're running your site without request validation on, you should make sure that everything output is properly encoded (this is a form of output sanitisation). Given the choice I would develop with the MVC framework rather than web forms, as it makes it easy to use HTML output sanitisation (e.g. using <%: %> brackets will HTML encode output automatically). This enables your application to correct handle malicious (and non malicious)
<script>tags entered in input without the need for validation, as the output is properly sanitised so therefore if your application is protected in this way request validation can be disabled, which is my preferred option as then you're not manipulating user input unnecessarily. For example, if SO sanitised input and removed<script>tags it would be impossible for me to include them in this message.Another type of sanitisation that is common with web apps is correctly formatting strings that will be injected into JavaScript (e.g. single and double quote characters). In a nutshell you're guarding against a user inserting malicious JavaScript via an input, which will be displayed to another user and executed if not properly sanitised, and when executed the request will be running as the new user which may have a higher security level in the application and all sorts of damage could occur.
对输入进行消毒很少是正确的选择。您应该在使用它的地方进行清理或编码，因为只有在那里您才知道什么需要编码、转义或删除。
在大多数情况下，当您使用设计良好的 API 时，无需进行手动清理。但在某些情况下，您仍然需要手动编码或验证，因为您了解的不仅仅是 API。例如，如果在 html 页面中嵌入的一段 javascript 中使用该字符串，则自动 html 编码输出不会保护您。
自动编码规则适合 html，而不是 javascript 字符串，因此这是不安全的。
Sanatizing input is rarely the correct choice. You should sanitize or encode at where it is used, because only there you know what needs to be encodes, escaped or removed.
In most cases manual sanitizing isn't necessary, when you use well designed APIs. But in some cases you still need to encode or validate manually, because you know more than the API. For example automatic html encoding output doesn't protect you, if the string is used inside a piece of javascript embedded in the html page.
The automatic encoding rules fit html, not javascript strings, so this would be insecure.