HTTP参数污染 [英] HTTP Parameter Pollution

问题描述

我们正在开发一个网站，在进行安全检查之后，我们已经确定了安全问题. 此报告也包含HTTP参数污染漏洞.在网上我可以找到什么是HPP?它如何注入&等等; 但是我找不到如何避免此类问题的方法. 服务器语言是php. &我知道相同的参数可以重复&当有许多相同的参数时，php仅考虑最后一个参数. 但是采取任何措施避免这种风险没有任何意义. 那么任何人都可以通过示例指导我如何避免HPP漏洞吗?

In a web site we are developing, after doing a security check, we've identified security issues. This report contains HTTP Parameter Pollution vulnerabilities too. In web i could find what is HPP? How it can inject & etc; Yet I couldn't find how to avoid this kind of issues. The server language is php. & i know same parameter can be duplicated & php just consider the last parameter when there are many of same. But it doesn't make any sense to do something to avoid this risk. So can any one guide me with how to avoid HPP vulnerabilities with examples ?

预先感谢

推荐答案

请注意，我在此处描述的是服务器端HPP"，但是存在客户端版本的漏洞.了解服务器端版本也将有助于客户端版本.

Note that I am describing "server-side HPP" here, however, there is a client-side version of the vulnerability. Understanding the server-side version will also help with the client-side version.

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

HPP is when your application makes a back-end HTTP request to another system.

例如如果您的网站使用以下前端URL进行转帐:

e.g. if your website uses the following front-end URL to make a money transfer:

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

只能通过POST方法访问它，并采用以下参数:

This is only accessible via the POST method and takes the following parameters:

amount=1000&fromAccount=12345

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

When your application processes this page it makes the following POST request to a back end system to actually process the transaction with a fixed toAccount:

https://backend.example/doTransfer.php

toAccount=9876&amount=1000&fromAccount=12345

现在，您说PHP仅在出现重复的情况下才使用最后一个参数.

Now you say that PHP only takes the last parameter in case of duplicates.

假设有人将您网站的POST更改为以下内容:

Suppose someone alters the POST to your website to the following:

amount=1000&fromAccount=12345&toAccount=99999

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

If your transferMoney.php page is vulnerable to HPP then it now might make the following request to the back end system

https://backend.example/doTransfer.php

toAccount=9876&amount=1000&fromAccount=12345&toAccount=99999

用户注入的第二个toAccount将覆盖此后端请求，并将资金转入他们自己的帐户(99999)，而不是系统设置的预期帐户(9876).这对于攻击者将自己的请求修改为您的系统很有用.但是，如果攻击者可以从自己的网站生成此链接并诱使其他用户在不注意额外参数的情况下无意中跟踪该链接，则对攻击者也很有用.

The second toAccount injected by the user will override this backend request and transfer the money into their own account (99999) instead of the intended account set by the system (9876). This can be useful for the attacker to amend their own requests to your system. but it can be also useful to the attacker if the attacker can generate this link from their own website and entice other users to unwittingly follow the link unaware of the extra parameter.

要解决此问题，您应确保所有后端HTTP请求均具有正确的 URL编码以及验证所有输入.例如fromAccount是实际的有效帐号.同样在我的示例中，即使未通过验证，后端请求也应已编码为fromAccount=12345%26toAccount%3D99999，这将阻止将第二个toAccount解释为单独的POST参数.

To fix this you should make sure that any back-end HTTP requests have correct URL encoding applied as well as validating all input. e.g. that fromAccount is an actual valid account number. Also in my example even if this was not validated, the back-end request should have been encoded as fromAccount=12345%26toAccount%3D99999 which would have stopped the second toAccount from being interpreted as a separate POST parameter.

客户端HPP是指攻击者可以操纵页面上显示的链接，因此当它们跟随客户端时，它们会执行应用程序开发人员想要的操作.例如，使用额外的参数污染"转移资金按钮会更改直接从应用程序而不是后端服务执行的转为帐户".

Client-Side HPP is when an attacker can manipulate links displayed on the page so when they are followed client-side, they do something different that the application developer intended. For example, "polluting" a transfer funds button with an extra parameter that changes the "to account" that is actioned directly from the app rather than a back-end service.

这篇关于HTTP参数污染的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！