为什么我们需要客户端和服务器端验证？ [关闭]答案

【问题标题】：Why do we need both client side and server side validation? [closed]为什么我们需要客户端和服务器端验证？ [关闭]
【发布时间】：2013-03-29 03:47:15
【问题描述】：

使用验证器同时使用客户端验证 (JavaScript) 和服务器端验证的论点是：如果客户端浏览器不支持 JavaScript，则用户无法使用客户端验证。

我的问题是这个论点在实践中有多好？理论上这是有道理的，但实际上，如果在浏览器中禁用 JavaScript，那么大多数网站功能甚至都无法工作。如果没有 JavaScript，用户甚至可能无法加载页面，更不用说提交表单了。

【问题讨论】：

这可能更适合Programmers。投票迁移。也可能重复：stackoverflow.com/questions/3483514/…
本质上，如果将其视为安全问题，则不存在客户端验证之类的东西。没有关闭 JavaScript 的浏览器可能会杀死互联网上 95% 的网站。几乎没有网站似乎有非 javascript 浏览的后备。
@Allendar：大网站都有。你会惊讶地发现 Facebook（好吧。大部分 facebook。有些位不）在没有 JS 的情况下工作。它是中档网站，而且“omg web2.0 很棒”的网站没有……这对他们和其他人来说都是一种耻辱。然而，有些人永远学不会:-(
Mandatory XKCD
看看这个。 dzyngiri.com/client-side-vs-server-side-validation

标签： javascript validation web-applications client-side-validation server-side-validation

【解决方案1】：

客户端验证只是避免了客户端“但我全部填写了它并没有告诉我任何信息！”。它实际上不是强制性的，实际上，客户端验证是一个非常新的东西（阅读：5 岁或更少）。实际上，它所做的只是阻止您的客户端（启用 JS）在重新加载页面之前知道表单是否正常。如果 AJAX 在游戏中，那就不同了——它可以让您节省带宽以及在提交前向用户提供反馈。最后，如果您正在构建严格的客户端、点对点交换应用程序（想想游戏），您将需要客户端验证以防止客户端作弊。

服务器端验证也很重要，因为通过关闭 JavaScript 可以完全绕过客户端验证。在某种程度上，JS 驱动的验证是一种方便和美观/美观的改进，不应该依赖于。此外，为了禁用或绕过最复杂的 JS 验证，在本地编辑页面源代码也很简单。

如果您不进行服务器端验证，用户可以做什么？任何事情，取决于您如何使用他们的数据。您可能允许用户删除整个数据库（或者更糟糕的是，泄露它们），修改他们喜欢的任何内容（或者更糟糕的是，阅读他们喜欢的任何内容。目录遍历缺陷是顽皮的人极其常见的入口点），并随意提升他们的权限。你想冒这个风险吗？不验证用户输入就像信任别人而不是在你的房子上安装锁一样。

【讨论】：

【解决方案2】：

验证应始终在服务器端执行 - 您永远不能信任客户端验证。

客户端验证总是提供更好的用户体验 (UX)，因此用户不必仅仅因为表单中的值是'无效 - 它使事情更有活力。

由于您甚至不需要浏览器来发出请求，而您的网站依赖于 JS 才能正常工作，因此您将需要服务器端验证并清理所有用户输入，以防您担心自己的数据库不被盗用。

现在由您决定是否要提供带有动态客户端验证提示的 UI。

【讨论】：

@Kaushik 好吧，当我针对 SQL 注入测试我的页面时，我通常使用 TamperData，我还使用 Node.js（使用 form-data module）从头开始生成请求。在实践中，任何程序都可以发出 http 请求并发送任意 GET/POST 数据——我不太确定这如何适用于 java 后端，但应该不会有太大的不同。
验证可以在客户端完成，例如很多浏览器支持HTML5表单验证属性-html5rocks.com/en/tutorials/forms/constraintvalidation
@andyb “验证”在这个意义上只是用户体验。可以通过 Chrome Dev Tools / Firebug 禁用此类约束来轻松绕过这一点，毕竟这些只是可以通过 JavaScript 访问和修改的 DOM 元素属性。
它叫做"constraint validation"。我试图解释说，我认为您关于“验证只能在服务器端执行”的声明自规范以来具有误导性。称之为“验证”
@andyb 是的，我的意思是验证到达服务器的输入。将尝试改写。

【解决方案3】：

始终保护您在服务器上的输入。这并不总是与禁用 JavaScript 的用户有关，而且他们可能会破坏服务器。

例如，如果网站对 <input> 进行了 JavaScript 最大长度检查，则用户可以禁用该检查，从而发送比您的服务器和/或数据库预期更多的数据。这可能会通过长时间占用服务器线程的大型 POST 使服务器过载，它可能会暴露数据库中的弱点，例如违反数据库约束可能会暴露有关任何持久性信息的详细信息。更糟糕的是，如果没有约束，用户可能能够执行注入攻击。

另一个例子是有人使用外部 HTTP 工具向您的服务器发送请求，完全绕过任何 JavaScript。我在开发过程中一直使用 Chrome 的 Advanced REST Client 来测试 JSON API。

通过 JavaScript 进行客户端验证只是向使用网站的人提供关于他们与网站交互的任何信息的更快反馈的一种方式。在传统的客户端-服务器通信中，由于上述原因，它应该不是唯一的验证。

【讨论】：

【解决方案4】：

如果用户禁用了 javascript 是他自己的问题，他决定单独禁用 javascript 是有原因的......因此，当您制作网站时，您必须始终牢记您的网站必须有效有和没有 javascript 的用户。需要双方验证的原因有很多，其中一些是：

用户已禁用 javascript
恶意用户故意删除了 javascript 以利用系统
通过 javascript 验证，您可以减少网站和客户端之间的数据流量。
当然，通过服务器验证，您可以一劳永逸地确保数据正确

有可能拥有一个同时使用 javascript 和“旧”技术的网站对每个用户和每个浏览器都有效。

【讨论】：

【解决方案5】：

客户端验证是一种具有即时字段验证的高度交互表单的解决方案，但它不会阻止恶意用户向服务器注入和发布无效格式的数据。重要的是，您的服务器端脚本验证用户所做的一切，否则您的网站将面临 SQL 注入攻击、XSS 攻击、用户做他们不应该做的事情等。

【讨论】：