为什么客户端验证还不够?
I saw here that:
As you probably already know, relying
on client-side validation alone is a
very bad idea. Always perform
appropriate server-side validation as
well.
Could you explain why server-side validation is a must?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(14)
客户端验证 - 我假设您在这里谈论的是网页 - 依赖于 JavaScript。
JavaScript 驱动的验证可以在用户的浏览器中关闭,由于脚本错误而失败,或者毫不费力地被恶意规避。
此外,表单提交的整个过程都可以伪造。
因此,永远无法保证到达服务器端的数据是干净且安全的。
Client-side validation - I assume you are talking about web pages here - relies on JavaScript.
JavaScript powered validation can be turned off in the user's browser, fail due to a scripting error, or be maliciously circumvented without much effort.
Also, the whole process of form submission can be faked.
Therefore, there is never a guarantee that what arrives server side, is clean and safe data.
编写服务器应用程序有一个简单的规则:永远不要信任用户数据。
您需要始终假设恶意用户以您不希望的方式访问您的服务器(例如,在本例中通过通过
curl
手动查询而不是预期的网页)。例如,如果您的网页尝试过滤掉 SQL 命令,则攻击者已经得到了很好的提示,即使用 SQL 命令传递输入可能是一个很好的攻击媒介。There is a simple rule in writing server application: Never trust the user data.
You need to always assume that a malicious user accesses your server in a way you didn't intend (e.g. in this case via a manual query via
curl
instead of the intended web page). For example, if your web page tries to filter out SQL commands an attacker already has a good hint that it might be a good attack vector to pass input with SQL commands.任何了解基本 JavaScript 的人都可以绕过客户端。
客户端只是用来改善用户体验(不需要重新加载页面来验证)
anyone who knows basic javascript can get around client side.
client side is just used to improve the user experience (no need to reload page to validate)
您正在交谈的客户端可能不是您认为正在交谈的客户端,因此它可能会忽略您要求它执行的任何验证。
在网络环境中,用户不仅有可能在浏览器中禁用了 javascript,而且还有可能您根本没有与浏览器对话 - 您可能会从正在 POSTing 的机器人那里获取表单提交到您的提交 URL,而根本没有看到表单。
在更广泛的背景下,您可能正在处理一个被黑的客户端,该客户端正在发送真实客户端永远不会发送的数据(例如,用于 FPS 游戏的瞄准机器人),甚至可能是由对您的有线协议进行逆向工程的人创建的完全自定义的客户端它对您期望它执行的任何验证一无所知。
The client you're talking to may not be the client you think you're talking to, so it may be ignoring whatever validation you're asking it to do.
In the web context, it's not only possible that a user could have javascript disabled in their browser, but there's also the possibility that you may not be talking to a browser at all - you could be getting a form submission from a bot which is POSTing to your submission URL without ever having seen the form at all.
In the broader context, you could be dealing with a hacked client which is sending data that the real client never would (e.g., aim-bots for FPS games) or possibly even a completely custom client created by someone who reverse-engineered your wire protocol which knows nothing about any validation you're expecting it to perform.
在不特定于 Javascript 和 Web 客户端的情况下,为了更广泛地解决问题,服务器应该负责维护自己的数据(与底层数据库结合)。
在客户端-服务器环境中,服务器应该准备好接受许多不同的客户端实现可以与其通信的事实。考虑一个贸易录入系统。客户端可以是 GUI(例如交易输入系统)和(例如)数据上传客户端(从 .csv 文件加载多个交易)。
客户端验证可以通过多种不同的方式执行,但并非全部正确。因此,服务器不必信任客户端数据并自行执行完整性检查和验证。
Without being specific to Javascript and web clients and to address the issue more widely, the server should be responsible for maintaining its own data (in conjunction with underlying databases).
In a client-server environment the server should be ready for the fact that many different client implementations could be talking to it. Consider a trade-entry system. Clients could be GUIs (e.g. trade entry sysems) and (say) data upload clients (loading multiple trades from .csv files).
Client validation may be performed in many different ways, and not all correctly. Consequently the server shouldn't necessarily trust the client data and perform integrity checks and validation itself.
以防攻击者发布自己的表格。
In case the attackers post their own form.
您可以关闭/编辑 JavaScript。
You can turn off/edit JavaScript.
因为用户代理(例如浏览器)可能是假的。创建自定义应用程序来创建具有任意标头和内容的 HTTP 请求非常容易。它甚至可以说它是一个真正的浏览器——你无法区分。
您所能做的就是查看请求的内容,如果不检查,您就不知道它是否有效。
Because the user agent (e.g. browser) might be a fake. It is very easy to create a custom application to create an HTTP request with arbitrary headers and content. It can even say it is a real browser—you have no way of telling the difference.
All you can do is look at the content of the request, and if you don't check it you don't know it is valid.
服务器端验证是必须的,因为客户端验证不能确保未经验证的数据到达服务器。
客户端验证还不够,因为它的作用范围非常有限。验证仅在浏览器用户界面中执行。
Web 服务器“侦听”并接收来自浏览器的包含数据的 HTTP 请求,然后对其进行处理。
恶意用户可以通过多种方式发送恶意 HTTP 请求。甚至不需要浏览器。
在浏览器中使用 JavaScript 执行的客户端验证是一项重要的可用性和用户界面增强功能。但它不能阻止知道如何规避浏览器默认行为(构建将发送到服务器的 HTTP 请求)的用户发送恶意数据。这可以通过一些浏览器插件、使用 cURL 等轻松完成。
Server-side validation is a must because client-side validation does not ensure not-validated data will arrive in the server.
Client-side validation is not enough because its scope of action is very restrict. The validation is performed in the browser user-interface only.
A web server "listens" to and receives an HTTP request containing data from the browser, and then process it.
A malicious user can send malicious HTTP requests by many ways. A browser is not even required.
The client-side validation, performed using JavaScript, in the browser, is an important usability, user-interface enhancement. But it does not prevent malicious data to be sent by an user that knows how to circumvent the browser default behaviour of building the HTTP request that will be sent to the server. This can be done easily with some browser plugins, using cURL, etc.
一般来说,最好让应用程序的每个部分都进行自己的检查/验证。
客户端检查有助于最大限度地提高用户体验,加快向客户端反馈需要修复的问题,并减少服务器端检查中遇到的问题数量。
然后,在服务器端代码的每个主要转换点,您也应该在那里进行检查。验证应用程序代码中的输入,最好通过 白名单输入验证,然后使用参数化查询与数据库进行任何交互,以进一步确保不会出现问题。
In general, it's best for EVERY piece of an app to do it's own checking/verifications.
Client-side checks are good for maximizing the user-experience and speeding up the feedback to the client that they need to fix something, and to reduce the amount of problems encountered in the server-side checks.
Then at each major point of transition on the server-side code, you should have checks in place there too. Verify inputs within the application code, preferably via whitelist input validation, and then have any interactions with the database use parameterized queries to further ensure problems do not occur.
您应该对任何数据执行服务器端验证,如果无效,可能会对发布数据的实体以外的任何人造成伤害。客户端验证可能适用于无效数据不会对发布数据的实体以外的任何人产生不良影响的情况。除非您可以确定不良数据的不良影响不会传播到发布该数据的实体之外,否则您应该使用服务器端验证来保护自己免受破坏者或其他恶意客户端的侵害。
You should perform server-side validation on any data which, if invalid, could be harmful to anyone other than the entity posting the data. Client-side validation may be suitable in cases where invalid data would have no ill effects for anyone other than the entity posting it. Unless you can be certain that the ill effects from bad data will not spread beyond the entity posting it, you should use server-side validation to protect yourself against vandals or other rogue clients.
客户端验证是为了避免客户端输入错误的数据。服务器端验证是为了避免服务器处理错误的数据。在此过程中,它还在提交过程中引入了一些安全性。
Client sided validation is for saving the client from entering wrong data. Server sided validation is for saving the server from processing wrong data. In the process, it also introduces some security into the submission process.
客户端验证以安全的浏览器、客户端语言或 HTML 5 为前提。所有这些元素都可能被禁用、部分不可用或根本无法实现。每个人都必须使用每个浏览器来使用您的网站。
服务器端语言更安全,并且 - 如果它们没有错误 - 验证肯定会更安全和正确。
Client side validations presuppose a safe browser, a client side language, or HTML 5. All these elements could be disabled, partially unusable, or simply not implemented. Your website have to be used from every person, with every browser.
The server side languages are safer, and -if they aren't bugs- the validation will be surely safer and right.
兄弟,假设如果一个人关闭了浏览器中的 JavaScript,验证就会失效。然后如果他通过该表单向服务器端发布一些恶意内容。它将导致严重的漏洞,如 sql 注入或 xss 或任何其他类型的问题。因此,如果您要实现客户端 JavaScript 验证,请务必小心。
谢谢
Buddy , Suppose if a person turnsoff the javascript in his browser , the validation became dead . Then if he post some malcious content through that form to the server side . It will lead to serious vulnerabilities like sql injection or xss or any other type of problems . So beware if you are going to implement a client side javascript validation .
Thank you