XSRF Countermeasure
Welcome back to Devil's Blog On Security. Today we'll cover countermeasures against XSRF attacks. From our previous posts on XSRF attacks it is quite clear that XSRF vulnerabilities arise mostly due to automatic submission of cookies therefore one of the best things you can opt as an countermeasure is not to rely completely on HTTP cookies.
Avoid use of hidden variables in HTML pages for critical applications better use any other alternative.
A protected session management can even avoid XSRF attacks that can be executed using session hacking.
Don't ever rely on HTTP for HTTP Referrer header since it can be spoofed.
Keep all plug-ins of your web browser updated.
If you are pro in computer security industry then you might be knowing that preventive measures against XSRF prove futile if website have XSS vulnerability. This is because XSS has capacity to create two way interaction without getting noticed. By the way this is partially true because you can not attack a website with anti-XSRF mechanism having only reflected XSS vulnerability. Now you might have a question why ? Because if a site has created defense against XSRF attacks then it is quite clear that it is protected against session hacking since XSRF depends on stolen session tokens and stealing running session will require XSS script to have session tokens. That is practically impossible because if attacker already have session tokens then why he/she will ever bother to steal it again.
If site is vulnerable to stored XSS attack then attacker have to write a Java script to create attack, no other script might work. So final line of countermeasure is that a site should also create defense against XSS attacks and specially stored one. In next part to our XSRF flow we will discus JSON XSRF attacks. Till then thanks for reading, have a nice time and keep visiting.
