neex opened a new issue #7563: URL: https://github.com/apache/trafficserver/issues/7563
The code in `url_CryptoHash_get_general` at URL.cc decodes percent encoding in all components of the URL, including username / password. This behaviour is incorrect and can lead to security consequences. Consider the following scenario: 1. An ATS instance serves two domains: `attacker.com` and `victim.com`. This can happen either in forward-proxy mode or in the reverse proxy mode in some cases. 2. An attacker controls the content of `attacker.com` (e.g. can serve whatever she wants to ATS when ATS makes requests to attacker.com, as well as to instruct ATS to cache this content). 3. The attacker wants to put her content into the context of `victim.com` to achieve e.g. XSS. The attacker can visit `http://%3a%[email protected]/` via ATS (note the encoded characters in the username). She can do so by sending the link in the HTTP request, like this: ``` GET http://%3a%[email protected]/ HTTP/1.1 ... ``` ATS will forward this request to `attacker.com`, but the key in the cache (calculated in url_CryptoHash_get_general before hashing) will be `http://:@victim.com/:@attacker.com/`. Now, if someone visits `http://victim.com/:@attacker.com/` via ATS, it will lookup the response in the cache and serve the attacker's page, thus achieving XSS impact (the attacker can send this link to someone and execute javascript in the context of `victim.com`). The same impact can be achieved using MD5 collisions. The cache key is hashed using MD5, and there're public tools to create an MD5 collision (including chosen-prefix ones). ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
