Cross Site Request Forgery (CSRF)
Cross Site Request Forgery is a vulnerability and a common attack that tricks a user into executing an unwanted action (such as sending a link via chat) in a web application. CSRF attack can force
the user to perform state changing requests or operations in systems like
unfriend a friend in Facebook, upload a photo or status in Facebook, changing
email addresses and so forth.
In this blog post I am discussing on what is CSRF attack and how we can prevent from this attack in web applications. In addition to that, I will be discussing on two major security patterns , which we can implement for preventing CSRF attack in my onfall blog posts.
What is CSRF?
There are few ways in which an end user can be
tricked into loading information from or submitting information to a web
application by attacker. Following diagram will simply explain to you what is CSRF by using a real-world example.
* session-id
is used to identify the intended user
If the Facebook was designed to use GET request to unfriend a friend, the unfriend request looks like this:
If the Facebook was designed to use GET request to unfriend a friend, the unfriend request looks like this:
Below I have explained the ways in which an end user can be tricked by the attacker with respect to the given example.
1. Building an exploit URL
As the diagram shows, let's say John needs to log in to his Facebook account. Normally what he does is he simply enters his Username and Password to get in on Facebook. After John entering his credentials on Facebook, it will authenticate John and create a Session Id for his new Session if only John is a valid user. Later on this session Id will be used to identify the John uniquely. This session Id will come along with the session cookie and store at the browser's cookie storage.
Let's say John wants to unfriend Sam from his Facebook friend list. Simply he can go to the Facebook page and click on the link to unfriend the Sam. But imagine an attacker prepares that URL (shorten the URL using a URL shorter into https://goo.gl/124qa) to unfriend the Sam from John's account and send that link to the john via chat.
Assume while you are browsing on Facebook you get a chat message from this Attacker. So, John does not know about that URL and he clicks on it. John's browser is making this request unintentionally (by converting that shorten URL into http://www.facebook.com/user/unfriend? id=Sam) and Sam will be removed from his Facebook account. This is how attacker tricks a user to into execute an unwanted action and this problem is known as the Cross Site Request Forgery.
2. Planting a fake image on page that is likely to be visited by the user
Let say attacker does not need to send this link through a chat to John. Attacker hosts a website (e.g. gossip.com) and in there attacker has this image element.
http://gossip.com
http://gossip.com
Assume somehow John visits this gossip.com and when this page loads hidden image will be tried to get loaded. Since this is not an actual image and this contains the link for unfriend Sam fro the John's Facebook account, when this request fires from the John's browser unknowingly Sam will be removed from his Facebook account. This problem is known as the Cross-Site Request Forgery.
How we can prevent from CSRF attack?
As the fundamental rule of preventing from CSRF attack, never
implement any state changing operations in the system through GET requests.
State changing operation is any operation that modifies data or behavior of the
system.
Modify data à
update status, update cover photo in Facebook
Modify behavior à shutting down a server and sending it to a different state
Let's assume the Facebook now implements a POST request and the vulnerable request looks like this:
Anyone who sends a post request and if
the session cookie comes along it will be accepted and then the data does not
go as query parameter but in the body. So, can we solve this problem using a
POST method instead of using GET method or attacker can still trick the user? Such a request cannot be delivered using a standard Anchor tags or Img tags as discussed earlier, but can be delivered using a FORM tag:
Now let say gossip.com has below form:
This form requires the user to click on the submit button, but this can be also executed automatically using JavaScript or some jQuery on page. So, still attacker can trick the user. The actual reason is the session cookie goes with the request. Because browser does not know whether this a legitimate user or an attacker, browser checks only the action. So, browser selects all eligible cookies to send along the request. Facebook also does not know whether this is an actual user or not (anyway it is actual user's browser) and Facebook will proceed that action. So, still we cannot solve this problem actually in this way.
So, to prevent from this CSRF attack security problem there are two major security patterns that we can implement.
1. Synchronizer Token Pattern
2. Double Submit Cookie Pattern
I will be discussing these security patterns in my next blog posts.
This form requires the user to click on the submit button, but this can be also executed automatically using JavaScript or some jQuery on page. So, still attacker can trick the user. The actual reason is the session cookie goes with the request. Because browser does not know whether this a legitimate user or an attacker, browser checks only the action. So, browser selects all eligible cookies to send along the request. Facebook also does not know whether this is an actual user or not (anyway it is actual user's browser) and Facebook will proceed that action. So, still we cannot solve this problem actually in this way.
So, to prevent from this CSRF attack security problem there are two major security patterns that we can implement.
1. Synchronizer Token Pattern
2. Double Submit Cookie Pattern
I will be discussing these security patterns in my next blog posts.
No comments:
Post a Comment