Week
Eleven ↓
Otherwise called Sea-Surf, Session Riding,
XSRF or CSRF, this attack vector enables attackers to force an unsuspecting
user’s browser to send unintended malicious requests by exploiting web application
vulnerabilities (Oriyano, 2016). The attacker is able to get into an active
session with a trusted site/application while the victim visits a malicious
site, and HTTP requests are injected to perform an attack. This pervasive
attack has been ranked in OWASP’s Top 10 list of regularly exploited attacks
(Acunetix, 2018). Generally, this attack requires the victim to be
authenticated and the level of authorization would determine the severity of
the attack. This vulnerability is being leveraged upon because web applications
would always trust users once their identity is confirmed.
In
executing CSRF attacks, an attacker would need to build an exploit URL or
script. The victim can then be tricked into executing the script/clicking the
link via a technique like social engineering. The targeted web application
receives a legitimate looking request from the victim’s browser after the
request is sent by the script. Using this crafted request, the attacker can
create custom actions to be performed as though it were the victim. To achieve
this, a GET or POST request could be used. An example of CSRF attack is seen in
2008’s uTorrent attack where GET requests were used to download malware on a
large scale.
CSRF using
GET request
When
applications are designed to use GET requests to transfer parameter and execute
actions, a request could be crafted for a $200 transfer to an attacker’s
account as shown below:
GET http://netbank.com/transfer.do?acct=Hacker&amount;=$200
HTTP/1.1
Embedding this request into a
seemingly innocent hyperlink would look like:
<a href="http://netbank.com/transfer.do?acct=Hacker&amount;=$200">Read
more!</a>
CSRF using
POST request
The dichotomy
between GET and POST methods is in the method used to execute the attack. For
applications that use POST requests, standard “a”, “href” or “img” tags cannot
be used to frame malicious requests (Incapsula, 2018). Attackers could however deliver
this request using <form> tag
with automatic execution of the embedded JavaScript giving a form as shown
below.
<body
onload="document.forms[0].submit()">
<form
action="http://netbank.com/transfer.do" method="POST">
<input
type="hidden" name="acct" value="Hacker"/>
<input
type="hidden" name="amount" value="$200"/>
<input
type="submit" value="View my pictures!"/>
</form>
</body>
This disguised exploit URL/code can be
delivered to a victim using techniques that would encourage a victim to
interact with it.
Mitigation
Anti-CSRF tokens can be used to prevent
CSRF attacks. This mechanism associates challenge tokens with each request and
appends them with the user’s session. These tokens are also called Synchronizer
tokens. This way, an attacker crafting a request will need to guess the anti-CSRF
token; for a victim to be successfully tricked into sending a request
(Veracode, 2018).
Double submission of cookies can also be
used to thwart CSRF attacks. In this method, random tokens are assigned to both
a cookie and a request parameter; access is then granted to the application
upon verifying that these tokens match (Oriyano, 2016).
References
Sean-Philip Oriyano. (April, 2016). CEH
v9: Certified Ethical Hacker Version 9 Study Guide, Edition 3.
Acunetix. 2018. CSRF Attacks, XSRF or
Sea-Surf. Retrieved from https://www.acunetix.com/websitesecurity/csrf-attacks/
Veracode. 2018. Cross-Site Request Forgery
Guide: Learn All About CSRF Attacks and CSRF Protection. Retrieved from https://www.veracode.com/security/csrf
Incapsula. 2018. Cross Site Request Forgery (CSRF) Attack. Retrieved from https://www.incapsula.com/web-application-security/csrf-cross-site-request-forgery.html
Incapsula. 2018. Cross Site Request Forgery (CSRF) Attack. Retrieved from https://www.incapsula.com/web-application-security/csrf-cross-site-request-forgery.html
Video Credit: Tech4Abhi. August 19, 2017
