5

I Recently came across a Virtual Machine that has Blind SQL Injection in the X-Forwarded-For header.

I used sleep() to detect the vulnerability.
The Payload worked in HTTP/1.0 and not in HTTP/1.1 .

PAYLOAD:

GET / HTTP/1.x
X-Forwarded-For: hacker' OR sleep(5) AND '1'='1 --+
Connection: close

RESULT:

  • For HTTP/1.1 : I Immediately get 400 Bad Request
  • For HTTP/1.0 : I get 200 OK after 5 seconds

    I used Burp Repeater to craft the packet.

VM-Link: https://www.pentesterlab.com/exercises/from_sqli_to_shell_II

Could someone help me understand the Issue here ?
Thanks.

  • "The Payload worked in HTTP/1.0 and not in HTTP/1.1 ." - this is claim without prove. Given that HTTP is not the simple protocol as it looks like and HTTP/1.1 is different and more complex compared to HTTP/1.0 self-made HTTP clients often implement HTTP wrong. Thus, I find it more likely that this is just caused by some misconception you have about HTTP/1.1. Therefore, please prove that the issue is actually dependent on the protocol. – Steffen Ullrich Jun 2 '18 at 18:22
  • 1
    The HTTP Version is the only thing available apart from the X-Forwarded-For Header. I'm not sure how else to prove it. Maybe you could see it for yourself. VM is available in the Link mentioned. – Wisam Ahmed Jun 2 '18 at 19:03
4

The Payload worked in HTTP/1.0 and not in HTTP/1.1 .

TL;DR: it worked in HTTP/1.0, it failed with an invalid HTTP/1.1 request but succeeded with a valid HTTP/1.1 request.


Have a look at the request which was sent:

GET / HTTP/1.x
X-Forwarded-For: hacker' OR sleep(5) AND '1'='1 --+
Connection: close

While HTTP/1.0 and HTTP/1.1 look about the same there are some important differences. One is that HTTP/1.1 requires the client to send a Host header in the request, i.e. something like Host: www.example.com. While this header was possible and widely used with HTTP/1.0 too it was not mandatory in HTTP/1.0 but is mandatory in HTTP/1.1. This means that the request you send is actually invalid with HTTP/1.1 which explains the response you get back from the server:

For HTTP/1.1 : I Immediately get 400 Bad Request

This immediate response from the server means that the request was rejected and not forwarded to the vulnerable web application. The well-formed HTTP/1.0 request instead was not rejected and resulted in the successful exploit:

For HTTP/1.0 : I get 200 OK after 5 seconds

After the HTTP/1.1 request was fixed the exploit worked there too:

Once I added Host Header. SQLi worked with 1.1 as well.

  • Thanks for that Info. Once I added Host Header. SQLi worked with 1.1 as well. – Wisam Ahmed Jun 2 '18 at 19:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.