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.

2
  • "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. Jun 2, 2018 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. Jun 2, 2018 at 19:03

1 Answer 1

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.

1
  • Thanks for that Info. Once I added Host Header. SQLi worked with 1.1 as well. Jun 2, 2018 at 19:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .