黑客如何欺骗前端验证?

信息安全 Web应用程序 api 科尔斯 同源策略
2021-08-09 04:48:18

我一直在阅读:将验证放在后端。前端验证用于 UX,而不是安全性。这是因为不良行为者可以欺骗前端验证。但是我很难理解一个坏演员是如何欺骗它的。

我从没想过太多,我只是认为这意味着有人可以通过像 Postman 这样的请求来绕过验证。但后来我了解到,使用同源策略是不可能的。* 那么这些不良行为者是如何提出同源请求的呢?

我能想到的唯一其他想法是不良行为者可以进入代码(例如:在 DevTools 上)并在那里编辑请求并从同一站点发出已编辑的请求。他们就是这样做的吗?

在实践中欺骗前端验证是什么样的?他们如何提出绕过 COR 的请求?

*更新:关于SOP是什么,我在这里错了。它不会阻止来自其他来源的请求,前邮递员。下面的许多答案阐明了 SOP 的用途。

4个回答

我认为您对 CORS 和 SOP 所做的事情感到非常困惑……两者都与这些攻击无关。

有很多方法可以绕过客户端验证。HTTP 只是一个字节流,在 HTTP 1.x 中它们甚至是人类可读的文本(至少对于标头而言)。这使得伪造或操纵请求变得微不足道。以下是按粗略类别分组的方法子集:

在浏览器中绕过验证

  • 浏览到您的站点并输入无效值。使用浏览器开发工具删除验证事件或操纵它们的执行以通过验证。提交表格。
  • 使用浏览器开发控制台从站点发送请求,就像通过经过验证的表单一样,但输入未经验证(只需直接调用发出请求的函数)。
  • 使用浏览器开发工具“编辑并重新发送”请求,在重新发送之前,将正文中的有效值更改为无效值。
  • 对于 GET 请求:只需在地址栏中输入任何带有无效参数的 URL。
  • 对于使用非同一站点 cookie 进行身份验证的 POST 请求:创建一个网页,该网页使用预期值(包括任何 CSRF 保护令牌)但使用无效值向您的服务器发送 POST,将其加载到浏览器中,然后提交。

使用非浏览器工具绕过验证

  • 将浏览器设置为通过拦截代理运行(与安全行业中的大多数一样,我通常使用 Burp Suite,但您也可以使用 Fiddler 等其他工具)。捕获出站请求,篡改字段以使其无效,然后将其发送出去。
  • 再次使用拦截代理,但这次使用修改过的无效值重播先前的请求(在 Burp 中,这正是中继器工具的用途)。
  • 右键单击浏览器开发工具的网络历史记录中的请求,选择“复制为 cURL”,将生成curl的命令粘贴到命令行中,编辑已验证的字段以使其无效,然后按 Enter 发送。

从头开始制作恶意请求

  • 使用 Burp Repeater,为您的站点指定协议、域和端口。添加必要的标头,包括授权所需的任何 cookie 或其他标头。添加具有无效值的所需参数。点击“发送”。
  • 使用curl,向您的站点发送一个请求,其中包含您想要的所需标头和任何正文,包括无效值。
  • 使用ncat,使用 TLS 在端口 443 上打开到您的站点的连接。输入 HTTP 顶行、标题和正文(毕竟,它只是文本,尽管在发送之前它会被加密)。如果需要,发送文件结尾输入(通常服务器会立即响应)。
  • 使用 TCP 或 HTTP 客户端库(从在 Node 上运行的 JS 到完整编译的 golang 二进制文件)以任何语言编写一个小脚本/程序,创建一个包含所有必需标头和无效字段的请求,并将其发送到您的服务器. 运行脚本/程序。

SOP 仅适用于使用浏览器发送请求并且请求源自托管在与请求目的地不同的来源(域、协议和端口的组合)的网页时。即便如此,SOP 主要防止原始页面看到响应;它不能阻止攻击的发生。如果您是试图通过客户端验证的攻击者,那么您可以从您正在攻击的源发送请求,而 SOP 完全无关紧要。或者只是从不是浏览器的东西(如代理、或curl、或自定义脚本)发送请求;这些甚至都没有SOP。

