details of a new attack on sites using the front-end-backend model, for example, those operating through content delivery networks, load balancers or proxies. The attack allows, by sending certain requests, to wedge into the content of other requests processed in the same thread between the frontend and backend. The proposed method was successfully used to organize an attack that allows intercepting the authentication parameters of users of the PayPal service, which paid researchers about $40 as part of a program to inform about the presence of unpatched vulnerabilities. The attack is also applicable to sites using the Akamai content delivery network.
The essence of the problem is that frontends and backends often provide a different level of support for the HTTP protocol, but at the same time encapsulate requests from different users in a common channel. To connect the frontend that receives requests and the backend that processes requests, a long-lived TCP connection is established through which user requests are transmitted, chained one after the other, separated by means of the HTTP protocol. The headers "Content-Length" (defines the total size of the data in the request) and "” (allows you to transfer data in parts, 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 frontend only supports "Content-Length" but ignores "Transfer-Encoding: chunked" (like CDN Akamai did), or vice versa. If Transfer-Encoding: chunked" is supported on both sides, implementation features of HTTP header parsers can be used to attack (for example, when the frontend ignores lines like "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked", "Transfer-Encoding :[tab]chunked", "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked", or "Transfer-Encoding : chunked", and the backend handles them successfully).
In this case, an attacker can send a request that both contains the "Content-Length" and "Transfer-Encoding: chunked" headers, but the size in "Content-Length" does not match the size of the chunked chain, which is smaller than the actual value. If the frontend processes and redirects the request according to "Content-Length", and the backend waits for the block to complete based on "Transfer-Encoding: chunked", then the end of the data based on "Transfer-Encoding: chunked" will be determined earlier and the remaining tail of the request attacker will be at the beginning of the next request, i.e. the attacker will be able to attach arbitrary data to the beginning of someone else's request, passed next.
To determine the problem in the used frontend-backend bundle, you can send a request through the frontend like:
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 arrival of the final null bounding block of chunked data. For a more complete check a special utility that also tests possible methods for hiding the "Transfer-Encoding: chunked" header from the frontend.
Carrying out a real attack depends on the capabilities of the attacked site, for example, when attacking a Trello web application, you can replace the beginning of the request (substitute data like “PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake”) and send a message, which includes the original third-party user request and the authentication cookies specified in it. In order to attack saas-app.com, it turned out to be possible to implement JavaScript code substitution in response, by substituting it into one of the request parameters. To attack redhat.com, an internal handler was used to redirect to the attacker's website (a request like "POST /search?dest=../assets/idx?redir=//[email protected]/ HTTP/1.1").
The use of the method for content delivery networks made it possible to simply replace the requested site through the substitution of the “Host:” header. The attack is also applicable for organizing content poisoning of content caching systems and extracting cached confidential data. The top of the application of the method was the organization of an attack on PayPal, which allows intercepting passwords sent by users during authentication (the iframe request was changed to execute JavaScript in the context of the paypal.com/us/gifts page, for which CSP (Content Security Policy) was not applied).
Interestingly, in 2005 an essentially similar request spoofing technique that allows you to spoof data in caching proxies (Tomcat, squid, mod_proxy) or bypass firewall locks by specifying multiple GET or POST requests within a single HTTP session.
Source: opennet.ru