Understanding cross site request forgery in web development

Focus on those forms and links which invoke state changing functions, because these are the most important CSRF targets.

We can user some OWASP’s CSRF testing tools to demonstrate the attack and flaws.

Let’s take an example to understand CSRF attack.

Here we have one demo website of bank. We have opened the tab to make a transaction as shown in picture.

If we transfer money (Say $50), we can it in our account history.

Now closing the tab and browsing something else. While browsing we see a link to see photos of cute cats.

We click the link and see some pictures of cute cat. When we come back to our bank’s account we can see that $6000 has been withdrawn automatically.

It clearly indicates that clicking on any link affects another website which thieves some important data.

Understanding cross site request forgery in web development Have you ever experienced that you are browsing something and when clicking any link or an object on a website affects the movement in another website in your browser? You might not be wanting to happen that activity but it is not on your hand. At that time a website loses trust from browser and does those malicious activities which are performed unpredictably. This vulnerability is called ‘Cross site request forgery’ which is ranked 8th on the list of OWASP top 10 vulnerabilities 2017 and software development companies should pay attention to this during project implementation. Cross site request forgery (CSRF) is a type of an exploit of a web application where untrusted commands are transmitted from a user which the particular web application trusts. This vulnerability is also known as session riding or one click attack and it is abbreviated as CSRF. The impact of successful CSRF attack has limitations on the capabilities of a victim web application. For example, this attack may result in changing password, transfer of funds or purchasing items without user’s knowledge. Actually, CSRF attack is performed by an attacker to get a target site perform a function via user’s browser without any knowledge of the target user. User cannot know until any unauthorized transaction takes place. Cross site scripting destroys the trust of user for a particular website whereas CSRF exploits the trust a website has in user’s browser. How to know we are vulnerable? To identify whether your application is secured from CSRF or not, you need to check if any links or forms have an unpredictable token. Without these tokens, attackers can find malicious requests. A defence could be, to re-authenticate whenever he tries to submit the request. Read More: How To Avoid Cross-site Scripting (Xss) Vulnerability In Web Development Focus on those forms and links which invoke state changing functions, because these are the most important CSRF targets. We can user some OWASP’s CSRF testing tools to demonstrate the attack and flaws. Let’s take an example to understand CSRF attack. Here we have one demo website of bank. We have opened the tab to make a transaction as shown in picture. If we transfer money (Say $50), we can it in our account history. Now closing the tab and browsing something else. While browsing we see a link to see photos of cute cats. We click the link and see some pictures of cute cat. When we come back to our bank’s account we can see that $6000 has been withdrawn automatically. --> It clearly indicates that clicking on any link affects another website which thieves some important data. Prevention It is recommended to use an existing CSRF defence. There are many frameworks like Spring, Django, Play and Angular JS which are built in CSRF defender. Some programming languages like .NET do it as well. OWASP is having a guard called CSRF Guard which can automatically perform defence actions in Java apps against CSRF. OWASP’s CSRFProtector performs the same defence for PHP and as an Apache filter. Prevention of CSRF generally requires the presence of an unpredictable token in every HTTP request. Such tokens should at least be unique per user session. It is recommended to include the unique token in the hidden field. It includes the value somewhere in the body of HTTP request, restricting its exposure in the URL. In the URL or a parameter, the unique token can also be included. There is still a risk of the exposure of token in front of an attacker. One Stop Solution for Web & Software Development Requirement - Enquire Today See here At personal level a user can practise these steps in order to prevent CSRF vulnerability. Have a habit of immediately logging off from any web application you use. Do not save your usernames and passwords into a browser and don’t allow any site to remember your login credentials. Use separate browsers for sensitive browsing and freely browsing. Integrated HTML enabled newsreader/browser and mail/browser creates more risk as simply viewing a news message or mail message may lead to an execution of the attack.