WEB漏洞挖掘之HTTP参数污染

前排提示：黄暴师傅依旧在线，纯粹的技术分享

#前言：1.为了方便大家日后更好的学习安全，小编为此专门建立了一个氛围良好的学习圈子。在这个圈子里，大家可以尽情地讨论安全方面的知识，不会的问题也可以在群里求助大佬同时，本人也经常会在群里免费限时分享我们VIP内部学习资源哦~如何加群：添加小编微信 hdm838683 即可PS：进群后切记不可退群！退群者终身无法再次加入！特此通知！2.VIP公开课免费资源因为VIP课程上线不久后，很多粉丝都想试听，但是天时不如地利，地利不如人和呀，辣鸡网盘就是不给力，一分享就挂！所以本人打算将公开课资源分成8个小部分给大家学习，目前总大小250G 左右，都是优质资源，够你白嫖了吧领取方法：后台回复关键词“大佬您好”即可获得！

好久不见，各位同志。这段时间由于忙各种事情，文章耽搁了好一会，那废话不多说，直接进入主题。

前情回顾：

web漏洞的重定向漏洞大家如果认真去看，一定可以学会的，没什么太大难度，当然，如果你基础不行，看什么都是天书（今日份嘲讽你+1）。

不过咧，比较尴尬的是，这种漏洞在国内不是很值钱，甚至说漏洞平台不屑于去收录这种漏洞。

但是！

在我看来，网络安全是一门讲究细节的工程，如果我们轻视任何一种漏洞，都没有好果汁吃。

目前国外对于这种漏洞的奖励金额在200美元到500美元之间，折合人民币在1000元到3000元左右。

全世界现在对于重定向漏洞普遍的做法就是在网站中通过实现中间网页（在用户访问期望的内容之前进行显示和提醒）的方式来抵御开放式重定向漏洞。在你重定向用户到一个URL时，可以显示一个中间网页，其中包含说明用户正在离开他们所在的域的提醒信息。因此，如果重定向网页显示的是虚假的登录页面或者试图伪装成受信任的域，用户都会知道他们正在被重定向。

例如：

可是这样做就可以心安理得了吗？

我不多BB，只讲一句话：尽管你可以使用中间网页提醒的方式避免重定向漏洞，但是网站之间交互的复杂性也能导致有些链接缺失保护。

好好想想，国内的IT们，你们信任的域内网址真的能一定安全吗？

HTTP参数污染

专业解释：HTTP参数污染（HPP）指操纵网站处理它接收到的HTTP请求参数的过程。漏洞发生的原因是：攻击者在请求中注入了额外的参数，同时目标网站信任了这些参数并且导致了非预期的结果。HPP漏洞可以在服务器端或客户端触发。在客户端通常指的是用你的浏览器可以看到测试效果。大多数情况下，HPP漏洞是否存在，取决于服务器端代码是如何处理攻击者通过控制的参数传递给服务器端的变量的。因此，寻找此类型的漏洞可能要比寻找其他类型的漏洞需要更多的试验测试。

人话解释：我们将自己构造的参数通过某些方式传递给服务器，由于服务器配置的很傻逼，相信了我们的参数，并将参数带入到正常业务中去处理，给出了我们想要的结果。至此，我们完成了攻击。

说起来容易，做起来懵逼。我们来看下面的详细讲解。

先来看服务端HPP：

在服务器端HPP中，尝试给服务器端发送非预期信息来让服务器端代码返回非预期的结果。当你发送一个请求到一个网站时，网站服务器端会处理该请求并且返回结果。在某些情况下，服务器端不仅返回一个网页，同时还会根据从URL获取到的信息运行一些代码。这部分代码只会在服务器端运行，所以对你来说基本上是不可见的，也就是说，你可以看到发送的信息和返回的结果，但是这中间运行的代码你是看不到的。因此，你只能推断这期间发生的事情。因为你看不到服务器端的代码结构，所以服务器端HPP取决于你如何确定存在潜在漏洞点的参数并进行试验。

让我们看一个好玩的例子：如果银行通过网站接收URL参数发起转账，可能会造成服务器端HPP漏洞。想象一下如果你可以通过输入三个URL参数from、to、amount来进行转账，每个参数按顺序指定：from指定要从中进行转账的账号，to指定要转入的账号，amount指定要转账的金额。以下URL表示从 大乃乃 账户转账5000元到 张三 账户：

https://www.bank.com/transfer?From=大乃乃&to=张三&amount=5000

（看不懂URL格式的，去上一篇重定向漏洞文章里补习URL格式知识）

银行可能会假设它只可能接收一个from参数，但是如果你提交两个from参数会发生什么？就像下面这个URL一样：

https://www.bank.com/transfer?From=大乃乃&to=张三&amount=5000&from=大鸡鸡

这个URL最初的结构组成和第一个URL一样，只是多加了一个额外的from参数以表示另一个发送账户 大鸡鸡。在这种情况下，攻击者可以发送这个额外的参数，希望可以令程序用第一个from参数做转账验证，使用第二个from参数从账户 大鸡鸡 提取资金。所以，如果银行信任它接收到的最后一个from参数，攻击者就可以利用一个不是他们自己的账户来执行转账操作——不再从 大乃乃 的账户向 张三 的账户转账5000元，取而代之的是，服务器端代码会使用第二个参数从 大鸡鸡 账户转账给 张三 账户。

当服务器接收到多个具有相同名称的参数时，它可以通过多种方式进行响应。例如，PHP和Apache取参数的最后一次赋值，Apache Tomcat取参数的第一次赋值，ASP和IIS取该参数的所有赋值，以及其他的服务等等。

因此，没有哪一个单独的验证程序可以保证能同时处理好多个相同名称的参数提交操作，发现HPP漏洞时，你需要做一些试验来确认你所测试的网站是如何运作的。

服务端的HPP漏洞形式还有一些在文章里是讲不明白的，后面我们团队的独家视频里会进行讲解，大家可以期待一下。

接着看客户端HPP：

客户端HPP漏洞使攻击者可以向URL中注入额外的参数，从而对客户端产生影响（客户端最常见的操作方式是个人电脑，通常是通过浏览器触发，并不是发生在网站的服务器端）。

想一想，如果客户端的脚本限制URL中只允许输入一个参数值应该咋办？

可以利用URL编码，例如：

https://www.bank.com/transfer?From=大乃乃%26from=大鸡鸡&to=张三&amount=5000

其中，%26 是URL编码 & 的意思。所以，如果只允许输入一个From值，就可以利用这种编码方式，强行多加一个键值 from=大鸡鸡 进去。

小结:

HPP带来的风险取决于站点后端执行的操作以及调用污染参数的位置。

相比其他一些漏洞，发现HPP漏洞后，更需要进行彻底的测试，因为我们通常无法接触到运行代码处理HTTP请求的后台服务器端。这意味着我们只能推断站点如何处理传递给它们的参数。

通过反复试验，你可能会发现HPP漏洞容易产生的场景。

挖掘推荐：

如果你们领悟能力高，通常，社交媒体链接是测试此类漏洞的首选。

例如替换和增加某些参数，嘿嘿嘿。

欢迎各位同志点击下方公众号卡片关注我们，等待下一篇文章 WEB漏洞挖掘之跨站请求伪造 发布。

原文始发于微信公众号（YKCC安全）：WEB漏洞挖掘之HTTP参数污染