如何更改或删除 HttpModule 中的 HttpRequest 输入参数
是否可以更改或删除 http 模块中的 http 请求表单输入？
我的目标是创建一个安全 IHttpmodule，它将检查请求的合理值，例如可接受的输入和查询参数长度的限制，或者在传递请求之前使用 AntiXSS Sanitizer 消除威胁、记录潜在的黑客尝试等到处理器。
因为这是一个横切问题，所以我更愿意找到一个适用于所有请求并影响请求值访问的所有方式的解决方案，Reqest.Form、Action(model)、Action(FormCollection)、HttpContext.Current.Request。表单等。
我正在使用 MVC，并考虑在创建模型实例之前创建自定义模型绑定器来清理数据。但这将是特定于应用程序的，需要记住注册每个模型绑定程序并且仅适用于操作（模型）。
Is it possible to change or remove http request form inputs in an httpmodule?
My goal is to create a security IHttpmodule that will check the request for reasonable values, such as limits on acceptable input and query parameter length, or use the AntiXSS Sanitizer to remove threats, log potential hack attempts, etc. before a request is passed on to a processor.
Because this is a cross cutting concern I'd prefer to find a solution that applies to all requests and affects all ways request values could be accessed, Reqest.Form, Action(model), Action(FormCollection), HttpContext.Current.Request.Form, etc.
I'm using MVC and have considered creating custom model binders to clean the data before creating the model instance. But that would be application specific, require remembering to register every model binder and only apply to Action(model).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我建议您在此阶段不要清理输入，因为这可能会导致有趣的问题。我经历了惨痛的教训才明白这一点。
你要消毒什么？代码注入（脚本/html）？ SQL注入？还有别的事吗？消毒与您正在做的事情有关。因此，如果您正在设置将每个请求的 HTTPRequest 中的内容记录到数据库中的代码，那么防止注入是有意义的，但删除恶意代码或修改它不会存储所提供的数据，你会得到不一致的数据。
您的代码应该查看这些输入正在执行的操作的上下文，而不是重新分配原始输入数据。
如果它要进入数据库，请确保它不会允许注入攻击。如果要将数据嵌入到页面上，请确保对其进行转义，以便您无法包含脚本或更改 HTML。如果是电子邮件发送者，请确保您无法在电子邮件字段中插入换行符并让 SMTP 发送到多个地址。
这一切都与上下文有关，因为没有包罗万象的所有漏洞。因此，保持原始输入原始，但根据您要在代码的该部分中执行的操作来过滤它们。
我是如何艰难地学到这一点的？当我学习 PHP 和 Web 安全时，我编写了一个脚本来调查所有 HTTP 标头、cookie、请求变量、ip、页面地址等。然后它根据我的需要通过各种预定义的过滤器过滤它们，并将它们传递到所需的函数/对象中。例如，年龄是一个数字，因此我会确保在通过清理年龄函数进行填充后将其分配给我的对象。这对于某些情况来说很好，但是当您有多个可以使用该数据的上下文时，转义 SQL 并不能解决问题，并且转义 HTML 实体以最初未呈现的方式存储数据，如果我'我将其放入数据库中。现在，如果需要对该列进行 XSS 过滤，那么请继续使用该列更新数据库的特定部分，但不要更新原始数据。
这只是我的观点，我没有资源表明这是最佳实践。
I suggest you do not sanitize input at this stage as it may lead to interesting issues. I learned this the hard way.
What would you sanitize? Code injection (script/html)? Sql Injection? Something else? The sanitization is linked to what you're doing. So, if you're setting up code that records what was in the HTTPRequest for each request into a database, it makes sense to work against injection, but removing malicious code, or modifying it won't store the data as it was provided, and you're going to get inconsistent data.
Your code should look at the context of what's being done with these inputs, rather than re-assigning raw input data.
If it's going into a database, make sure it's not going to allow for injection attacks. If it's embedding the data onto a page, make sure it's escaped such that you can't include scripts or change the HTML with it. If it's an emailer, make sure you can't insert a new line charecter in the email field and have SMTP send to multiple addresses.
It's all about the context, because there is no catch all for all the exploits. So, keep your raw inputs raw, but filter them based on what you're going to do in that part of your code.
How did I learn this the hard way? Back when I was learning PHP and web security, I made a script that investigated all HTTP headers, cookies, request variables, ip, page address, and otherwise. It then filtered them through various pre-defined filters based on what I wanted, and passed them into the required function/object. For instance, age was a number so I would make sure to assign it to my object after filltering through the sanitize-age function. This was fine for some cases, but when you have multiple contexts in which that data can get used, escaping against SQL just doesn't cut it, and escaping HTML entities stores the data in a way that wasn't originally presented if I'm placing it into a database. Now, if that column needs to be filtered against XSS, then go ahead and update that specific part of the database with that, but not the raw data.
This is simply my opinion, I do not have resources that indicate this is a best-practice.