Cross Site Request Forgery Attack – Less known but
dangerous
Cross Site Request Forgery (CSRF or XCRF) is one of the top
10 OWASP website vulnerabilities. But the most important about this
vulnerability is that the vulnerability is less known so most of the people do
not know that this vulnerability exists. You will find most of the website
vulnerable to this attack.
What is CSRF:
CSRF is the malicious exploit in which an attacker sends legitimate commands to
a website from a user without his permission. For sending legitimate commands,
attacker uses victim’s web browser. Attacker uses victim’s web browser to send
valid requests to a website without user’s interaction on that request. This
attack is also known as session riding because attacker uses the session of the
victim to perform the requests.
People always confuse this vulnerability with XSS (Cross-Site
Scripting) and those who know says that protection against XSS attack also make
website secure against the CSRF attack. But XSS and CSRF are different type of
attacks. Cross-Site Scripting exploits the trust of a client for the website or
application. But CSRF exploits the trust of a website on the user’s browser. If
the request is being made by the user’s web browser, then website thinks that
it is made by the user itself.
Overview of the CSRF
attack: CSRF attack is performed by using victim’s web browser. In this
attack there are 3 things which are involved.
1. Victim: The person whose session is
being used by the attacker.
2. Trusted website: Website on which the
commands being sent by the attacker using victim’s web browser.
3. Malicious website: Website used by the
attacker to ride the session of the user to send the requests on the trusted
website using user’s web browser. This website site injects a HTTP request for
the trusted site into the victim user session compromising its integrity.
Suppose there is a user who have logged in into a website A.
After logging in. website has started a session for that login. After some time
user has visited the malicious website B which contains a malicious link posted
by the attacker which sends some request on the website A. In This case, if the
user will click on that link, a request is being send to the website A with the
valid session started by user.
Now take a look on the live example on a bank website.
A user logged in into a bank website with his login details.
In this case a valid session is started by the website on the user’s web
browser.
Figure 1: user login in a bank website
This website has a form like this:
<form
action="http://www.mybank.com/transferfunds.php" method="GET">
Recipient: <input type="text" name="receiver">
Amount : <input type="text" name="amount">
<input type="text" name="sender" value=”taken_from_session”>
<input type="submit" value="transfer">
</form>
This is the form on the bank website to transfer the funds
to the other person’s account. Here the hidden field is used for the sender’s
account. Its value is taken from the database according to the user’s session.
So the account will be the account of the person who has started the session on
the website.
After the submission of the form this will send the data to
the page transferfunds.php with data submitted. You can see the URL of the
target page like this
http://mybank.com/transferfunds.php?account=sender’s_account&amount=amount_to_be_transferred&reciever=receiver’s_account
This form sends GET requests. The GET request could be
originated in several different ways:
1.
By the user, who is using the actual web
application;
2.
By the user, who types the URL directly in the
browser;
3.
By the user, who follows a link (external to the
application) pointing to the URL.
If the user knows the form structure and the website is
vulnerable to the attack, he can exploit this vulnerability to transfer the
funds to his account from the user’s account.
Now attacker force user to open a malicious website in other
tab which has a malicious link like this.
Take a look on the link. This link sends a GET request to
the bank website to transfer the funds from the account of logged in user to
the account of someone else account. Here is an example of malicious link using
an image tag. Browser does not restrict image tag for any specific type of
image extension so it can also point to any webpage.
Attacker can also use:
SCRIPT SRC
Figure 2: Attacker using victim’s browser to perform action
There are many ways to send this link to the victim.
1.
By a third party website where it is posted as
an image link or scripting tag
2.
By sending link in Email.
3.
Malicious link in all external documents which
can execute scripts.
4.
On instant messaging
Many times attacker uses URL shorten service to generate a
short URL which will redirect user to original URL.
Some Points about the
attack: I have shown a simple attack example on a bank website using a form
which uses GET method to submit data without the original user’s interaction in
the action. But this attack is not as simple as it is shown in the example attack.
I said that the attack is used the website trust on the user’s browser. But
this attack is not limited to the browsers. Attacker can also embed into a word
document, Flash File, Movie, RSS or Atom web feed, or other document format
allowing scripting.
The example shown above uses the GET method for the attack.
But it does not mean that the applications using GET methods only vulnerable to
the attack. POST forms can be exploited by creating fake forms if the form
structure is known.
Limitation: You
have seen the process how an attacker can exploit this vulnerability. But there
are some limitations of CSRF attack. The success of CSRF depends on many
factors which can be there at the same time. This is a blind attack which has
not good success rate. These are some factors.
1.
The attacker must find a website that is
vulnerable to the attack does not check referrer header.
2.
Attacker should have the idea of the structure
of that website and its forms.
3.
The user must be logged in into the website
while clicking on the malicious link.
These factors should be true at the same time while attacker
is performing the attack.
How to check a
website is vulnerable to CSRF? This vulnerability
exists due to the lack of knowledge of website developers. But website
developers can protect their website by manually checking all the web forms. To
check a website for this vulnerability, create a duplicate form and host it on
some other domain and then try to send request to original website. In
case of GET form, you can directly create a request link which can be posted on
any website.
If any website allows attacker to perform a legitimate website
function using a static URL or POST request then there is the possibility of
this attack. If this command is performed through GET then it is a much higher
risk for the website. If the site is purely POST, an attacker could craft a website
form on the website A (some other
website) and using JavaScript auto submit form function to submit the form to a
target website B. If the web application
containing the CSRF payload uses a browser component that runs in the local
zone, then sending remote POST requests to any website is possible using
XMLHTTP or similar objects. A quick test would involve browsing the website
through a proxy such as Paros and record the requests made. At a later time
perform the same action and see if the requests are performed in an identical
manner (your cookie will probably change). If you are able to perform the same
function using the GET or POST request repeatedly then the site application may
be vulnerable.
Protection against
CSRF: This attack is easy to prevent. But most of the website developers do
not know about this attack. So you will see many websites vulnerable to this
attack. These are the main ways which can be used to protect web applications
against this attack.
1.
Use
of random TOKENS: This is the main and most successful protection against
this attack. Use random tokens with a form submission each time when a user submit
a form. It’s very difficult to guess the random token pattern. But those random
values of the token must be unpredictable. This is the best way to protect
against the attack. You have seen the above form example. We can protect that
form by using the code below:
action="http://www.mybank.com/transferfunds.php" method="GET">
Recipient: <input id="acpro_inp0" name="receiver" type="text" />
Amount : <input id="acpro_inp1" name="amount" type="text" />
<input id="acpro_inp2" name="sender" type="text" value="”taken_from_session”" />
The validity of the token can also be limited to a small piece of time, such as 3-5 minutes. We have stored token In the session variable and it is unique to a user. Attacker must know the token to submit this form via external ways.
2. Limiting the lifetime of cookies:
Website must have some limited time for the authentication cookies. If user is
inactive for some fixed time, the session must be expired. So user will have to
login again for performing some other action. In this case, if the attacker is
trying to perform CSRF attack with some valid HTTP request, request will not be
accepted. User will have to login again. And why will he login if he had not
sent the request?
3. Use POST method in forms: POST method
is more secure than GET method. If GET method is used in a form, all the
submitted data and variables can be seen on the URL as query string parameter
on the address bar. But POST method submits data in secure manner. But this is
not a good protection and post forms can also be exploited. It can only
increase attacker’s effort in exploiting the vulnerability.
4. Check for the referrer website in each
request: Always check the header of the request and check from which web
page the request is being made. And perform action according to the request if
the referrer website valid. A request for money transfer on the bank website
must be sent from the bank website itself and the page which is designed for
the money transfer. All other requests will be attack.
But attacker can easily modify header
information too, if he knows the exact structure of the website and referrer
page for the form. He can change that to the original one in the request
headers. So this protection method is also limited.
5. Damage limitation: This is not the
protection, but it reduces damage caused by the vulnerability. For example if
an attacker have manage to perform CSRF on a website then any action done by
him will require an authentication every time to limit the damage. Amazon uses
damage limitation to reduce the damage by authenticating user at each step.
Conclusion: CSRF is a website vulnerability which is less
known to website developers so it exists and can be seen in many websites. This
vulnerability was found in Gmail 5 years back on January 2007. There are many
famous websites which are still vulnerable to this type of attack. It is really
difficult to protect against this attack, but there are many ways which can
help to protect against this. The most effective way is use of random token
generator. This is used by many websites to protect against CSRF. Amazon uses
damage limitation to protect against this attack.
Users who want to protect themselves against the attack must
know that they cannot do anything. If they want to protect their session being
used, they should logout the website just after the usage. And avoid browsing
other website while using some secure session website.