与服务器端验证相比，为什么客户端验证存在安全风险？

Question

我不太明白为什么客户端验证是一个潜在的安全风险或比服务器端验证更大的安全风险？谁能给我一些场景？

Answer 1

理想情况下，您应该同时做客户端和服务器端，而不是其中之一。如果我们看看这 3 个场景，两者都是唯一安全、用户友好的方式：

仅限客户端：如前所述，如果有人想向您的服务器发送格式错误的数据（例如 SQL 注入），绕过这些验证并不需要太多。 NoScript 不会运行 javascript 验证代码，并且一些浏览器允许用户主动更改所有加载的 javascript 和 html，因此用户可以从控件中解开验证 javascript。

仅服务器端：这比仅客户端更安全，但降低了用户友好性。他们必须将表单发送到服务器，对其进行验证并收到错误页面返回，说明特定字段无效。令人讨厌的是，如果这些字段中的任何一个是密码字段，则默认情况下不会重新填充它们的值。例如，假设用户没有在帐户创建表单中正确输入电话号码。当服务器返回有关电话号码错误的页面时，用户会看到，更正电话号码并再次点击提交，只是收到另一个关于未输入密码的错误页面（并在第二次再次输入文本框），即使这不是最初的问题。

客户端和服务器端：您可以获得服务器端验证的安全性，用户将难以干预的内容，以及无需提交页面的输入验证的用户友好性（无论您是否通过纯本地验证javascript 或 AJAX)。

如果您绝对必须选择一个，那么服务器端将是您的选择。但是您永远不必选择其中一个。

Answer 2

使用各种工具，例如Fiddler、Noscript、Web Developer 等，我可以禁用客户端 javascript 验证，并修改发送到服务器的数据。根据数据的类型和服务器对其的处理方式，可能会发起 SQL 注入攻击、尝试破坏服务器安全性或只是存储虚假数据。

一个轻量级示例：假设您有客户端验证以确保邮政编码为 5 位或 5+4 位。如果我禁用客户端脚本，我可以保留我的 24 位值。如果您的服务器没有进一步检查该值，并且数据库能够存储所有 24 位数字，那么我已经保存了虚假数据。

Answer 3

如果您只在客户端进行验证，有人可能会禁用 javascript（或更改 js 代码，例如使用 firebug）。因此，所有在 js 中进行的验证都是无用的，用户可以在您的系统中插入无效数据。

Answer 4

我假设您说的是网络场景？

如果您使用 Javascript 进行客户端验证，如果用户禁用了 Javascript，会发生什么情况？然后他们可以将数据提交给尚未验证的服务器。

如果他们偷偷摸摸，他们甚至可以将数据直接发布到您的服务器（完全绕过您的页面）。

如果您在客户端验证之外或代替客户端验证之外进行服务器端验证，那么您就有额外的机会来防御这些情况。

Answer 5

实际上，客户端验证（结合服务器端验证）具有巨大的安全优势。如果您在客户端上仔细验证，那么进入服务器的所有流量都应该是干净的。除了攻击者。这使得进行更好的服务器端攻击检测成为可能。在大的计划中，这可能是您可以做的最重要的事情来保护您的应用程序。有关更多信息，请参阅 OWASP ESAPI IntrusionDetector 或 OWASP AppSensor。

哦，显然如果攻击在客户端开始和结束，例如基于 DOM 的 XSS，那么您将不得不在客户端进行验证和编码。