为什么我需要执行服务器端验证？

Question

感谢所有评论或发布答案的人!我保留了我原来的问题,并在下面更新完整性.

[2011年2月16日 - 更新2]正如一些人所指出的那样 - 我的问题应该是:给定一个标准的asp.net 4表单,如果我没有任何服务器端验证,我可以使用哪种类型的恶意攻击？

这是我对这个问题的看法.

• 如果数据不敏感(页面上的注释) - 从asp.net安全角度来看,遵循标准最佳实践(SqlParameters,启用请求验证等)将保护您免受恶意攻击.
• 对于敏感数据/应用程序 - 由您决定哪种类型的服务器端验证适合您的应用程序.您需要考虑端到端解决方案(Web服务,其他系统等).您可以在下面查看一些建议 - 白名单验证等.
• 如果您使用ajax(xhr请求)发布用户输入,则需要重新保护服务器上代码中的其他项目符号.同样,下面有很多解决方案 - 比如确保数据不包含任何html /代码等等 (旁注:.net框架requestValidationMode ="4.0"在这方面确实提供了一些保护 - 但我不能说话它是如何完整的解决方案)

请随时继续发表评论......如果以上任何内容不正确,请告诉我.谢谢!

---

[2011年2月3日 - 更新1]我要感谢大家的回答!也许我应该问相反的问题:

假设一个简单的asp.net 4.0 Web表单(formview + datasource,启用了请求验证),允许登录用户将注释发布到公共页面(存储在sql server db表中的注释).我应该对服务器端的新"注释"执行什么类型的数据验证或清理？

---

[2011年1月19日 - 原始问题]我们的asp.net 4网站有一些用户可以提交数据的表单,我们在客户端使用jquery验证.用户必须使用有效帐户登录才能访问这些表单.

我知道我们的客户端验证规则很容易被绕过,客户端可以在没有必填字段的情况下发布数据等.这与我无关 - 用户必须登录,我不认为我们的数据非常"敏感"我也不会说任何验证都是"关键"的.输入数据使用SqlParameters写入数据库(防止sql注入),我们依赖asp.net请求验证来防御潜在危险的html输入.

是否真的值得花时间在服务器上重写各种jquery验证规则？具体来说,恶意用户如何破坏我们的服务器或我们可以开放哪些特定的攻击？

我很抱歉,因为看起来这个问题已在本网站上讨论了几次 - 但我还没有找到一个答案,引用了未执行服务器端验证的特定风险或问题.提前致谢

Answer 1

假设情况:

假设您有一个邮政编码字段.在客户端,您验证它必须是"00000"或"00000-0000"模式.由于您允许使用连字符,因此您决定将该字段存储为数据库中的varchar.

因此,一些邪恶的用户出现并决定绕过所有客户端验证并提交不正确格式的内容并使其超过请求验证.

好吧,没什么大不了的......,无论如何,你在将它显示回用户之前对其进行编码.

但是你还用邮政编码做了什么？您是否将其提交给Web服务进行某种查找？您要将其上传到GPS设备吗？它将来会被其他东西解释吗？您的邮政编码字段现在是否包含一些JSON或其他奇怪的东西？

或类似的东西:http://www.businessinsider.com/livingsocial-server-flaw-2011-1

Answer 2

安全性是一种可靠性属性,定义为系统抵御攻击的概率,或者故障未被恶意激活的概率.

为了实现安全性,您必须执行威胁分析.复杂的计算机系统需要进行更深入的分析(考虑飞机的控制塔的设备),因为它们变得越来越重要,威胁会给企业或人类生命带来风险.

您可以通过询问自己如果用户绕过验证会发生什么来执行您自己的威胁分析？.

两组答案,例如:

第1组(关键)

1. 用户可以购买低于其价格的物品
2. 可以向用户显示关于其他用户的信息
3. 用户获得他/她不应具有的权限

第2组(非关键)

1. 用户在下一页中显示不一致的数据
2. 处理继续,但不一致导致需要人为干预的错误
3. 用户的数据(但仅限该用户而非其他用户)会受到损害
4. 将奇怪的错误页面返回给用户,其中包含许多无法使用的技术信息

在第一种情况下,你必须明确修复你的验证问题,因为你可能会在攻击后赔钱,或者失去公众的信任(即使你不是朋友,也要考虑伪造Facebook网址并展示某人的照片).

在第二种情况下,如果您确定不一致的字段不会使您的业务或数据面临风险,您仍可能避免修复

真正的问题是

您如何证明发送到您网站的任何不一致数据永远不会对可能构成威胁的系统产生任何影响？

这就是为什么你减少修复验证的时间而不是考虑它

Answer 3

老实说,用户并不关心您认为"敏感"或"关键"数据.这些标准由他们决定.

我知道,如果我是您的应用程序的用户,并且我看到我的数据发生了变化,而我没有直接做某些事情导致更改......我会尽快关闭我的帐户.很明显,您的系统不安全,我的数据都不安全.

请记住,你强迫人们登录,所以你至少要在某处拥有自己的密码.无论是否容易访问,违规都是违规行为,我已经失去了信任.

所以...虽然您可能不认为输入注入攻击很重要,但您的用户将会这样做,这就是您仍然应该进行服务器端输入验证的原因.

Answer 4

您的数据可能不值得,我没关系.

但是,攻击者可以将CSRF "跨站点请求伪造"攻击代码注入您的应用程序; 您网站的用户可能会将其他网站上的数据泄露.是的,它会要求那些"其他网站"出现错误,但这种情况会发生.是的,它要求用户不要在这些网站上使用"注销"按钮,但没有足够的人使用它们.想想用户在其他网站上存储的所有美味数据.你的用户不会发生什么坏事.

攻击者可以注入HTML,邀请用户下载并安装"查看此内容所需的插件" - 键盘记录程序插件,或搜索硬盘驱动器以获取信用卡号或税务申报.也许一个插件成为垃圾邮件或色情主机.您的用户信任您的网站不推荐Yakuza拥有的插件,对吧？如果您的网站建议安装邪恶的东西,他们可能会感到不友好

根据无效数据可能引发的错误类型,您可能会发现自己是一个spambot或色情主机.这在很大程度上取决于您对应用程序的其他方面进行编码的防御程度.太多的应用程序盲目地信任输入数据.

最好的部分:你的用户不是人.您的用户是浏览器,可能正在执行由其他网站提供的攻击,这些攻击无需执行良好的输入验证和输出清理.您的用户是碰巧偶然或通过设计找到您的病毒或蠕虫.你可能会相信这些人,但你相信他们的电脑有多远？我,不是很远.

请尽可能安全地编写应用程序 - 如果需要,您可以在首页放置一个大按钮以删除所有用户的数据 - 但请不要故意编写不安全的程序.