【问题标题】:Why is client-side validation not enough?为什么客户端验证还不够?
【发布时间】:2011-03-29 20:25:29
【问题描述】:

我看到here那个:

您可能已经知道,依靠 仅在客户端验证上 非常糟糕的主意。始终执行 适当的服务器端验证为 好吧。

您能解释一下为什么必须进行服务器端验证吗?

【问题讨论】:

标签: validation server-side client-side-validation


【解决方案1】:

编写服务器应用程序有一个简单的规则:永远不要相信用户数据。

您需要始终假设恶意用户以您不希望的方式访问您的服务器(例如,在这种情况下,通过手动查询通过 curl 而不是预期的网页)。例如,如果您的网页试图过滤掉 SQL 命令,攻击者已经很好地暗示了通过 SQL 命令传递输入可能是一个很好的攻击媒介。

【讨论】:

    【解决方案2】:

    伙计,假设一个人在他的浏览器中关闭了 javascript,验证就失效了。然后如果他通过那个表格向服务器端发布一些恶意内容。它将导致严重的漏洞,如 sql 注入或 xss 或任何其他类型的问题。因此,如果您要实现客户端 javascript 验证,请注意。

    谢谢

    【讨论】:

      【解决方案3】:

      客户端验证以安全浏览器、客户端语言或 HTML 5 为前提。所有这些元素都可能被禁用、部分不可用或根本未实现。每个人都必须通过每个浏览器使用您的网站。 服务器端语言更安全,而且 - 如果它们不是错误 - 验证肯定会更安全和正确。

      【讨论】:

        【解决方案4】:

        一般来说,最好让应用程序的每个部分都进行自己的检查/验证。

        客户端检查有利于最大化用户体验并加快向客户端反馈他们需要修复的内容,并减少服务器端检查中遇到的问题。

        然后在服务器端代码的每个主要转换点,您也应该在那里进行检查。验证应用程序代码中的输入,最好通过whitelist input validation,然后与数据库进行任何交互,使用参数化查询进一步确保不会出现问题。

        【讨论】:

          【解决方案5】:

          客户端验证是为了避免客户端输入错误的数据。服务器端验证是为了避免服务器处理错误的数据。在这个过程中,它还为提交过程引入了一些安全性。

          【讨论】:

            【解决方案6】:

            服务器端验证是必须的,因为客户端验证不能确保未经验证的数据会到达服务器。

            客户端验证是不够的,因为它的作用范围非常有限。验证仅在浏览器用户界面中执行。

            Web 服务器“侦听”并接收包含来自浏览器的数据的 HTTP 请求,然后对其进行处理。

            恶意用户可以通过多种方式发送恶意 HTTP 请求。甚至不需要浏览器。

            在浏览器中使用 JavaScript 执行的客户端验证是一项重要的可用性和用户界面增强功能。但它不会阻止知道如何规避浏览器默认行为(即构建将发送到服务器的 HTTP 请求)的用户发送恶意数据。这可以通过一些浏览器插件、使用 cURL 等轻松完成。

            【讨论】:

              【解决方案7】:

              您应该对任何数据执行服务器端验证,如果这些数据无效,可能会对发布数据的实​​体以外的任何人造成伤害。客户端验证可能适用于无效数据对发布它的实体以外的任何人都没有不良影响的情况。除非您可以确定不良数据的不良影响不会传播到发布它的实体之外,否则您应该使用服务器端验证来保护自己免受破坏者或其他流氓客户端的侵害。

              【讨论】:

              • 你需要验证它,即使它只会伤害提交者,因为跨站点请求伪造攻击的可能性。 en.wikipedia.org/wiki/Cross-site_request_forgery
              • @Dave Sherohman:感谢您的更正,虽然我不确定我是否理解它。如果流氓用户代理提交的虚假信息除了将虚假数据返回给流氓用户代理之外没有任何作用,那将如何启用攻击?假定谁信任谁,以及允许发生流氓用户代理无法自己做的恶作剧?
              • 想象一个 rouge 代理构造了一个无效的查询,并诱使目标执行该查询,可能是通过隐藏的 iframe 虚假响应将来自您的域,例如可以访问您的应用程序 cookie。如果虚假响应允许注入客户端代码,则攻击者可以窃取 cookie 并随后利用这些新信息发起进一步的攻击。
              • 对不起,这个例子不是特别清楚(它提出了应该通过正确的输出转义而不是输入验证来处理的问题)。我要说明的一点是,构建恶意查询的人可能不是执行恶意查询的人,因此您仍然必须谨慎行事。最近有人在这些方面捣乱的例子:giorgiosironi.blogspot.com/2010/08/… 攻击者试图通过分发恶意查询让其他人执行来给 Google 制造负面新闻。
              • @Wildcard:我想我明白道格拉斯的意图,但他的后续例子很糟糕。更好的问题可能是基于提交数据构建客户端 Javascript 的网站。如果提交故意格式错误的数据可能导致服务器向客户端发送有害代码,则服务器应执行足够的验证以防止这种情况发生,即使代码的影响只会对客户端有害。
              【解决方案8】:

              因为用户代理(例如浏览器)可能是假的。创建自定义应用程序以创建具有任意标头和内容的 HTTP 请求非常容易。它甚至可以说它是一个真正的浏览器——你无法分辨。

              你能做的就是看请求的内容,不检查你就不知道它是有效的。

              【讨论】:

              • 您还可以检查会话变量——不仅仅是内容。
              【解决方案9】:

              客户端验证 - 我假设您在这里谈论网页 - 依赖于 JavaScript

              JavaScript 支持的验证可以在用户的​​浏览器中关闭,由于脚本错误而失败,或者被恶意规避而无需付出太多努力。

              另外,表单提交的整个过程都是可以伪造的。

              因此,永远无法保证到达服务器端的数据是干净且安全的数据。

              【讨论】:

              • 它适用于所有拥有客户端的事物,例如在线游戏,因此,正如@Pascal 所说,您不能信任客户端。而且,就网页而言,它们是最容易伪造的 =/
              【解决方案10】:

              您正在与之交谈的客户可能不是您认为您正在与之交谈的客户,因此它可能会忽略您要求它执行的任何验证。

              在网络环境中,用户不仅可能在其浏览器中禁用了 javascript,而且您可能根本没有与浏览器对话 - 您可能会从机器人获取表单提交这是在根本没有看到表单的情况下发布到您的提交 URL。

              在更广泛的背景下,您可能正在处理一个被黑客入侵的客户端,该客户端正在发送真实客户端永远不会发送的数据(例如,用于 FPS 游戏的瞄准机器人),或者甚至可能是由反向工程人员创建的完全自定义客户端您的有线协议对您期望它执行的任何验证一无所知。

              【讨论】:

                【解决方案11】:

                以防攻击者发布自己的表单。

                【讨论】:

                  【解决方案12】:

                  您可以关闭/编辑 JavaScript。

                  【讨论】:

                    【解决方案13】:

                    在不针对 Javascript 和 Web 客户端以及更广泛地解决问题的情况下,服务器应负责维护自己的数据(与底层数据库一起)。

                    在客户端-服务器环境中,服务器应该准备好接受许多不同的客户端实现可能与之对话的事实。考虑一个交易进入系统。客户端可以是 GUI(例如交易输入系统)和(例如)数据上传客户端(从 .csv 文件加载多个交易)。

                    客户端验证可以通过多种不同的方式执行,但并非所有方式都正确。因此,服务器不必信任客户端数据并自行执行完整性检查和验证。

                    【讨论】:

                      【解决方案14】:

                      任何了解基本 javascript 的人都可以绕过客户端。

                      客户端只是用来改善用户体验(无需重新加载页面验证)

                      【讨论】:

                        猜你喜欢
                        • 2018-11-28
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 2011-04-30
                        • 1970-01-01
                        • 1970-01-01
                        相关资源
                        最近更新 更多