Cross site request forgery attacks constitute of tricking a user to unknowingly send a request, of, say, transferring funds to the attacker's account.
Formal Definition:
" is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts"
~Wikipedia
AKA (Also Known As):
One-click attack
Session riding
Abbreviated as:
CSRF or XSRY (pronounced as sea-surf)
Difference from XSS(Cross-Site Scripting):
Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.
To understand how it works, we first need to understand the concept and working of cookies and session.
Cookies:
If a user has cookies enabled on his/her web browser, every time the user makes a request to a web server, (that is, accesses a web site) the web server stores information in a piece of text called cookie.
This cookie is hereafter used for identifying this user uniquely.
Session:
Session is another way to identify users uniquely. If you have worked on ASP.Net applications you will know that values that need to be stored for a particular user are added in Session. Each session is uniquely identified by an ID called Session ID.
When a user makes a request to an application that implies session and if the user has cookies enabled the Session ID generated would be stored in the cookie. And for every subsequent request this Session ID would be sent to the server. The server would use this Session ID to identify the user. This way the user would not need to authenticate himself/herself for each request.
Once the user's session has been assigned an ID, it is returned to the server for every request. However, if the time elapse between two requests is more than the timeout value, the session is said to be expired and the user will have to identify himself again, (for e.g. login again) if the user wishes to continue using the web site.
Cookies:
If a user has cookies enabled on his/her web browser, every time the user makes a request to a web server, (that is, accesses a web site) the web server stores information in a piece of text called cookie.
This cookie is hereafter used for identifying this user uniquely.
Session:
Session is another way to identify users uniquely. If you have worked on ASP.Net applications you will know that values that need to be stored for a particular user are added in Session. Each session is uniquely identified by an ID called Session ID.
When a user makes a request to an application that implies session and if the user has cookies enabled the Session ID generated would be stored in the cookie. And for every subsequent request this Session ID would be sent to the server. The server would use this Session ID to identify the user. This way the user would not need to authenticate himself/herself for each request.
Once the user's session has been assigned an ID, it is returned to the server for every request. However, if the time elapse between two requests is more than the timeout value, the session is said to be expired and the user will have to identify himself again, (for e.g. login again) if the user wishes to continue using the web site.
How CSRF Works?
Consider the following scenario:
1. You are logged into your internet banking account.
2. Simultaneously you are also checking out a forum.
3. Let's say you click on an innocent looking link on the forum.
4. Though this link "looks" innocent, it actually isn't. In fact, it sends a funds transfer request of say, Rs. 1000 destined for his own account.
5. How is this possible?..
It is possible if the internet banking website you are visiting does not have a multi step funds transfer process, or even if it does, the last step, which is the final step where funds are actually transferred to the destination account does not check if the previous steps have been performed, and simply transfer funds without verifying the user sending the request. Here, the site blindly trusts the Session ID sent by the client browser (through cookie) to authenticate the user.
How does the hacker know the web page of the final step.
Simple.. The hacker may also have an internet banking account and has, therefore, noticed the link of the funds transfer page and also that the amount and destination account number are made a part of the link. For e.g, the link may look something like:
www.internetbanking.com/funds/amount=1000&account=123567890
(Normally, web sites that provide features which involve money transactions or that provide any type of crucial information should never ever make even minor fields like amount a part of the URL.)
So, here's a small introduction to CSRF.
Helpful Links:
No comments:
Post a Comment