7

是否有任何高级理由同时对 Web 应用程序进行客户端和服务器端验证？

4

8 回答 8

11

因为您的客户端验证可能会被破坏。

例如 - 在网络上，如果您使用 javascript 进行验证，则关闭 javascript 或使用 FireBug 等工具更改其工作方式非常容易。

使用其他客户端/服务器方法的事件，可能会破坏数据链接，并且可以在到达服务器的途中更改“验证”数据（中间人攻击）。

一般来说，格言“从不信任客户端”是您需要始终在服务器上进行验证的原因。

你可能会问，为什么要在客户端验证？为了提供即时反馈。

于 2010-11-02T10:53:53.383 回答
3

用户可以在本地修改验证 javascript（保存页面并用它做任何事情）或者可以在浏览器中关闭 javascript。所以在这种情况下，客户端验证是没有用的。因此，您也应该在服务器上进行验证

于 2010-11-02T10:53:33.603 回答
3

客户端验证用于以下方面
1) 数据符合长度和格式限制
2) 即时指示或反馈给用户

服务器端验证
1）针对业务逻辑的更高级验证
2）检查标准的任何变化。例如，您从亚马逊订购了一本书，并且在您结帐后，您会收到该书缺货的指示，因为其他人会在此之前购买它
3）检查目标用户是否已发布数据。可以操纵 cookie 和 javascript 之类的客户端内容，因此服务器确实需要对通过的数据进行身份验证和污点检查。

因此，需要服务器端验证作为抵御恶意数据的主要防线，并根据高级业务逻辑检查数据。

于 2010-11-02T11:05:38.027 回答
2

客户端验证为用户提供即时反馈，而无需等待页面加载。但是，如果客户端禁用了客户端脚本（例如禁用了 JavaScript），验证将不会触发，这就是您需要服务器检查值的原因。

于 2010-11-02T10:54:15.927 回答
2

客户端将在到达服务器之前（理论上）消除大部分验证问题（尽管禁用/编辑 JavaScript 等情况并非总是如此）。这将通过将责任放在客户端设备上来执行验证，从而消除服务器上的任何“紧张”/不必要的处理。

服务器端将捕获由于某种原因未被客户端验证捕获的任何验证问题。

于 2010-11-02T10:55:24.373 回答
2

客户端验证是一个加号，但不是必需的。您必须使用服务器端验证 (ssv)，因为当您接受用户信息时，您应该始终将其视为“敌对”。如果该数据也被输入数据库，ssv 是您的最后一道防线，因为您不希望数据库中有垃圾或无效数据。

客户端验证不是防弹的，因此如果某些东西在客户端得到验证，这并不意味着它在到达您的服务器时是有效的。

于 2010-11-02T10:59:43.403 回答
2

实时客户端验证的目的（即当用户从一个字段移动到另一个字段时，而不是在用户点击提交之后）是为了尽快给用户反馈。例如，如果社会安全号码需要 9 位数字，而用户输入了 8，那么您不想等到用户完成表单的其余部分并点击提交来指出错误，即使验证发生在客户端。等到 SUBMIT 之后验证客户端几乎是没有意义的——它所做的只是节省您的服务器和带宽。在出现错误时指出错误通常会导致更高的表单完成率，因为它总体上对用户来说是一种更简单的体验——不会有错误列表：“请更正以下所有错误”。但是您仍然需要进行服务器端验证以确保无论如何数据的完整性。夜总会保镖站在俱乐部门前，而不是在街对面的停车场。

于 2010-11-02T11:21:45.000 回答
0

如果您的应用程序在数据库中有多个表，那么您的服务器端验证可能只是一组限制（数据表设计的一部分）。我们可能认为我们在服务器端没有任何验证，因为它不是中间服务器层，而是数据库层限制。

那么我们可以说，具有关系数据库的优势——基于Integrity（我们知道我们的数据结构是安全的）。在大多数情况下，我们可能只使用客户端验证来向客户端提供对其操作的实例反馈。在服务器端层、任何服务器端代码中的控制器中不进行额外验证可能不是关键问题。

因此，我们可以说，对于某些/大多数情况，我们可能只使用客户端验证。服务器端验证是 - 特殊情况，例如：当客户提交购买表格时检查是否已经购买了东西。

在双方都进行验证时不要重复自己，这不是一个坏主意。

当然，有些应用程序需要对其数据进行大量关注，那么不仅服务器端验证很重要（如业务模型安全的一部分，而且大多数用例的测试覆盖率 - 对于客户端的输入。

但如果它只是一个有多种形式的网站......那么我相信数据库限制和客户端验证是不错的选择。

于 2013-02-18T19:24:30.503 回答