Overlooking the risk of Cross-site Request Forgery (CSRF) exploits can leave your organisation's website or application vulnerable to attack. In this first in a series of security blogs we look at the steps developers can take to reduce the risk.
A successful CSRF exploit can compromise end user data and operation, when it targets a normal user. If the targeted end user is an administrator account, a CSRF attack can compromise the entire web application.
What is a CSRF exploit?
Cross-site request forgery (CSRF) is a type of security exploit where unauthorized commands are transmitted from a user a website trusts, without the user’s knowledge. Because the command is carried out from the user’s computer attacks often go un-reported, as such there is rarely any evidence of the attack recorded in web server logs.
How does a Cross-Site Request Forgery exploit happen?
The exploit works by including a link or script in a page that accesses a site to which the user is known to have already been authenticated. These malicious links or scripts are typically injected into a page by an attacker via Cross-Site Scripting i.e. where an attacker submits an un-validated comment on a blog post. This is then displayed on a page tricking the user’s web browser into accessing the link.
Look at this image - spot what's going on here?
<img src=”http://usersbank.com/transfer-money?to=attacker” />This is a very simple example - you'd hope that your online bank wouldn’t action money transfers with a simple querystring parameter but it does show that if the user is logged into userbank.com then an exploit can happen.
How can the exploit be avoided?
There are various countermeasures to a CSRF exploit including:
- Validating the REQUEST header is the first line of defence - When requests are made via another webpage a referrer header is included, this should be checked to make sure that any requests are made from the correct domain. As referrer headers can be spoofed this is seen as weak solution.
- Use best practices for GET requests - Don’t let any http GET requests have permanent effects on a system i.e. save data to a database. This measure stops links to pages that do things like deleting data being simply loaded via an image tag. This practice also prevents problems whereby aggressive web crawlers accidentally requesting pages that effect a system.
- Use of secret, user-specific tokens in all form submissions – A token should be submitted with every http form POST. The secret token should then be validated before completing any action on a system. As a third party shouldn’t be able to retrieve the user-specific token they cannot send the token with a un-authorized POST request. This means your system cannot be tricked into completing an unauthorised action.
Is your website or application protected?
If you have an off the shelf package or use a well-known and well-documented open source platform then you are probably ok. However even these systems, along with bespoke solutions should still be tested for CSRF exploits.
All Magnifica solutions take the steps outlined above. If you have any concerns about a system your organisation uses we can carry out a technical review on any 3rd party solution - you'll receive a report that outlines risks such as CSRF exploits.