感谢评论或发布答案的所有人！我保留了我原来的问题，并在下面更新完整性。
[2011年2月16日 - 更新2]有些人指出 - 我的问题应该是：给定一个标准的asp.net 4表单，如果我没有任何服务器端验证，那么什么类型的我容易受到恶意攻击吗？
这是我对这个问题的看法。
请随时继续发表评论......如果以上任何内容不正确，请告知我们。谢谢！
[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验证规则真的值得我们花时间吗？具体来说，恶意用户如何破坏我们的服务器或我们可以开放哪些特定的攻击？
我很抱歉这个问题已在本网站上讨论了几次 - 但我还没有找到一个答案，引用了未执行服务器端验证的特定风险或问题。提前致谢
答案 0 :(得分：18)
假设情况：
假设您有一个邮政编码字段。在客户端，您验证它必须是“00000”或“00000-0000”模式。由于您允许使用连字符，因此您决定将该字段存储为数据库中的varchar。
因此，一些邪恶的用户出现并决定绕过所有客户端验证并提交不正确格式的内容并使其超过请求验证。
好的，没什么大不了的......，无论如何，你在将它显示回用户之前对其进行编码。
但是你还用邮政编码做了什么？您是否将其提交给Web服务进行某种查找？您要将其上传到GPS设备吗？它将来会被其他东西解释吗？您的邮政编码字段现在是否包含一些JSON或其他奇怪的内容？
或类似的东西：http://www.businessinsider.com/livingsocial-server-flaw-2011-1
答案 1 :(得分：7)
安全性是一个可靠性属性，定义为系统抵御攻击的概率，或者故障未被恶意激活的概率。
要实施安全性，您必须执行威胁分析。复杂的计算机系统需要进行更深入的分析（考虑一架飞机的控制塔的设备），因为它们变得越来越“强烈”，威胁会给企业或人类生命带来风险。
您可以通过质疑自己来执行自己的威胁分析如果用户绕过验证会发生什么？。
两组答案，例如：
第1组（关键）
第2组（非关键）
在第一种情况下，您肯定必须修复您的验证问题，因为您可能会在攻击后赔钱，或失去公众的信任（考虑伪造Facebook网址并显示某人的照片）如果你不是相互朋友的话。）
在第二种情况下，如果您确定不一致的字段不会使您的业务或数据面临风险，您仍可以避免修复
如何证明发送到您网站的任何不一致数据从不应该对可能构成威胁的系统产生任何后果？
这就是为什么你减少修复验证的时间而不是考虑它的原因
答案 2 :(得分：6)
老实说，用户并不关心您认为“敏感”或“关键”数据。这些标准由他们决定。
我知道，如果我是您的应用程序的用户，并且我看到我的数据发生了变化，而我没有直接做某些事情导致更改......我会尽快关闭我的帐户。很明显，您的系统不安全，我的数据都不安全。
请记住，您强迫用户登录，因此您至少要将密码放在某处。无论是否容易访问，违规都是违规行为，我已经失去了信任。
所以...虽然您可能不认为输入注入攻击很重要，但您的用户将 是您仍应进行服务器端输入验证的原因。
答案 3 :(得分：5)
你的数据可能不值得，我也没关系。
但是，攻击者可以向您的应用程序注入CSRF“跨站点请求伪造”攻击代码;您网站的用户可能将其他网站上的数据泄露。是的，它会要求那些“其他网站”出现错误，但这种情况会发生。是的，它要求用户不要在这些网站上使用“注销”按钮，但没有足够的人使用它们。想想用户在其他网站上存储的所有美味数据。你的用户不会发生任何不好的事情。
攻击者可以注入HTML，邀请用户下载并安装“查看此内容所需的插件” - 键盘记录程序插件，或搜索硬盘驱动器以获取信用卡号或税务申报。也许一个插件成为垃圾邮件或色情主机。您的用户信任您的网站不推荐Yakuza拥有的插件，对吧？如果您的网站建议安装邪恶的东西，他们可能会感到不友好。
根据无效数据可能触发的bug类型，您可能会发现自己是一个spambot或色情主机。这在很大程度上取决于您对应用程序的其他方面进行编码的防御程度。太多的应用程序盲目地信任输入数据。
最好的部分：你的用户不是人。您的用户是 browsers ，可能正在执行其他网站提供的攻击，这些攻击无需执行良好的输入验证和输出清理。您的用户是碰巧偶然或通过设计找到您的病毒或蠕虫。你可能会相信这些人，但你相信他们的电脑有多远？我，不是很远。
请尽可能安全地编写应用程序 - 如果需要，您可以在首页上放置一个大按钮以删除所有用户的数据 - 但请不要故意编写不安全的程序。
答案 4 :(得分：3)
这是一个极好而勇敢的问题。简短（可能是勇敢）的答案是你没有。如果您了解所有安全漏洞并且仍然认为没有必要，那么这就是您的选择。
这实际上取决于您的用户是谁，该网站所接触的人（内联网或互联网）以及获取帐户的容易程度。您说您的数据不敏感但您仍然需要用户登录。如果未经授权的用户通过在其他用户的计算机上跳跃来访问系统有多糟糕呢？
请记住，依靠请求验证来查找恶意输入永远不会被证明是100％安全的，因此安全性通常在多个级别完成，并且具有相当多的冗余。
然而，它必须是您的选择，并且您正在做正确的事情，以找出将其排除的后果。
答案 5 :(得分：2)
我认为您需要在客户端和服务器端验证这两者，这就是原因。
在客户端，您经常会阻止用户提交明显错误的数据。他们没有填写必填字段。他们将字母放在一个只包含数字的字段中。他们提供了将来只有过去的日期（例如出生日期）的日期。等等。通过在客户端防止这些类型的错误，您可以避免用户受挫，并减少对Web服务器的不必要命中数。
在服务器端，您通常应该重复在客户端进行的所有验证。这是因为，正如您所观察到的，聪明的用户可以绕过客户端验证并提交无效数据。此外，还有一些验证在客户端无效或无法完成。有时，您会检查数据条目是否符合业务规则。您可以根据数据库中的现有数据进行检查。如果您只是让用户输入任何内容（尤其是省略必填字段），则网站将无法正常运行。
答案 6 :(得分：1)
查看firefox的Tamper Data扩展。您可以非常轻松地向服务器提供任何内容
答案 7 :(得分：0)
通过您的网站（使用jQuery验证）向您的服务器执行HTTP POST的任何人也可以通过绕过jQuery验证的其他方式执行HTTP POST。例如，我可以使用System.Net.HttpWebRequest将一些数据发送到您的服务器，并使用适当的cookie将恶意内容注入表单字段。我必须正确设置__EVENT_VALIDATION和__VIEWSTATE字段，但如果我成功，我将绕过验证。
如果您没有服务器端数据验证，那么您实际上根本没有验证输入。 jQuery验证对于用户体验很好，但不是真正的防线。
对于像自由格式注释字段这样的输入尤其如此。您肯定希望确保该字段不包含HTML或其他恶意脚本。作为防御的额外衡量标准，当您使用像AntiXss这样的库在Web应用程序中显示评论内容时，您也应该转义评论内容（参见http://wpl.codeplex.com/）。
答案 8 :(得分：0)
在客户端验证和服务器端验证方面，我的意见是客户端验证只是为了确保表单填写正确并且用户可以篡改表单并绕过您在javascript中执行的验证
在服务器端，您实际上可以确保实际上要存储此数据并以深度方式验证它并检查相关数据库表，以确保始终使用从客户端获取的任何数据集对数据库进行规范化。我甚至会说服务器端比客户端更重要的是不向用户显示您在表单中查找的内容以及如何验证数据。
总结一下，我建议双方进行验证，但如果我必须在两者之间进行选择，我会建议服务器端验证，但这可能意味着您的服务器可能会执行您可能无法验证的其他验证客户端
答案 9 :(得分：0)
回答你的第二个问题：
您需要使用白名单来阻止传入评论中的恶意输入。
.NET Framework请求验证可以很好地阻止传入POST请求中的XSS有效负载。但是，它可能不会阻止其他恶意或错误的HTML进入评论（图像标记，超链接等）。
因此，如果可能的话，我会在服务器端为允许的字符设置白名单验证。一个正则表达式应该覆盖这个就好了。你应该允许A-Za-z0-9，空白和一些标点符号。如果正则表达式无法匹配，则向用户返回错误消息并停止事务。关于SQL注入：在这种情况下我会允许撇号（除非你在评论中喜欢可怕的语法），但是将参数化SQL查询的代码注释放在以下的效果中：“这是对SQL的唯一保护，所以当时要小心修改“。您还应该锁定Web进程使用的数据库帐户的权限（仅读/写，而不是数据库所有者权限）。我不会做的是尝试对输入进行黑名单验证，因为这样做非常耗时（请参阅http://ha.ckers.org/xss.html处的RSnake的XSS备忘单，了解您需要预防的事项数量仅适用于XSS）。
在.NET框架和您自己的白名单验证之间，您应该可以免受基于HTML的攻击，例如XSS和CSRF *。使用参数化查询将阻止SQL注入。如果评论数据涉及任何其他资产，您可能需要设置更多控制措施，但这些控制措施涵盖了与您概述的基本数据提交表单相关的攻击。
另外，我根本不会尝试“清理”数据。很难做到正确，用户（如上所述）在未经他们许可的情况下修改数据时就会讨厌它。当数据验证失败时，为用户提供明确的错误消息更安全，更有用。如果您将他们的评论放回页面供他们编辑，HTML会对输出进行编码，这样您就不会受到反射XSS攻击的攻击。</ p>
与往常一样，OWASP.org（http://www.owasp.org）是webappsec相关所有内容的良好参考。查看他们的十大和开发指南项目。
* CSRF可能不是您的直接关注，因为您网站的欺诈性帖子可能对您无关紧要，但是防止XSS的另一个好处是保持针对其他网站的CSRF有效负载不会从您的网站托管。