THE ART OF SMUGGLING HTTP REQUEST PRESENTED BY SAURABH TIWARI WORKSHOP 

AGENDA  Evolution of HTTP protocol version  HTTP Pipelining  CL.CL / CL.TE Desync Attack  Impact?  HTTP/2  H2.CL Desync Attack  Websocket  Websocket HRS  Prevention 

HTTP/1.0 In early versions of HTTP (version 1.0 and before), every request is one TCP connection one that precedes 

HTTP/1.1 Uses by default persistent connections to transmit multiples requests We can use the header “Connection: close”, if we don’t want persistent connections This version also introduced “Transfer-Encoding” header which is the key to some HRS attacks SOLUTION 

HTTP PIPELINING It allows multiple HTTP requests to be sent over a single TCP connection without waiting for the correspondin responses 

HOW DOES THE SERVER KNOW WHERE A REQUEST ENDS AND A NEW REQUEST STARTS? A request is made up of a header section and a body section The headers can have any length and are terminated by \r\n the server can determine the size of the body section using the CL or TE header 

HOW DOES THE SERVER KNOW WHERE A REQUEST ENDS AND A NEW REQUEST STARTS? A request is made up of a header section and a body section The headers can have any length and are terminated by \r\n the server can determine the size of the body section using the CL or TE header 

SO WHERE IS THE CONFUSION? Transfer-Encoding headers are not supported by all servers As a result, the confusion appears when the proxy and the backend server do not agree on the size of each request 

DUPLICATE CONTENT-LENGTH (CL.CL) 

CONTENT-LENGTH(.)TRANSFER-ENCODING  When both Content-Length and Transfer-Encoding headers are present in a message, the server faces a dilemma: which one to prioritize? Fortunately, the HTTP/1.1 RFC provides clear guidance on how to handle this situation.  If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored. Ref: RFC2616 - HTTP/1.1 

IMPACT? Leveraging HTTP request smuggling to exploit reflected XSS:  When an application is susceptible to both HTTP request smuggling and reflected XSS, a powerful attack vector emerges.  In other words, you can smuggle a request containing the XSS payload, and the next user's request that is processed by the backend server will automatically be affected, allowing you to exploit the XSS vulnerability without any user interaction. Turning an on-site redirect into an open redirect using HTTP request smuggling:  Many applications perform on-site redirects from one URL to another and place the hostname from the request's Host header into the redirect URL  This behavior is normally considered harmless, but it can be exploited in a request smuggling attack to redirect other users to an external domain 

HTTP/2 There are only three new concepts that you need to understand :-  Pseudo Headers : In HTTP/1, the first line of the request contains the request method and path. HTTP/2 replaces the request line with a series of pseudo-headers. The five pseudo-headers are easy to recognize as they're represented using a colon at the start of the name: 

HTTP/2 There are only three new concepts that you need to understand :-  Binary Protocol : HTTP/1 is a text-based protocol, so requests are parsed using string operations. HTTP/2 uses a binary protocol, which means that requests and responses are sent as binary data rather than plain text. This binary protocol uses predefined offsets to indicate the start and end of different parts of the request or response, making it much less prone to ambiguity and desync attacks.  Message Length : In HTTP/1, the length of each message body is indicated via the Content-Length or Transfer-Encoding header. In HTTP/2, the message body is composed of data frames, which have a built-in length field. This means that the length of the message body is explicitly specified in the data frames, making it clear and unambiguous. 

BUT WAIT, HOW CAN DESYNC ATTACKS STILL HAPPEN IN HTTP/2?  You might think that with the built-in length field in HTTP/2 data frames, desync attacks would be impossible.  However, the vulnerability lies in HTTP/2 downgrading.  When an HTTP/2 connection is downgraded to HTTP/1, the built-in length field is lost, and the server needs to rely on the Content-Length or Transfer-Encoding header to determine the message length.  This downgrade can create an opportunity for desync attacks to occur. Credit: Portswigger 

H2.CL DESYNC ATTACK 

WEBSOCKET  In traditional HTTP, the client initiates communication by sending a request to the server, which then responds with the requested data.  This unidirectional approach can make it challenging to implement certain application features that require real-time, bidirectional communication.  For instance, building a web app that sends instant notifications to users becomes cumbersome, as the client must continuously poll the server for updates, resulting in unnecessary requests and wasted resources.  The WebSocket protocol allows the creation of two-way communication channels between a browser and a server by establishing a long-lasting connection that can be used for full- duplex communications. 

WEBSOCKET HANDSHAKE  Client sends GET request (aka Upgrade request) to the backend with the set of special HTTP headers: Upgrade, Sec- WebSocket-Version, Sec-WebSocket-Key  Backend should responds with status code 101 and acknowledge nonce sent by client  Backend should compute confirmation value using nonce from client and send it inside Sec-WebSocket-Accept HTTP Header.  After successful handshake client or backend can transfer data using WebSocket frames  If we now add a proxy in the middle, something interesting happens: Instead of fronting the connections themselves, most proxies won't handle the upgrade but will instead relay them to the backend server 

WEBSOCKET HRS 

PREVENTION  Do not use front-end server.  If used, configure them properly to only accept what is acceptable by both the front-end server & backend- server.  Use HTTP/2 end to end and disable HTTP downgrading if possible.  If you can't avoid HTTP downgrading, make sure you validate the rewritten request against the HTTP/1.1 specification.  For example, reject requests that contain newlines in the headers, colons in header names, and spaces in the request method 

WHOAMI?  Saurabh Tiwari  23  Working as a IT Security Analyst  One of the moderators of BreachForce Cybersecurity Cohort  Also, a student  Life’s motto : Bring on the hardship, it’s preferred in a path of carnage ~ Zoro 

THANKS| linkedin.com/in/saurabh-tiwari-5315801b5 @Zodiac_Minati