bobince
join:2002-04-19
DE
| reply to EGeezer
Re: CSRF article
I don't find it difficult to believe at all. Most web apps have no protection against XSRF, but then a lot of apps don't really have any significant user actions that pose a serious risk.
Webapp risks are, in order of decreasing seriousness and increasing commonness:
1. Code injection
2. SQL injection
3. HTML injection (leading to XSS)
4. XSRF
We're averaging somewhere between levels 2 and 3 today: code injection (through careless filepath handling or idiotic use of eval-style commands) is all but eliminated, affecting only the most totally shoddy of applications. SQL injections are on the wane as many authors are aware of them and database layers tend to hide the potential.
But HTML injections are still very widespread, and few sites take any precautions against XSRF because most authors don't really understand what the risks are.
Luckily, the 10% (if this article is to be trusted) of sites that actually do mitigate against it tend to be those where it really matters, such as banking. But don't expect your average web forum or social networking site to cover it.
Even here, a forum full of security people, the topic linked above is full of irrelevant posts about what combinations of browsers and settings are 'vulnerable', which shows a complete lack of understanding of what XSRF actually is. Some tips:
* any browser is vulnerable to XSRF. No cookies or JavaScript is required, a simple HTTP request to an action is all that is required. All the argument about whether DSLR's logout script's cookie should be honoured when accessed from a third-party site is moot when anyone can post a disguised/redirect link to the logout script on the DSLR forums themselves.
* requiring actions to be submitted through a POST request - though in general something you should be doing anyway to avoid all sorts of problems - is not sufficient to prevent XSRF attacks. An external site can easily include an auto-posting form targeting your script.
* referrer checks are not sufficient to prevent XSRF attacks. Anyone can post a disguised/redirect link (or, in most forums, an image) on the site itself, which results in the referrer being set to the expected value. Plus what do you do with people whose referrers get filtered out for any of the usual reasons? Either deny them access to the feature, or allow it and leave them vulnerable.
The best way to prevent XSRF attacks is to include a authorisation token in every non-idempotent request, which varies (at least) between users, so one person can't guess another's token. |