CORS 是一种在 SOP 中戳洞的方法(CORS 不会增加任何安全性;它是一种部分放松 SOP 安全性功能的方法),因此除非 SOP 相关,否则它甚至无关紧要。但是,在许多情况下,您可以使用无效参数发出跨域请求(例如,我创建自己的攻击页面并将浏览器指向它,然后使用它向您的站点提交无效请求),因为对于大多数情况请求,SOP 仅限制您是否可以看到响应 - 即使服务器根本不允许 CORS,您也可以跨域发送请求 - 而且通常不需要看到响应。

身份验证后从浏览器中提取授权令牌(cookie、标头值等)很容易(只需检查开发工具中的网络流量,或使用代理)。请记住,为了使验证成为问题,攻击者必须能够通过浏览器使用您的网站,这可能意味着他们可以进行身份​​验证。或者只是使用或其他方式提交身份验证请求curl,从响应中刮取返回的令牌,并将其用于恶意无效请求;根本不需要浏览器!

浏览器无能为力(就向服务器发送请求而言),我无法通过一些常见的开源实用程序在 shell 提示符下完成。

编辑:正如@chrylis-cautiouslyoptimistic 指出的那样,这包括在请求中欺骗 Origin 标头。虽然 Origin 标头通常不能在浏览器中配置 - 它是在发出某些类型的请求时由浏览器自动设置的 - 可以在发送请求后对其进行编辑(通过拦截或重新播放请求),或者简单地首先伪造它。任何基于此标头的存在、不存在或值的保护措施只有在攻击者通过不知情的受害者浏览器间接提交请求的情况下才有效(如 CSRF 的情况),通常是因为攻击者可以t 对站点进行身份验证或想要通过另一个用户的帐户进行攻击。对于任何其他情况,攻击者可以简单地选择要给出的值(如果有)作为 Origin。

编辑 2:正如@Tim 所提到的,SOP 和反 CSRF 措施等都是为了保护网站用户免受互联网上其他人的攻击(同一网站的另一个用户,或者想要利用您对网站的访问)。当授权用户是攻击者并且目标是站点本身或其所有用户时,它们根本不提供任何保护,通过存储的 XSS、SQL 注入或恶意文件上传(人们有时尝试通过客户端验证来防止)。

也许一个非常简短的答案也会有所帮助。

我从没想过太多,我只是认为这意味着有人可以通过像 Postman 这样的请求来绕过验证。但后来我了解到,使用相同的原产地政策是不可能的。

同源策略是浏览器自愿实施以保护其用户的策略。它不会影响 Postman,因为 Postman 没有实施此政策。所以,你原来的想法是正确的。

邮递员和同源政策不是障碍。为了理解这一点,我需要解释为什么作为开发人员,您实际上从不信任客户端/前端。

前端和后端信任

如果有人控制一台计算机,他们就控制它向服务器发送的内容。这就是字面意思:它的每个最后一个字节,每个最后一个标头或请求,表单中的每个最后一个 POST 字段或 URI 中的 GET 参数,每个 Web 套接字和连接,每个最后的时间(在广泛的时间限制内,这里不是问题)。

他们可以让那台计算机按字面意思发送后端,无论他们想要什么,都可以按需发送。任何 GET。任何 POST。任何标题字段。任何事物。它们可以包含任何标题。任何来源。他们选择并知道的任何 cookie 信息。从字面上看,任何东西。大多数用例的常见例外可能是物理“黑匣子”加密卡/密钥和客户端的 IP 地址,如果在会话期间检查,这两者都是更棘手的障碍 - 甚至 IP 通常可以通过各种方式被欺骗,尤其是如果他们不关心回复。

