黑客如何欺骗前端验证？

解答动态

• 

  我认为您对COR和SOP的工作非常困惑。。。两者都与这些攻击无关。有很多方法可以绕过客户端验证。HTTP只是一个字节流，在HTT .x中，它们甚至是人类可读的文本（至少对于头而言）。这使得伪造或操纵请求变得微不足道。下面是一些方法的子集，按粗略的c分类类别：验证在浏览器中浏览到您的站点并输入无效值。使用浏览器开发工具删除验证事件或操纵其执行以通过验证。提交形式.使用browser dev console从站点发送请求，就像通过已验证的表单一样，但输入未验证（只需直接调用发出请求的函数即可）。使用browser dev工具编辑并重新发送请求，在重新发送之前，将正文中的有效值更改为无效一个。为了GET请求：只需在位置中键入任何带有无效参数的URL酒吧使用非samesite Cookie进行身份验证的POST请求：创建一个网页，该网页使用预期值（包括任何CSRF保护令牌）向服务器发布，但使用无效值，在浏览器中加载，然后提交。绕过使用非浏览器工具验证将浏览器设置为通过拦截代理运行（与安全行业中的大多数工具一样，我通常使用Burp套件，但您也可以使用其他工具，如Fiddler）。捕获出站请求，篡改字段使其无效，并在其上发送好的。用再次使用拦截代理，但这一次使用修改过的无效值重放上一个请求（在Burp中，这正是Repeater工具的用途）。右键单击浏览器dev tools的网络历史记录中的请求，选择quot；，将生成的cURL命令粘贴到命令行中，编辑已验证的字段以使其无效，按Enter键以发送。制作来自scratchUsing Burp Repeater的恶意请求，请指定站点的协议、域和端口。添加必要的头，包括任何cookie或授权所需的其他头。使用无效值添加所需参数。单击quot；。使用curl，向您的站点发送请求，请求中包含所需的头和任何正文（包括无效值）想要。使用ncat，在端口443上使用TLS打开到站点的连接。键入HTTP顶行、头和正文（毕竟，它只是文本，尽管在发送之前会被加密）。如果需要，发送文件结尾的输入（通常服务器会立即响应）。使用TCP或HTTP客户机库（从节点上运行的JS到完整编译的golang二进制文件）编写一个小脚本/程序，创建一个包含所有必需头和无效字段的请求，并将其发送到服务器。运行脚本/程序。 SOP仅适用于使用浏览器发送请求，并且请求来自托管在不同于请求目的地的源（域、协议和端口的组合）的网页的情况。即便如此，SOP主要还是防止原始页面看到响应；它不能防止攻击的发生。如果您是试图通过客户端验证的攻击者，那么您可以从您攻击的源发送请求，而SOP则完全不相关。或者只是从非浏览器（如代理、curl或自定义脚本）发送请求；这些浏览器都没有SOP。
  CORS是一种在SOP中戳洞的方法（CORS没有添加任何安全性；它是一种部分放松SOP安全特性的方法），因此，除非SOP相关，否则这都无关紧要。但是，在许多情况下，您可以使用无效参数发出跨源请求（例如，我创建自己的攻击页并将浏览器指向它，然后使用它向您的站点提交无效请求），因为对于大多数请求，SOP仅限制是否可以看到响应—即使服务器根本不允许COR，也可以跨源发送请求—而且通常不需要看到响应。
  提取授权令牌（Cookie、标头值、，不管怎样）在验证后从浏览器中删除都很容易（只需在开发工具中检查网络流量，或者使用代理即可）。请记住，要使验证成为问题，攻击者必须能够通过浏览器使用您的站点，这可能意味着他们可以进行身份验证。或者只需使用curl或其他方法提交一个身份验证请求，从响应中删除返回的令牌，并在恶意的无效请求中使用它；根本不需要浏览器！
  EDIT：正如@chrylis cautiouslyoptimistic所指出的，这包括欺骗请求中的原始标头。尽管原始标头通常不可在浏览器中配置—它在发出某些类型的请求时由浏览器自动设置—但在发送请求后（通过拦截或重新播放请求）可以对其进行编辑，也可以在第一时间对其进行伪造。基于此头的存在、不存在或值的任何保护措施仅在攻击者通过无意中的受害者浏览器间接提交请求（如CSRF）的情况下有效，这通常是因为攻击者无法对站点进行身份验证或希望通过另一个用户的帐户进行攻击。对于任何其他情况，攻击者可以简单地选择什么值（如果有的话）作为来源。
  EDIT 2：正如@Tim所提到的，SOP和反CSRF措施都是为了保护网站用户免受互联网上其他人的攻击（同一网站的另一个用户，或者一个想利用你访问网站的外人）。当授权用户是攻击者，目标是站点本身或其所有用户时，它们根本不提供任何保护，例如通过存储XSS、SQL注入，或者恶意文件上传（人们有时会试图通过客户端验证来阻止这种情况）。
  
• 

  也许一个非常简短的答案也会有帮助。
  我从来没有考虑过这个问题，我只是认为这意味着有人可以通过对以下内容发出请求来绕过验证邮递员。但是后来我了解到，同一原产地政策这是不可能的。
  同源策略是浏览器自愿实现的保护用户的策略。它不影响邮递员，因为邮递员不执行此策略。因此，你原来的想法是正确的。
  
• 

  邮递员和同源政策不是障碍。为了理解这一点，我需要解释为什么作为一个开发人员，您实际上从不信任客户机/前端。
  前端和后端信任 如果有人控制一台计算机，他们就控制它向服务器发送的内容。这是字面意义上的：它的每一个字节，每一个报头或请求，表单中的每一个POST字段或URI中的GET参数，每一个web套接字和连接，每一个最后的时间（在宽泛的时间限制内，这里不成问题）。
  他们可以让计算机按字面意义发送后端，任何他们想要的东西，按需发送。任何可能得到的。任何职位。任何标题字段。什么都行。它们可以包含任何标题。任何来源。他们选择和知道的任何饼干信息。从字面上说，任何事。大多数用例的常见例外可能是物理的“黑匣子”加密卡/密钥和客户机的IP地址，如果在会话期间进行检查，这两者都是更棘手的障碍，甚至IP通常也可以以各种方式进行欺骗，特别是当他们不关心回复时。
  结果是从安全角度来看你不能相信客户发送的任何东西。你可以提高标杆报价很多，足够大多数日常使用。安全传输（TLS/HTTPS），如果有人控制一台路由通过的中间计算机，就很难修改、截获或更改流量。一个实现良好的操作系统和浏览器，可以阻止特定网页之外的脚本或恶意软件在本地进行干扰。检查一端或两端的证书。一种安全的网络，它可以对可能连接的东西进行身份验证。
  但其中的每一个都是一个障碍，而不是一种绝对的防御。每一个都曾经被打破过，现在不时被打破，将来也会被打破。也不能保证没有bug和漏洞。没有人能够在客户端防御用户、恶意软件或rootkitted远程访问故意或无意地破坏客户端PC上的防御，因为这样的用户通常可以更改或绕过操作系统或浏览器编程要执行的任何操作。没有一个是真正完美的防御。
  因此，如果你有任何软件或基于web的系统，有一个后端和前端，这是一个黄金法则，你不信任客户端提供的数据。收到时你要重新检查后端. 如果请求是访问或发送网页或文件，是否可以，是否应该允许该会话访问该文件，文件名是否有效？如果请求是要处理的某个数据或窗体，那么所有字段是否合理并包含有效数据，是否允许该会话进行这些更改。
  您不信任不在您自己的安全已知co下的事物
• End