Details of a new attack on websites that utilize a front-end-back-end model, such as those operating through content delivery networks, load balancers, or proxies. This attack allows for the injection of content into other requests being processed in the same stream between the front-end and back-end by sending specific requests. The proposed method has been successfully applied to conduct an attack that intercepts user authentication parameters for the PayPal service, which paid researchers around $40,000 under its bug bounty program for reporting unpatched vulnerabilities. The attack is also applicable to sites using the Akamai content delivery network.
The essence of the problem is that front-ends and back-ends often provide different levels of HTTP protocol support while encapsulating requests from different users into a common channel. A long-lived TCP connection is established to connect the request-accepting front-end and the request-processing back-end, through which user requests are streamed one after another, separated by means of the HTTP protocol. Headers such as 'Content-Length' (which defines the total size of the data in the request) can be used to separate requests.‘ (allows data to be sent in chunks, specifying blocks of different sizes in the format '{size}\r\n{block}\r\n{size}\r\n{block}\r\n0').
The problem arises if the front-end supports only 'Content-Length' but ignores 'Transfer-Encoding: chunked' (for example, this was the case with Akamai CDN), or vice versa. If 'Transfer-Encoding: chunked' is supported on both sides, the attack can exploit discrepancies in the implementation of HTTP header parsers (for instance, when the front-end ignores lines such as 'Transfer-Encoding: xchunked', 'Transfer-Encoding: chunked', 'Transfer-Encoding:[tab]chunked', 'X: X[\n]Transfer-Encoding: chunked', 'Transfer-Encoding[\n]: chunked', or 'Transfer-Encoding : chunked', while the back-end successfully processes them).
In this case, the attacker may send a request where both the "Content-Length" and "Transfer-Encoding: chunked" headers are specified, but the size in "Content-Length" does not match the size of the chunked data, which is less than the actual value. If the frontend processes and redirects the request according to "Content-Length," while the backend expects the block to be completed based on "Transfer-Encoding: chunked," then the end of the data according to "Transfer-Encoding: chunked" will be determined earlier, causing the remaining part of the attacker's request to be attached to the beginning of the next request. That is, the attacker will have the opportunity to append arbitrary data to the beginning of someone else's request being sent next.
To identify the issue in the used frontend-backend combination, a request of the following kind can be sent through the frontend:
POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4
1
Z
Q
The problem is present if the backend does not immediately process the request and waits for the final zero-length chunked data block to arrive. For a more complete check, a special utility that also tests possible methods of hiding the "Transfer-Encoding: chunked" header from the frontend.
Conducting a real attack depends on the capabilities of the targeted site. For example, when attacking the web application Trello, one could modify the beginning of the request (inserting data like "PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake") and send a message that includes the original request of another user along with the specified authentication cookies. For the attack on saas-app.com, it became possible to inject JavaScript code in the response by substituting it into one of the request parameters. In the case of the attack on redhat.com, an internal handler was used to redirect to the attacker's site (a request like "POST /search?dest=../assets/idx?redir=//redhat.com@evil.net/ HTTP/1.1" was substituted).
The use of a method for content delivery networks allowed for the simple substitution of the requested site by modifying the "Host:" header. This attack is also applicable for poisoning content caching systems and extracting cached confidential data. The peak of this method's application was the organization of an attack on PayPal, which enabled the interception of passwords sent by users during authentication (there was a modification of the iframe request to execute JavaScript in the context of the page paypal.com/us/gifts, for which a CSP (Content Security Policy) was not applied).
Interestingly, in 2005, there was a similar technique of request substitution, allowing the alteration of data in caching proxies (Tomcat, squid, mod_proxy) or bypassing firewalls by indicating multiple "GET" or "POST" requests within a single HTTP session.
Source: opennet.ru
