Take this example: You are logged into your banks website which is vulnerable to CSRF. There are now certain functions you can do as a logged in user that pertain to your account, for instance deleting your account, editing your profile, or changing your password. CSRF will allow an attacker to gain access to your website functions and the things you can do while your logged in. The caveat is that you must have this tab open in your browser for the attack to work.
As a user who is unaware of what evil plot is underway, you click a link an email you got (or browse to a malicious website), and it brings you to a web page as expected. Meanwhile your still logged into your banks website, but have it on a different tab. This evil website then makes a request to your banks website, claiming you want to delete your account. The website has no CSRF protection, and goes ahead and deletes your account. You have no idea what just happened and go about your business.
This is a typical CSRF scenario. The bank had no way of telling if you legitimately clicked the delete account button, or if it was a malicious request from a site you were browsing. Since these requests happen in the background, as a user you have no way of seeing these requests happen. Simply browsing the web can lead to your account being compromised!
This could have been prevented if the developer writing the banks software was knowledgeable of CSRF. To prevent CSRF attacks on your website, forms and “state change” action buttons need to contain a token. A token is a unique set of randomly generated numbers and letters. So, say I have a form. The form contains a text area for a password change, asking the user what they would like to change their password to. We also must implement a hidden field (The user will not see this field, but it is sent to the user in the code that makes up the form, so its not truly hidden) and put our unique generated token in it. Now when I submit the new password, the server will expect this token to come back and be the same token that was supplied. If it is not then we can disregard the request as it had no token or it was invalid. This is how you can successfully prevent CSRF attacks.
If your website is vulnerable to both XSS and CSRF, It opens up a whole new world of hacking possibilities as the attacker does not need to trick you to clicking a link, or wait for the rare occasion where the user has the target vulnerable website tab open. By Injecting code on the website itself, the chances of you browsing on that page are a lot higher, and most people will fall victim to these kind of attacks.
To be safe, inputs should not only be validated and stripped of special characters, but also contain a unique token to check against. Doing these two things will thwart a lot of hacking attempts and keep you and your users safe from hackers.
For more information on this or other topics, or if you think you have been directly affected by one of these attacks, please call us at 855.355.SITE today.