1

I was trying this, on a website where I was allowed to carry out testing by the site administrator. On failing to use two different headers (Site is beyond AWS and I am getting a 400), I tried the old way of using 2 different Content-Length headers.

Finally, I stick with one Content-Length header I added 1 to the length and added a character to the request body. Surprisingly this is getting processed for 2+ mins on all requests on this site and I am not sure what is happening.

To be technical, the ideal request is

POST /endpoint HTTP/1.1
Host: redacted
User-Agent: redacted
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 4

test

And if I modify it to

    POST /endpoint HTTP/1.1
    Host: redacted
    User-Agent: redacted
    Accept: application/json, text/plain, */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 5
    5

    test

it is processing for long time. I thought it might be a parsing bug, but it is happening for all requests on this site. Is this an issue?

1
  • I'm not sure what you are really trying to do, but the second one is not a valid HTTP request. The 5 is not the beginning of the HTTP body but is an malformed part of the HTTP header - the header ends only after it. Therefore it will either reject the request as malformed or will try to read 5 bytes - but you send only 4 (test) and thus it will wait for more. Not actually a security question though, but more a missing understanding of HTTP. Mar 14, 2021 at 16:01

1 Answer 1

2

Content-Length just says that "I'm going to send this much data in the following HTTP body." The server will sit and wait for you to in fact send that much in the HTTP body, so that it can process it for the request. This is the "parsing bug" you have found—the server is in fact waiting for data you never send.

The extra character you "added to the request body" is in fact not in the request body: it is instead a malformed HTTP header, which your particular server apparently is happy to ignore. HTTP headers are separated by newlines—a single empty line always separates the headers from the body.

You can use the feature you've discovered to keep a connection open as long as you like, sending an absurdly large Content-Length (although not too large—it's not implausible that advanced server software or an IDS reverse proxy might notice that and just preemptively cut you off) and then sending data in at a mere trickle to make the server not time out the connection—then you can keep many such connections open to mount a C10k problem-based DoS in the style of Slowloris or RUDY.

(For the record, I'm not sure what you expect will happen when you add 1 to the Content-Length and one character to the body: that will just, well, create another well-formed, normalised request with an extra character in its body.)

You must log in to answer this question.

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