CSRF Explained - Best Security Tips offers daily news, information, advices and tips about spyware, adware, viruses, trojans, web vulnerabilities, hackers, other threats    | Register now | Login
   
TIPS NEWS TOOLS DOWNLOADS MALWARE FORUM BOOKS FREE MAGAZINES FREE WEBCASTS & VIDEOS
GFI LANguard Network Security Scanner - Dld 30-day trial! del.icio.us  digg  Furl  NewsVine  Spurl  Blinklist  Ma.gnolia  Reddit  Tailrank  YahooMyWeb 
Best Tips
Security Scanner
Security Categories
Advertise With Us!
Latest Viruses / Threats
Downloads
Security News
RSS / Atom Feeds
Web Application Security: CSRF Explained  
Author: Max : 2006/11/19 Printer Friendly Page Tell a Friend
CSRF Explained 
For the last few days I’ve really been trying to figure out what CSRF (Cross site request forgeries) are. I know that might seem like a pedantic or academic question but it’s really not. Here’s what I’m really concerned with. Without being able to define it we can’t even start talking about how to defend it. Stopping all cross site calls would break the internet and unfortunately wouldn’t solve a lot of the CSRF attacks out there anyway (since many are really SAME site request forgeries).

Here’s what I’m getting at. What if I can force someone to log out. In of itself that isn’t really much of an “attack.” If anything from a security perspective that is helpful because it reduces the overall risks for other CSRF attacks to be successful. However used in some strange DoS attack against the user might prove to be bad. So it’s not the CSRF that’s bad, it’s the DoS that the CSRF helps to create.

Calling a remote function might not be bad (lots of image servers are actually remote databases with an image output). Most would think calling an HTML file in an IMG tag is bad. Well, except if that HTML page is a benign 404 error telling us that the image isn’t hosted there anymore.

There are even more gray areas, like changing someone’s billing information. That would seem to be highly unscrupulous and bad, but if the attacker can’t do anything with it, it really ends up being only a mild inconvenience to the owner of the account when the company in question calls and warns them that their billing information doesn’t match their credit card on file. So while that definitely is a CSRF it’s certainly not an attack of any note. So what is an attack of note? Clearly changing passwords, secret questions or emails qualify. But who’s to say if adding a note to an calendar function or changing someone’s sex from male to female in the database or changing their default time zone is bad or not?

I’ve heard lots of definitions and all of them are skirting around the one major issue, which is what exactly makes the attack “bad” or worth thinking about. XSS seems more clear cut because it’s “bad” if you can get someone else to visit it and if the website is popular, etc… There are a few shades of gray in there but far fewer than with CSRF. If we as a web application security lab can’t define it, how can anyone reasonably expect to stop it?
 

Return to Category | Return To Main Index
Identity Theft Protection Services :
LifeLock Identity Theft Prevention Solution
Veracity Credit Optimization Services
Equifax Credit Watch
Free Credit Report
Identity Truth
Privacy Matters 123