{"id":306,"date":"2024-01-27T16:00:20","date_gmt":"2024-01-27T22:00:20","guid":{"rendered":"https:\/\/blog.ishsome.com\/?p=306"},"modified":"2024-04-16T20:55:19","modified_gmt":"2024-04-17T01:55:19","slug":"http-request-smuggling","status":"publish","type":"post","link":"https:\/\/blog.ishsome.com\/index.php\/2024\/01\/27\/http-request-smuggling\/","title":{"rendered":"HTTP Request Smuggling"},"content":{"rendered":"\n

This blog is based on the HHTP Request Smuggling room from TryHackMe<\/a>.<\/p>\n\n\n\n

What is HTTP Request Smuggling?<\/mark><\/h4>\n\n\n\n

HTTP<\/a> Request Smuggling is a vulnerability that arises when there are mismatches in different web infrastructure components. This includes proxies, load balancers, and servers that interpret the boundaries of HTTP requests.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n
<\/div>\n\n\n\n

Request splitting or HTTP desync attacks are possible because of the nature of keep-alive connections and HTTP pipelining, which allow multiple requests to be sent over the same TCP connection. Without these mechanisms, request smuggling wouldn’t be feasible. When calculating the sizes for Content-Length (CL) and Transfer-Encoding (TE), it’s crucial to consider the presence of carriage return \\r<\/code> and newline \\n<\/code> characters. These characters are not only part of the HTTP<\/a> protocol’s formatting but also impact the calculation of content sizes.<\/p>\n\n\n\n

While testing for request smuggling vulnerabilities, it’s important to note that some tools might automatically “fix” the Content-Length header by default. This means if you’re using such tools to run payloads, your Content-Length values might get overwritten, potentially changing the test results.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n

Note that testing for request smuggling can potentially break a website in many ways (cache poisoning, other user requests may start failing, or even the back-end pipeline might get fully desynced), so extreme care should be taken when testing this on a production website.<\/p>\n<\/blockquote>\n<\/div>\n\n\n\n

<\/div>\n\n\n\n

Importance of Understanding HTTP Smuggling Request<\/mark><\/h4>\n\n\n\n
    \n
  1. Smuggled requests might evade security mechanisms like Web Application Firewalls. This potentially leads to unauthorized access or data leaks.<\/li>\n\n\n\n
  2. Attackers can poison web caches by smuggling malicious content, causing users to see incorrect or harmful data.<\/li>\n\n\n\n
  3. Smuggled requests can be chained to exploit other vulnerabilities in the system, amplifying the potential damage.<\/li>\n\n\n\n
  4. Due to the intricate nature of this vulnerability, it can often go undetected, making it crucial for security professionals to understand and mitigate it.<\/li>\n<\/ol>\n\n\n\n

    Components of Modern Web Applications<\/mark><\/h4>\n\n\n\n

    Modern web applications are no longer straightforward, monolithic structures. They are composed of different components that work with each other. Below are some of the components that a modern web application usually consists of:<\/p>\n\n\n\n

      \n
    1. Front-end server<\/strong>: This is usually the reverse proxy or load balancer that forwards the requests to the back-end.<\/li>\n\n\n\n
    2. Back-end server<\/strong>: This server-side component processes user requests, interacts with databases, and serves data to the front-end. It’s often developed using languages like PHP<\/a>, Python, and Javascript and frameworks like Laravel, Django, or Node.js.<\/li>\n\n\n\n
    3. Databases<\/strong>: Persistent storage systems where application data is stored. Examples of this are databases like MySQL, PostgreSQL, and NoSQL.<\/li>\n\n\n\n
    4. APIs (Application Programming Interfaces)<\/strong>: Interfaces allow the front and back-end to communicate and integrate with other services.<\/li>\n\n\n\n
    5. Microservices<\/strong>: Instead of a single monolithic back-end, many modern applications use microservices, which are small, independent services that communicate over a network, often using HTTP\/REST or gRPC.<\/li>\n<\/ol>\n\n\n\n
      Load Balancers and Reverse Proxies<\/mark><\/h5>\n\n\n\n
        \n
      1. Load Balancers<\/strong>: These devices or services distribute incoming network traffic across multiple servers to ensure no single server is overwhelmed with too much traffic. This distribution ensures high availability and reliability by redirecting requests only to online servers that can handle them. Load balancing for web servers is often done by reverse proxies. Examples include AWS<\/a> Elastic Load Balancing, HAProxy, and F5 BIG-IP.<\/li>\n\n\n\n
      2. Reverse Proxies<\/strong>: A reverse proxy sits before one or more web servers and forwards client requests to the appropriate web server. While they can also perform load balancing, their primary purpose is to provide a single access point and control for back-end servers. Examples include NGINX, Apache<\/a> with mod_proxy, and Varnish.<\/li>\n<\/ol>\n\n\n\n
        <\/div>\n\n\n\n
        \"How<\/figure>\n\n\n\n
        <\/div>\n\n\n\n
        Role of Caching Mechanisms<\/mark><\/h5>\n\n\n\n

        Caching is a technique used to store and reuse previously fetched data or computed results to speed up subsequent requests and computations. In the context of web infrastructure:<\/p>\n\n\n\n

          \n
        1. Content Caching<\/strong>: By storing web content that doesn’t change frequently (like images, CSS, and JS files), caching mechanisms can reduce the load on web servers and speed up content delivery to users.<\/li>\n\n\n\n
        2. Database Query Caching<\/strong>: Databases can cache the results of frequent queries, reducing the time and resources needed to fetch the same data repeatedly.<\/li>\n\n\n\n
        3. Full-page Caching<\/strong>: Entire web pages can be cached, so they don’t need to be regenerated for each user. This is especially useful for websites with high traffic.<\/li>\n\n\n\n
        4. Edge Caching\/CDNs<\/strong>: Content Delivery Networks (CDNs) cache content closer to the users (at the “edge” of the network), reducing latency and speeding up access for users around the world.<\/li>\n\n\n\n
        5. API<\/a> Caching<\/strong>: Caching the responses can significantly reduce back-end processing for APIs that serve similar requests repeatedly.<\/li>\n<\/ol>\n\n\n\n

          Request Smuggling CL,TE<\/mark><\/h4>\n\n\n\n

          CL.TE<\/strong> stands for Content-Length\/Transfer-Encoding<\/strong>. The name CL.TE<\/strong> comes from the two headers involved: Content-Length<\/strong> and Transfer-Encoding<\/strong>. In CL.TE technique, the attacker exploits discrepancies between how different servers (typically a front-end and a back-end server) prioritize these headers. For example:<\/p>\n\n\n\n