在asp.net中处理危险字符的最佳做法是什么? 参见示例:asp.net sign up form
你应该:
#1的问题是它会增加页面加载时间。
答案 0 :(得分:9)
请求验证是ASP.NET中检查HTTP的一项功能 请求并确定它是否包含潜在危险 内容。在这种情况下,潜在危险的内容是任何HTML 正文中的标记或JavaScript代码,标题,查询字符串或 请求的cookie。 ASP.NET执行此检查是因为标记或 URL查询字符串,Cookie或已发布的表单值中的代码可能 已被添加用于恶意目的。
请求验证有助于防止此类攻击。如果是ASP.NET 检测到请求中的任何标记或代码,它会抛出“潜在的 检测到危险值“错误并停止页面处理。
也许最重要的一点是它发生在服务器上;无论客户端访问您的应用程序,他们都无法通过JavaScript来解决它。
答案 1 :(得分:2)
你接受它们就像写作方面的常规字符一样。渲染时,您对输出进行编码。无论安全性如何,您都必须对其进行编码,以便您可以显示特殊字符。
答案 2 :(得分:2)
解决方案编号1不会增加加载时间。
您应该始终使用第2号解决方案和第一个解决方案,因为用户可以在浏览器中关闭javascript。
答案 3 :(得分:0)
始终验证服务器上的输入,这甚至不应该是讨论,只需这样做!
客户端验证对用户来说只是一件好事,但服务器才是最重要的!
答案 4 :(得分:0)
想到
自从ASP .NET 2.0以来,ASP .NET默认为您处理潜在危险的字符。来自ASP.NET中的请求验证:
就像是认为一扇坚固的门可以让小偷出局。它不会。这只会让他慢下来。您必须知道最常见的载体是什么以及可能的解决方案是什么。您必须理解,您在HTML / CSS / Javascript中编写的每个 EVERY 变量(字段/属性)都是潜在的攻击向量,必须进行清理(通过使用适当的库,如某些方法,包括在较新的MVC.NET中,或者至少是ASP.NET 4.0的<%: %>
,没有例外,你执行的每个 EVERY 查询都是一个潜在的附加向量,必须通过独占来消毒使用ORM和参数化查询,没有例外。数据库中不能保存密码。还有很多其他类似的东西。这并不是很困难,但是懒惰,自满,无知会使其变得更难(如果不是几乎不可能的话)。如果不是你会介绍那个洞那么它就是你左边的程序员,或右边的程序员。没有希望。
答案 5 :(得分:0)
在asp.net中处理危险字符的最佳做法是什么?
我没有看到您链接到的截屏视频(问题应该是自包含的),但没有危险字符。这一切都取决于具体情况。以Stack Overflow为例,它允许我输入字符Dangerous!'); DROP TABLE Questions--
。没有什么危险的。
ASP.NET本身将尽最大努力防止HTTP级别的恶意输入:它不会让任何用户访问诸如web.config
之类的文件或Web根目录之外的文件。
只要你开始使用用户输入做某事,就由你决定。没有银弹,没有一条适合他们的规则。如果您要将用户输入显示为HTML,则必须确保仅允许无害的标记标记而没有任何可编写脚本的属性。如果您允许用户上传图片,请确保仅上传图片。如果要将输入发送到RDBMS,请确保转义对数据库操作语言有意义的字符。
等等。