Dev Training

# Dev Training
### Unvalidated Redirects and SSRF

## Redirects

### Safe redirect

`https://example.com/login`

```csharp
public ActionResult Login(LoginModel model)
{
    // Authenticate
    ...
    return Redirect("~/home");
}
```

### Unsafe redirect

`https://example.com/login?next=/home`

```csharp
public ActionResult Login(LoginModel model, string next)
{
    ...
    if (!String.IsNullOrEmpty(next))
    {
        return Redirect(next);
    }
}
```

### What about?

`https://example.com/login?next=http://evil.is/phishing`

### Mitigation

* Try to avoid redirects with user supplied URL
* When doing so, make sure URL is local (or whitelisted)
* Use **built-in libraries or functions**

### Pitfalls

* Starts with `/`
    * `//evil.is` is a valid URL
* Starts with domain
    + `http://example.com.evil.is`

## Impact

### Phishing

* Organization's website used as an entry point for phishing
    * Lends credibility to the attack
    * Makes it more likely to succeed

### As a part of attack chain

* Possible to bypass domain white/blacklisting
* Possible to escalate to SSRF with webhooks or other server-side processes

### XSS

* When `javascript:` (or `data:`) protocol is used in redirect
* `/login?next=javascript:alert(1);`

### Other attack paths

* Header injection (response header splitting)
* Bypass CSP

## Server-side HTTP requests

### What is it?

* Web application performs HTTP request
    * API calls
    * Webhooks
    * HTML-based PDF generator

### Server-side request forgery (SSRF)

* User can control where server reads or submits data
    * User might be able to read results of requests

## Impact

### Internal HTTP services or interfaces

* Possible to access IP-blocked or internal interfaces

### Local file inclusion

* If HTTP library supports `file://` protocol
    * `file:///etc/passwd`

### Cloud hosting

* Access cloud meta data servers
    * `http://169.254.169.254/`
    * Can potentially leak authentication keys

### Internal services

* Databases can have REST interfaces that are only available on internal network
    * MongoDB

## Mitigation

### Avoidance

* If possible, don't make HTTP requests to user-controlled URLs
    * Be careful with HTML-based PDF generators

### If necessary

* Block access to internal network
* Isolate system that performs requests as much as possible
* Be mindful of DNS rebinding
* Think carefully about threat models and attack vectors
Note: DNS rebinding is a type of attack where an attacker tricks a victim's browser into accessing a malicious website by initially resolving to a harmless domain, then switching to a malicious one.

## Rules of thumb

### Redirects

* Avoid redirecting to user supplied locations
* If user can control redirect location, validate that the target location is valid
    * Use built-in libraries or functions to parse URL

### SSRF

* Avoid making requests to user-controlled URLs
* If necessary, be very careful!
* Don't use network location for authorization

## Epilogue

### Further reading

* [OWASP - Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html)
* [Acunetix Blog](https://www.acunetix.com/blog/web-security-zone/unvalidated-redirects-and-forwards/)
* [OWASP - SSRF Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)
* [Blind SSRF Chains](https://github.com/assetnote/blind-ssrf-chains)

### Hall of fame

* [Capital One](https://blog.appsecco.com/an-ssrf-privileged-aws-keys-and-the-capital-one-breach-4c3c2cded3af)
* [SSRF in Wkhtmltopdf leads to LFI](http://hassankhanyusufzai.com/SSRF-to-LFI/)