Request forgeries (CSRF, XSRF, SSRF)

Request Forgeries for the Security+

In 2020, CheckPoint Research announced multiple vulnerabilities in the popular social media application named TikTok. One of the found vulnerabilities allowed an attacker to delete another user’s video, create a video on behalf of that user, automatically become a follower, or even change a private video to become a public video.

That’s right — anyone could perform those actions against anyone else’s TikTok account. All thanks to something called a Cross-Site Request Forgery, aka XSRF or CSRF.

What’s Cross-Site Request Forgery?

CSRF occurs when an attacker is able to perform actions on behalf of an authorized user. We talked about some prior examples with TikTok, but this could also mean that an attacker is able to change passwords to whatever they want, initiate charges, initiate a fund transfer, delete accounts, and so on.

Basically, any action that a legitimate user could take with their account, an attacker could potentially take with a CSRF attack.

This can be done from a simple phishing attack by sending an email to a user with a specially crafted URL. For example, let’s look at a scenario from Imperva’s blog.

An attacker might notice that a URL endpoint to initiate a transfer looks like this:

GET http://netbank.com/transfer.do?acct=PersonB&amount=$100 HTTP/1.1
Code language: HTTP (http)

They could modify the endpoint to link to their account:

GET http://netbank.com/transfer.do?acct=AttackAccount&amount=$100 HTTP/1.1
Code language: HTTP (http)

They could then send this link directly to someone they know who uses the same bank, or they could embed it in an email via a hyperlink:

<a href="http://netbank.com/transfer.do?acct=AttackAccount&amount=$100">Read more!</a>
Code language: HTML, XML (xml)

What looks like an innocent link turns out to be a malicious link that would transfer $100 from your account to the attacker’s account, if the bank website were vulnerable to this attack.

Preventing CSRF with tokens

A widely used defense against CSRF attacks is what’s called CSRF tokens. These tokens get randomly generated for requests and get validated by the application before processing the request. That way, if a request has a legitimate CSRF token, then the application can process it.

If the CSRF token is no longer valid, then the application can discard the request.

Server-side request forgery (SSRF)

There’s also an attack called a Server-Side Request Forgery, or SSRF. This is similar to CSRF, but does have some key distinctions.

Instead of making requests on behalf of a user, SSRF aims to abuse functionality on the webserver to read or modify internal resources that aren’t supposed to be accessible to end-users.

Or, the resources might be accessible to end-users, but only with limited access. The webserver, however, has unrestricted access to that same resource, allowing regular users to elevate their access privilege to that resource.

This is possible because an attacker might send a request to a webserver, and the webserver performs the request on behalf of the attacker, but may not have accounted for the fact that the request was malicious.

POST /vidgif/upload HTTP/1.1
Host: imgur.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0)
Accept: */*
Accept-Language: en-US,en;q=0.5
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://imgur.com/vidgif/video/between/56.72/9.71?url=http%3A%2F%2Fwww.onirikal.com%2Fvideos%2Fmp4%2Fbattle_games.mp4
Content-Length: 127
Cookie: REDACTED;
Connection: close

source=http%3A%2F%2F192.166.218.53%2Fmalicious123.php&url=http%3A%2F%2F192.166.218.53%2Fmalicious123.php&start=56.72&stop=66.43

Code language: HTTP (http)

Example source: https://hackerone.com/reports/247680

Preventing SSRF

Similar defenses to what we’ve talked about for web-based vulnerabilities apply for SSRF as well. This vulnerability comes from trusting inputs coming from users, which should never be done.

For example, if you ever have to accept a user-supplied URL, you should make sure it’s the type of URL that you expect and not a maliciously crafted path that attempts to extract password files on your server.

Are you ready to take the Security+ exam? Practice with our free PBQ practice exam and see how well you do! If you need to study more first, enroll in our high quality course today

Related Articles

Responses

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.