Web Hacking Tips
  • Web App Hacking Tips & Tricks
  • Weekly Tips
    • Week 1 - XSS Filter Evasion
    • Week 2 - CSRF Token Bypass
    • Week 3 - CORS Exploitation
    • Week 4 - Finding XSS
    • Week 5 - CSRF Explanation
    • Week 6 - XSS Types
    • Week 7 - Advanced SQLMap
    • Week 8 - Stealing HttpOnly Cookies from PHPINFO
    • Week 9 - SQLMap Tamper Scripts
    • Week 10 - XSS Obfuscated Payloads
    • Week 11 - XS-Search: Cross-Origin Enumeration
    • Week 12 - Subdomain Takeovers
    • Week 13 - XSS Keylogger
    • Week 14 - Algolia API Keys
    • Week 15 - GraphQL Introspection
    • Week 16 - Naming BurpSuite Repeater Tabs
    • Week 17 - GoBuster Tips
    • Week 18 - Burp Request to Python Script
    • Week 19 - Customizing Nikto Scans
    • Week 20 - Google Phishing Page
    • Week 21 - Google BITB
    • Week 22 - XSS Through SVG File
    • Week 23 - FoxyProxy Extension
    • Week 24 - CSP Bypasses
    • Week 25 - Pilfering LocalStorage with XSS
    • Week 26 - Cloud SSRF
    • Week 27 - Blind XSS
    • Week 28 - Firebase Misconfigurations
    • Week 29 - XSS to CSRF
  • Week 30 - SQLMap Debugging
  • Week 31 - WayBack Machine
  • Week 32 - O365 BITB
  • Week 33 - Burp Intruder Attacks
  • Week 34 - GraphQL Bruteforcing
  • Week 35 - User Accounts
  • Week 36 - CVE Submission
  • Week 37 - Second Order SQLi
  • Week 38 - Out of Band SQLi
  • Week 39 - Broken Link Hijacking
  • Week 40 - JWT Testing
  • Week 41 - BURP ATOR
  • Week 42 - ProxyChains
  • Week 43 - CSS Keylogging
  • Week 44 - SVG SSRF
  • Week 45 - Request Smuggling
  • Week 46 - XSS Payloads
  • Week 47 - DNS Re-binding
  • Week 48 - SSRF Bypass
  • Week 49 - File Upload Bypass
  • Week 50 - CRLF Injection
  • Week 51 - HTML to PDF
  • Week 52 - Parameter Pollution
  • Week 53 - Pre-Account Takeover
  • Week 54 - Race Conditions
  • Week 55 - SQLi to RCE
  • Week 56 - Cloud SSRF PrivEsc
  • Week 57 - Response Queue Poisoning
  • Week 58 - Directory Traversal
  • Week 59 - File Upload -> CSRF
  • Week 60 - Modern CSRF Attacks
Powered by GitBook
On this page

Week 57 - Response Queue Poisoning

Did you know you can likely upgrade CRLF Injection to a Critical finding? Many bug bounty programs consider it medium-severity and on par with XSS. In this post, I will show you how to make it P1 through Response Queue Poisoning!

To accomplish this, we first need to find a way of injecting the classic %0d%0a somewhere in the request. I recommend targeting the URL itself or another parameter that is reflected in the response headers (like Location). For reference, %0d%0a refers to:

Carriage Return = \r (%0d)

Line feed = \n (%0a)

^ Read more about it on one of my previous posts linked in comments

Now let’s say we discovered the below CRLF injection. Before upgrading the severity, we need to form a clean request with our line breaks. The %0d%0a represent a new line break between headers, and the added Connection and Host headers allow for a complete request.

GET /%20HTTP/1.1%0d%0aHost:%20redacted[.]net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

We have a complete request we were able to inject on the server. Now, let’s upgrade this to critical. What the below request does is tell the back-end server to issue 2 responses. The back-end server sees only one request but has two responses and gets confused:

GET /%20HTTP/1.1%0d%0aHost:%20redacted[.]net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Notice the “Foo: bar” header at the end. This is to cancel out the “GET /randompage” that will be appended by a victim’s incoming request we will overlap and steal.

So the server ends up with a response that has no matching request. This response is held in the queue until the server receives another request, then it sends it forward. As you can see, this throws off the server by one request, and the cycle is repeated until the keep-alive connection is terminated.

The end result is intermittently receiving responses intended for other authenticated users and a critical finding for us hackers. This attack is known as Response Queue Poisoning.

If you are having trouble visualizing this, I found a beautiful explanation by PortSwigger I wanted to include:

“As there are no further requests awaiting a response, the unexpected second response is held in a queue on the connection between the front-end and back-end.

When the front-end receives another request, it forwards this to the back-end as normal. However, when issuing the response, it will send the first one in the queue, that is, the leftover response to the smuggled request.

The correct response from the back-end is then left without a matching request. This cycle is repeated every time a new request is forwarded down the same connection to the back-end. “

Note:

If you are having trouble exploiting this, try with a large number of newlines, this has been known to bypass some server-side defense mechanisms. Check out the article linked in the comments for more info.

PreviousWeek 56 - Cloud SSRF PrivEscNextWeek 58 - Directory Traversal

Last updated 2 years ago