CSRF AttacksCross Site Request Forgery Attacks are similar to XSS in that the attacker posts malicious code to a forum, blog comment, or any other interactive part of the website that will return that content (and code) to users.
Unlike XSS, however, CSRF does not need Javascript. Plain HTML or even BBCode is sufficient, so this makes CSRF the sneakiest of attacks that need careful handling.
Let's start with one simple example. Let's say that your website has a script called delete.php that deletes some content in the database. It takes numeric ID as input to identify the content that needs deletion:
delete.php?id=123
Let's say that the attacker knows of this script. All the attacker needs to do is to insert an image request with SRC set to this script, in a forum post for example, even using BBCode:
Server would translate this to a valid HTML image tag. Anyone who visits the page where this code is presented, will have their browsers issue a call to the above script, and if the script is not protected, it will delete content with ID=123.
This may not sound as a big threat until you perhaps imagine what would happen if the admin visits the page with malicious code. No Javascript, no illegal characters, a simple image request. The admin is probably logged-in, and has proper authentication so even if the delete.php script solves for authentication (only admins can delete with it), the admin is the one who's browser issued the call, so damage is done!
Fortunately, though, there are ways to prevent CSRF attacks to certain extent:
First and foremost, this works only with GET requests, since there is no other sneaky way to issue a hidden call without an image (and without a script, which is solved with XSS protection), except maybe framed pages and/or iframes which are harder to insert into a forum (or blog) post that usually disables such tags. Therefore, move all your sensitive data inputting to POST, instead of GET. This may make your simple administration scripts a bit complex, since in order to POST data you need a form, whereas with GET you can put a simple link somewhere.
And, of course, have all your potentially damaging scripts require a second confirmation. So, even if a CSRF attack happens, you will need to confirm the (damaging) request.
One other additional protection is to compare timestamps. Have the forms with which you issue calls to potentially damaging scripts carry a timestamp, and inside the (damaging) script compare the timestamp from the form with current timestamp. If the difference is greater than, say, 10 seconds, do not perform the potentially damaging action. There is a logic behind this. When you access the page where you need to click to delete some content, you have 10 seconds to click it, after which the script will reject deleting (reload to reset timestamps, of course). So, when you reach a page with CSRF attack against you, if you visited that page more than 10 seconds ago, the attack will not work.
Note that this protection is not perfect. In some complex AJAX application that takes data via URL (GET), does something to it, and passes it to a server script via POST, it is possible to pipe a CSRF attack, if the attacker knows your software arhitecture - as is the case with open-source software.
