how-to block ads
|
EGeezer
Spring is here
Premium
join:2002-08-04
Central Ohio
clubs:
 ·AT&T CallVantage
 ·RoadRunner Cable
| CSRF article
Here's a follow-up article on Daniel  's topic (the topic is over two weeks since last update, so a new topic is indicated);
In this latest installment, WhiteHat finds nine out of 10 websites still have serious vulnerabilities that attackers can exploit; and that there is an average of seven vulnerabilities per website. The top 10 list has remained somewhat static over the past several months withCross-Site Scripting (XSS) as the top vulnerability class, appearing in approximately 70 percent of websites. However, CSRF, while known in the public domain for years, has recently garnered more attention from malicious hackers. Attackers using CSRF can easily force a user’s Web browser to send unintended HTTP requests such as fraudulent wire transfers, change passwords and download illegal content.
Article here.
NOTE: The linked article is a press release by a company who sells a product that deals with the issue, So, one should deal with the report as a marketing as well as an informational tool. The reports in the press release link require registration with contact information.(I have my own opinion on that, but that's a separate topic). I suspect that Charles Chaplin has requested a copy, and can be reached at Hannaford corporate headquarters' general phone number ...
While the stats seem a bit hard to believe, if they are even 20% true, it still demonstrates that security at the application development level has a long way to go. These exploits are not OS exploits, so blaming Microsoft, Linux or Unix does not lead to any meaningful solutions. Blaming the browser makers also doesn't lead to solutions. The key point here is the need to develop more secure web applications rather than further crippling browser functionality used for legitimate "trusted" sites.
For more reading on application security, see
»www.owasp.org/index.php/Main_Page
and
»www.webappsec.org/
--
Mayors of New York come from nowhere and go nowhere.
Wallace Sayre (apparently, so do governors... ) | |
bobince
join:2002-04-19
DE
| 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. | |
|
