This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author AdamGold
Recipients AdamGold
Date 2021-01-19.15:06:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
The urlparse module treats semicolon as a separator ( - whereas most proxies today only take ampersands as separators. Link to a blog post explaining this vulnerability:

When the attacker can separate query parameters using a semicolon (;), they can cause a difference in the interpretation of the request between the proxy (running with default configuration) and the server. This can result in malicious requests being cached as completely safe ones, as the proxy would usually not see the semicolon as a separator, and therefore would not include it in a cache key of an unkeyed parameter - such as `utm_*` parameters, which are usually unkeyed. Let’s take the following example of a malicious request:				

GET /?link=;link='><t>alert(1)</script> HTTP/1.1


Upgrade-Insecure-Requests: 1		

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,imag e/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate			

Accept-Language: en-US,en;q=0.9 Connection: close			

urlparse sees 3 parameters here: `link`, `utm_content` and then `link` again. On the other hand, the proxy considers this full string: `1;link='><t>alert(1)</script>` as the value of `utm_content`, which is why the cache key would only contain ``. 

A possible solution could be to allow developers to specify a separator, like werkzeug does:
Date User Action Args
2021-01-19 15:06:49AdamGoldsetrecipients: + AdamGold
2021-01-19 15:06:49AdamGoldsetmessageid: <>
2021-01-19 15:06:49AdamGoldlinkissue42967 messages
2021-01-19 15:06:48AdamGoldcreate