结果是,从安全角度来看,您不能信任客户端发送的任何内容您可以提高标准报价很多,足以满足大多数日常使用。安全传输 (TLS/HTTPS),如果有人控制路由经过的中间计算机,则很难修改、拦截或更改流量。一个实施良好的操作系统和浏览器,可以阻止特定网页之外的脚本或恶意软件在本地进行干扰。证书检查一端或两端。对可能附加的内容进行身份验证的安全网络。

但其中每一个都在提高标准,而不是绝对的防御。每一个都曾经被打破过,现在有时会被打破,将来也会被打破。也没有保证没有错误和漏洞。没有人可以防御在客户端故意或无知地破坏客户端 PC 上的防御的用户、恶意软件或 rootkitted 远程访问,因为这样的用户通常可以更改或绕过任何操作系统或浏览器被编程执行的操作。没有一个是真正完美的防御。

因此,如果您有任何带有后端和前端的软件或基于 Web 的系统,那么您不信任客户端提供的数据是一条黄金法则您在后端收到时重新检查它。如果请求是访问或发送网页或文件,可以吗,是否应允许该会话访问该文件,文件名是否有效?如果请求是要处理的一些数据或表单,所有字段是否合理且包含有效数据,是否允许该会话进行这些更改。

您不信任不受您自己安全已知控制的事物。

服务器,您将大体上信任(您管理操作系统和安全性,或拥有可信赖的合作伙伴)。但是客户和更广泛的网络根本不信任。甚至对于服务器,您也对其进行了安全检查,无论是恶意软件和行为检测、访问控制还是网络扫描软件,因为您也可能错了。

因此,为了方便客户端,您可以在客户端浏览器/应用程序(前端)进行验证,因为大多数客户端都是诚实的,并且可以在浏览器或应用程序中快速检测到许多错误。

但是您在服务器(后端)进行验证以实际检查请求或数据是否有效并且应该被处理或拒绝

也就是说,你的答案是...

你问它是怎么做的。执行此操作的软件可以通过多种方式完成 - 恶意软件、蓄意的用户行为、错误配置的客户端系统/软件、拦截计算机/代理。

但是无论怎么做,这是在客户端中利用这些问题的基本过程,使任何客户端数据包从根本上不可信(包括来源和引用字段),并且无法信任它们。它不包括 OP 范围之外的外部问题,例如证书滥用。

  1. 研究真正的回复/数据包/请求/帖子在应用程序中的样子。
  2. 使用内置浏览器工具、浏览器扩展、透明代理/代理应用程序修改数据包,或基于它创建一个手工制作的请求,需要不同的标头。
    (毕竟,后端实际上并不知道“真实”值应该是什么,或者“真实”来源或引用者是什么,它只知道数据包*说*它们是什么,或者来源或引用者是什么.这需要 15 秒到 2 分钟来修改地球上我想要的任何东西,或者如果它是由软件完成的,则不到一毫秒。)
  3. 修改或伪造任何其他需要的东西,或制作任何数据包的自定义版本,然后发送它们(预先准备好或当时修改)
  4. 完毕。
  1. 您的后端可通过网络访问。这意味着我不需要使用你的 frontend我可以找出它使用的端点,以及请求的格式,并使用我自己的工具发送前端永远不允许的请求。您绝不能假设到达您的后端的请求实际上来自您自己的应用程序。从字面上看,它可以是任何东西。

  2. 您的前端在我的浏览器中运行。你没有我的浏览器,我有。你有一个最大宽度的文本字段?我可以在检查器中编辑它。isValid()您有一个在提交时调用的 500 行函数?我可以打开控制台并删除处理程序,或者执行isValid = function() { return true }. 或者更改您的整个 JavaScript 并通过透明代理访问您的站点,该代理将您的代码版本替换为我的版本(但直接传递其他请求)。或其他一百万种事物中的一种。您不能信任任何不受您直接控制的计算设备。

  3. 同源策略保护免受站点 A 的影响,该站点 A 想要尝试通过使用我的浏览器(已向站点 B 进行身份验证)访问我在站点 B 上的数据来完成工作。它不能保护免受任何伤害。可以随心所欲地违反同源政策。未经我的许可,第三方代码不应违反它。