HTTP参数污染

Question

在我们正在开发的网站中，在进行了安全检查之后，我们发现了安全问题。此报告还包含HTTP参数污染漏洞。在网上我可以找到什么是HPP？它如何注入&等等，但我无法找到如何避免这类问题。服务器语言是php。&我知道相同的参数可以被复制&当有很多相同的参数时，只需考虑最后一个参数。但做些什么来避免这种风险是毫无意义的。那么，有谁能用例子来指导我如何避免HPP漏洞呢？

提前谢谢

Answer 1

请注意，我在这里描述的是“服务器端HPP”，但是有一个客户端版本的漏洞。理解服务器端版本也将有助于客户端版本。

HPP是指您的应用程序向另一个系统发出后端HTTP请求时。

例如，如果您的网站使用以下前端URL进行转账：

https://www.example.com/transferMoney.php

这只能通过POST方法访问，并接受以下参数：

amount=1000&fromAccount=12345

当应用程序处理此页面时，它向后端系统发出以下POST请求，以便使用固定的toAccount实际处理事务

https://backend.example/doTransfer.php

toAccount=9876&amount=1000&fromAccount=12345

现在，您说PHP只在重复的情况下接受最后一个参数。

假设有人将帖子更改到您的网站，如下所示：

amount=1000&fromAccount=12345&toAccount=99999

如果您的transferMoney.php页面易受HPP攻击，那么它现在可能会向后端系统发出以下请求

https://backend.example/doTransfer.php
    
toAccount=9876&amount=1000&fromAccount=12345&toAccount=99999

用户注入的第二个toAccount将覆盖这个后端请求，并将资金转移到他们自己的帐户(99999)中，而不是由系统(9876)设置的预期帐户。这对于攻击者修改自己对系统的请求可能很有用。但是，如果攻击者能够从自己的网站生成这个链接，并诱使其他用户不知不觉地跟踪该链接，而不知道额外的参数，那么它也可能对攻击者很有用。

要解决这个问题，您应该确保所有后端HTTP请求都应用了正确的URL编码，并验证了所有输入。fromAccount是一个实际有效的帐号。在我的示例中，即使没有验证，后端请求也应该被编码为fromAccount=12345%26toAccount%3D99999，这将阻止第二个toAccount被解释为一个单独的POST参数。

客户端

客户端HPP是指攻击者可以操纵显示在页面上的链接，因此当它们被客户端跟踪时，它们会做一些应用程序开发人员想要做的事情。例如，带有额外参数的“污染”转移基金按钮将直接从应用程序而不是后端服务中激活的"to account“更改为”to account“。

HPI

还有一个类似的攻击，HTTP参数注入(，HPI)，它不依赖于第一个名称相同的第二个参数，而是将额外的参数简单地注入到后续URL中。

Ctrl+F HPI 这里