Skip to end of metadata
Go to start of metadata

What is CSRF?

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. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application (taken from

How do CSRF attacks work?

For example, a typical GET request for a $100 bank transfer might look like:

GET$100 HTTP/1.1

A hacker can modify this script so it results in a $100 transfer to their own account. Now the malicious request might look like:

GET$100 HTTP/1.1

A bad actor can embed the request into an innocent looking hyperlink:

<a href="$100">Read more!</a>

Next, he can distribute the hyperlink via email to a large number of bank customers. Those who click on the link while logged into their bank account will unintentionally initiate the $100 transfer.

Note that if the bank’s website is only using POST requests, it’s impossible to frame malicious requests using a <a> href tag. However, the attack could be delivered in a <form> tag with automatic execution of the embedded JavaScript.

This is how such a form may look like:

 <body onload="document.forms[0].submit()">
   <form action="http://.com/" method="POST">
     <input type="hidden" name="acct" value="Alice"/>
     <input type="hidden" name="amount" value="$100"/>
     <input type="submit" value="View my pictures!"/>

What helps to prevent attacks?

There are 2 possible approaches helping to prevent such CSRF attacks:

  • Check standard headers to verify the request is same origin
  • Check CSRF token

see for a detailed description how both approaches are working.

Cryptshare CSRF protection:

The CSRF protection of Cryptshare Server consists of 2 parts:

  • Cryptshare is using a CSRF protection functionality provided by the Wicket framework ( The implementation is based on the "check standard headers to verify the request is same origin" approach. Every requests that tries to perform an action on a component, such as a form submit, or link click, is verified by checking the HTTP header for cross domain requests. When a request is coming it is checked whether the Origin HTTP header of the request matches where the request is coming from.  If there is no match the request is aborted and an error page with HTTP error 400 is shown ("Possible CSRF attack").
  • Crypthare is using a synchronizer token pattern (STP). There is a unique, secret hidden field in every HTML form which is validated server side. Every request is validated if the token is available with correct value. In case the validation fails, the request is aborted and a warning is logged in the Cryptshare server log.