Paid Advertising
web application security lab

CSRF Isn’t A Big Deal - Duh!

Did you hear the news? CSRF isn’t a big deal. I just got the memo too! There were a few posts pointing me to an article on the fact that CSRF isn’t that big of a deal. Fear not, I am here to lay the smack down on this foolishness. To be fair, I have no idea who this guy is, and maybe he’s great at other forms of hacking - web applications just don’t happen to be his strong point. Let’s dissect the argument, just to be clear:

Even with some of the best commercial Web vulnerability scanners, it’s very rare that I find cross-site request forgery (CSRF). That doesn’t mean it’s not there. Given the complexity of CSRF, it’s actually pretty difficult to find.

Huh? It’s difficult to find with a scanner so therefore it’s difficult to find period? Noooo… almost every single form on the internet is vulnerable to it unless it’s using a nonce. Just because scanners have a tough time dealing with it doesn’t mean it’s hard for a human to find. If you set down your scanner and do a manual pentest once in a while you’ll find that nearly every site is vulnerable to it in multiple places (.NET with encrypted ViewStates are the only sites that natively don’t have this problem regularly).

The good news is it’s even more difficult to exploit CSRF which essentially takes advantage of the trust a Web application has for a user.

What the?! Difficult to exploit? If writing HTML and/or JavaScript is difficult, sure. However, if you have even the slightest idea of how to create a form and a one liner JavaScript to submit it, or even worse a single image tag in a lot of cases, it’s not difficult. It’s not even mildly challenging. The only hard part is getting the user to click on that page with the payload, but even that should still be kitten play in almost all cases through web-boards, spear phishing and the like. Getting people to click on links is insanely easy. Maybe I’m not getting the difficult part. Also, that is a terrible way to think about CSRF - it’s not always about trust, it’s just about getting another user to commit an action on your behalf. Trust is only involved in some instances of CSRF - there are many many examples that have nothing to do with user credentials.

So, based on what I’m seeing in my work I don’t think CSRF is as big of a deal - or perhaps I should say as top of a priority.

No, not top priority compared to something like SQL injection or command injection or something. But yes, it’s very much a big deal. Last week I did an assessment where one of the CSRF attacks would allow me to create a new admin user in the system. A huge percentage of the fraud on the Internet (TOS fraud, not actual hacking) is related to CSRF abuse (click fraud, affiliate fraud, etc…). We’re talking about hundreds of millions of dollars lost to a single exploit and only in those two variants. Like lots of exploits it totally depends on the problem at hand. Sorry, folks, CSRF is not getting downgraded because a piece of software can’t find the issue for you.

52 Responses to “CSRF Isn’t A Big Deal - Duh!”

  1. Mike Says:

    I think this person has common misconcpetions about secuirty.

    Perhaps he should have read this:

  2. Wladimir Palant Says:

    RSnake, are you sure that replying to somebody who clearly doesn’t know what he is talking about is worth it?

  3. Jerk Says:

    Kevin Beaver looks like a Beaver.

  4. Ben Says:

    @RSnake, So now I know where the developer of OpenCart is getting his information -

    In his words:

    “this sort of problem even today effects big sites like gmail, paypal. you really think everything is down to the person who writes the script? or the web user?” and “any good anti virus would stop this sort of problem.”

    I think we need a license’s for the internet with different classes eg: web user, developer. Now wouldn’t that be nice.

  5. Jerk Says:

    Also the definition of CSRF on that site has issues:,,sid92_gci1210029,00.html

  6. RSnake Says:

    @Wladimir Palant - Yes, yes, I do. :) It educates people who may not know better, and it’s a stress reliever. It’s my version of taking a day at the spa.

    @Ben - ouch. That’s unbelievable. Nice quote there though!

    @Jerk - whoah, their definition is even more whack. Geez, no wonder he never finds it, if that’s the definition he’s been using in his assessments.

  7. Dre Says:

    Great post!

  8. mudfarmer Says:

    Even managed to succumb to XSS/CSRF (via Jira/Atlassian):

  9. Michael Says:

    This person probably also thinks that XSS can only pop up a dialog box. Good post RSnake.

  10. Todd Says:

    Great post, see now I can really understand how CSRF is a big deal. I can hide all kinds of crazy js in a link for you to click on.

  11. ToddAO Says:

    The Hacking for Dummies’s author also claims any unauthorized hacking (whether it’s white, grey or black hat) is evil. After reading this post, I’m beginning to question more and more of what he says in his book.

  12. skyphire Says:

    Heh?!. :) actually Apache got hacked through a combination of XSS & CSRF:

    They luckily prevented mirrors to be subverted, image that damage.

  13. Roland Says:

    Great post!
    That “getting people to click on links is easy” is confirmed by the recent hack of

    An user with admin rights had clicked on a tinyURL link which leaded to an XSS hole in the same site.

  14. Kevin Says:

    I’m glad my take on CSRF is sparking some health debate guys. You can read about how I meant this along with my thoughts on Robert’s opinion here:

  15. llvllatrix Says:

    Correct me if I’m wrong, but the reason this attack is so deadly is because it is very difficult to validate the intent of the user in an automated fashion. That property also makes it difficult to detect automatically, but easy to detect manually.

    Are there any other analogous solutions in other domains where they encounter this problem? One that comes to mind is credit card companies.

  16. Brews Says:

    Typo: “However, if you have even the slightest idea of —>how

  17. RSnake Says:

    @Kevin - I understood perfectly what you meant. It appears you didn’t read the last paragraph of my post. Your experience is clearly not acceptable in making a determination of priority because you don’t understand the problem. If you did you would see that it varies wildly on the site and CSRF issue at hand, and it’s not something you can make this kind of blanket statement about - at least not without being wrong. I don’t see anyone (even to use your words, other “leet” grown men with hacker handles, or otherwise) rushing to agree with you either… In fact, quite the opposite.

    If your point was about prioritization entirely I agreed with you (sorta) in that it depends on the exploit (which is exactly what I said above, so don’t pretend like I don’t understand risk, Kevin, as that would be incredibly unwise and incorrect). However, the same with lots of vulnerabilities that scanners do have an easy time finding though, so that’s a terrible argument, and you should not have used the term CSRF at all in your post if that is indeed what you meant - which, of course, you didn’t since it was quite clearly in the title and even now you are saying it doesn’t belong in the OWASP top 10. Keep digging that hole!

    Incidentally, I looked at every post you pointed to on on your blog for places where you said you shouldn’t rely on tools for web application assessments. You’re right, you have written that in the past (most of those posts are not related to this discussion though) but now I have to wonder if you were doing a good job in those assessments if you still think finding and exploiting CSRF is ‘difficult’. Either way, I did find this little nugget on your post about “Why Good Security Testing Tools Matter” “Often, manual testing alone is too time consuming, limited, and difficult.” I do agree with ‘limited’, as scanners can test for millions of things a day, however that is not always the case as there are a great number of commercial tools that simply have no chance of spidering an application that is not ‘normal’ and require some human intervention. But difficult? Time consuming? As opposed to running a scanner, right? As opposed to letting a piece of software do the bulk of your job? Don’t you think it would be prudent to manually test the site for CSRF so you know what it does before you start writing a report on what your customers’ risk is? To use a quote by Robert E. Lee, prescription without diagnoses is malpractice.

    As a general rule of thumb, if penetration testing is ‘difficult’ for a penetration tester, they probably shouldn’t be in this business.

  18. RSnake Says:

    @llvllatrix - you got it! Yes, in fact this attack is sometimes referred to as the confused deputy problem. There are tons of analogies to this in real life where you can’t understand the true intent of the information you are receiving, only that you received it. Snail mail, FAXs, etc… all suffer from the potential for this sort of thing if the person who receives it doesn’t authenticate and authorize the data they receive.

    @Brews - whoops! Thank you! Fixed. I type too fast sometimes and add a few extra words in just for good measure. ;)

  19. Kevin Beavers Must Die Says:

    Until today, i have never ever heard about Kevin Beavers the “Information Security Expert”, so makes me wonder, what are his actual contributions to the “security industry” besides a couple of really bad and non-security-scene-focused books?
    So thats everything i need to make me call an a “Expert”, just a f*cking lame book?

    Anyway RSnake, best we can do is ignore this type of “expert” which are actually just it managers with some sort security certification (probably this guy just get an a CEH cert and then start talk about security like if he was years-experience) and never ever in his live have confront what an actual assessment is.

    PS: Quoting “Kevin Beavers” latest post to the day…
    “There’s something about our field - I’ve met many people over the years who like to find any flaw they can that’s even remotely exploitable - regardless of whether or not it really matters in the grand scheme of things - and make a big deal out of it to justify their expertise and their existence. Given all the issues we face in information security today, that approach just doesn’t add up.”
    LOL, please do no extrapolate behavior MustLive and his “advisories” as the Security Industry behavior.

    PS2: Hope someone put this on the encyclopedia dramatica =P.

  20. Jake Reynolds Says:

    That’s one of the best examples of why a scan is not a penetration test. When it comes down to something as simple as determining whether a request is “action-oriented,” (and thus a good candidate for XSRF) a scanner has a bad day every day. It’s also no wonder why he doesn’t think it’s serious; he never manually tests so he doesn’t understand the vulnerability or pertinent attacks.

  21. Tom T. Says:

    In Kevin Beaver’s response at his blog:

    ” … picking knits …” (sic)

    Now he’s picking on elderly ladies knitting sweaters?

    Doesn’t know the difference between “knit” and “nit”, and we should trust him with our security?

    Yeah, I make a lot of typos too — especially when there’s no “preview comment” pane (cough, cough) — but it’s *his* blog, and he can take all the time he needs to proofread it. Careless.

    BTW, is “rouge” (ladies’ makeup to give their cheeks a little blush) now an accepted 133t misspelling of “rogue” (evil, treacherous, traitorous, lawless), or is everybody just getting careless, and others following their lead? I see it everywhere.

    We whose native language is English should set a better example for those in other countries who are learning it for the Web. Funny thing: One typo in code breaks the whole thing, but apply the same care to English? … thanks for letting me rant. ;)

  22. AppSec Says:

    @Tom T:
    It’s the over-reliance of automated spellchecking and the desire to get things out in the open as quickly as possible.

    I’m severely guilty of it.


  23. RSnake Says:

    @AppSec - amen - I should be shot, drawn and quartered by the spellcheck/grammar police. I have gotten better over the years, but I’m nowhere near being able to cast stones in that regard.

  24. Malcolm McLaren's Ghost Says:

    I want to state up front my intention is not to level a personal or ad hominem attack against Kevin Beaver. Kevin clearly has the talent and ability to run a consulting business, write several books, and publish frequent articles.

    However, after reading his CSRF Q&A, his follow-up blog post, and all the other articles he cites, I get the picture of someone who does not have a deep understanding of application security. He comes across as having performed an abundance of automated, tool-based testing but very little in-depth manual testing. His back-and-forth with Jeff Williams about the OWASP Top 10 is a great example. It’s crazy talk! He wavers between making poorly-expressed arguments, back-peddling on those arguments, and eventually throwing his hands up in the air and saying “well, all web applications are unique so it depends.” That approach reappears numerous times throughout his articles and comments. Since he hasn’t found much SQL Injection — likely during tool-based scans — it “doesn’t exist in the real world.” (ed: I guess the mass SQL injection -> JS injection hacks happened somewhere else…) But since scanners ALWAYS.FIND.XSS, it’s problemo numero uno in the real world.

    One of Kevin’s goals is to convey application security issues to executive management in business-relevant terms. But for someone to try and do this while grossly misunderstanding and misstating the meat is dangerous. RSnake’s Robert E. Lee quote is right on the money.

    A new addition to’s Charlatans, perhaps?

  25. Kevin Beaver Says:

    Hey Guys,

    Again, thanks for all the dialog. I do appreciate everyone’s input.

    It is amazing how supposed colleagues working in the same field can attack like this. I’ve been around long enough to know that no continued amount of rationalization, reasoning, or logic will suffice in such situations.

    None of you know me personally or the quality of work I provide to my clients. It’s easy to take cheap shots in this type of forum. I - and others - hear you loud and clear.

    I wish each of you continued success in our field.

    All the best,

  26. RSnake Says:

    @Kevin - I’m not attacking you, I’m attacking your wildly incorrect assumptions and the way in which you gathered those assumptions. I hope you understand the difference, even though this does reflect badly on your skills, it is not meant to defame you. I actually just don’t want you spreading incorrect technical information to people who are looking to “experts” like yourself for guidance.

    You are both correct and incorrect in your statement above. No amount of rationalization or reasoning will suffice, but logic will and does. The problem is that you are working with logic but have a completely incorrect assumption. Your argument is a great example of post hoc ergo propter hoc - you assume that because you don’t find it and you find it difficult to exploit that other people don’t find it and other people find it difficult to exploit. In reality CSRF is by FAR the easiest client-side vulnerability to build exploit code for and it is trivial to find if you don’t rely on automation to do your job. A fallacy of causality.

    The really troubling part here is that it doesn’t even seem that you understand why you’re wrong, or at minimum you are prepared to defend a completely incorrect assessment of a vulnerability impact that you now realize is incorrect. Everyone makes mistakes, and that I can forgive, if they can admit they are wrong. However, consultants that advise people incorrectly and then fight with real experts even when they are corrected simply scare me. That’s not being helpful - that’s doing the public a disservice.

  27. Greg Says:

    Great stuff all around. One thing not really mentioned is prevalence vs risk. OWASP’s list is of the top RISKS for 2010. Just cuz we don’t see it now does not mean we aren’t at risk. All it takes is a few high profile attacks using CSRF and others will start to use it and voila…prevalence. CSRF is difficult to find and not all that hard to exploit. That is something we need to plug in our apps. It may not be a focus or a “big deal” but that is because we, as humans, tend to be reactive and it only becomes a big deal once it becomes a big deal. And where it is difficult to detect, it is just that much further out in our detection (thus prevalence) timeline. Where the attacks look to come from real people all over the place, how many attacks are going on this moment we don’t know about?

    Kevin’s blog does make one great point (among others) — cover your XSS and SQL Injection holes first. These attacks ARE prevalent and ARE exploited today. Plus, they lay the foundation for things like CSRF to take hold.

  28. Malcolm McLaren's Ghost Says:

    @Kevin -

    I am not attacking you, but I am pointing out your incorrect statements and examples of your lack of web application security knowledge and experience. This is an easy-to-solve problem provided that you’re willing to admit it, learn from it, and fix it. Thus far, though, you’ve demonstrated that you’re not.

    One more example: Your “Authenticated XSS – problem or not?” blog post on the Acunetix (!) site ( states, “But there’s another angle to XSS that no one seems to be talking about – at least I’m not seeing anything on it. It’s the issue of XSS on Web pages that are only accessible when the user is logged in.”

    Just for argument’s sake, let’s ignore the countless examples of authenticated XSS vulnerabilities cataloged thanks to Bugtraq, Full Disclosure, OSVDB, and many other places. (Hint: they’re all a Google search for “authenticated xss” away.) Let’s even ignore the common XSS payload of stealing the session cookies of a logged-in user. THERE ARE EXAMPLES OF AUTHENTICATED XSS FLAWS ON THE ACUNETIX TEST TARGET WEBSITE. THAT ACUNETIX WANTS THEIR SCANNER TO FIND. THAT ARE CLEARLY EXAMPLES OF SECURITY PROBLEMS THAT THEIR CUSTOMERS CARE ABOUT. To “not see” anything about authenticated XSS is the result of not having looked for it or not really understanding XSS in the first place.

    These are not cheap shots. These are examples of how and why your statements are wrong. You’re doing yourself and your clients a disservice if you’re not willing to understand and remedy this.

  29. Malcolm McLaren's Ghost Says:


    To re-state what RSnake said in the original post, CSRF is not difficult to find. If a form does not include a cryptographic nonce (a random one-time-use value included in a URL parameter or POST data value), it’s vulnerable to CSRF; if it does, than it’s not vulnerable.

    Several web scanners even do a decent job of flagging CSRF. But a smart human needs understand context of the specific form and the application in general to assess the risk. CSRF in a “search” form may not a big deal, but CSRF in a form to provision accounts, transfer money, or perform other high-value actions could be.

  30. TheLightCosine Says:


    I find CSRF on almost every single webapp i test. Every report I write, I have to include an item about post actions requiring a token. So i’d say prevalence is there. As for impact, I don’t see how it’s not obvious the potential impact. It cuts right to what I believe to be the very core issue of information security: trust. CSRF is a horrible violation of application trust boundaries. I don’t know about what methodologies everyone else uses, but when I do threat modeling of an application, that is an entire step, looking at the system of trust. CSRF is imo a FUNDAMENTAL failing of an application’s security model.

    Anyways, that’s my little two cents rant, and I’m a nobody lol! btw, RSnake, love your site keep the posts flowing.

  31. TheLightCosine Says:

    oh and on a side note:,,sid92_gci1210029,00.html who the hell wrote that definition, and has anyone emailed them to tell them how whack it is?

  32. RSnake Says:

    @Kevin - Another blog post with all kinds of fail in it:,289483,sid92_gci1381093,00.html

    I’m not seeing GET requests being used all that often but when I do it’s usually a big exposure.

    Wtf? You aren’t seeing GET requests all that often? How? Maybe you’re only talking about user submission of data…. and even then, if you discount tracking scripts and analytics, etc… you’re probably only still barely right. But that probably deserves a major caveat that you didn’t put into your post. I hope you realize there are way way more sites and pages that use GET than use POST. Like, orders of magnitude more. I also hope you realize that most of the time it ISN’T a big exposure, despite what you’re “seeing”. Is what a user types in a search box a big exposure? Maybe but more likely than not, no… well then you can remove a majority of GET submission of data from your list right there.

    However, security is about taking reasonable steps to eliminate the urgent and important stuff – especially the low hanging fruit – in order to minimize risk where you can. Do yourself and your business a favor and avoid using GET requests at all costs.

    GET vs POST is urgent and important stuff and CSRF isn’t? Wow! Granted, there are some truths to your post around how data gets logged, but your conclusions are wildly off base and you failed to mention alternate methods of protection. There are ways to avoid information leakage from happening - like using SSL/TLS and not allowing the browser to cache the content, which you totally don’t speak to. If the user is submitting information to a server that deserves to be protected, it should be taking the non-cacheable SSL/TLS approach anyway, so that argument doesn’t make much sense. Your argument about what is being logged is also not super on the ball because if companies aren’t logging data that’s being sent to them they will have a far harder time doing forensics. It’s how the logs are stored that’s the issue, not that it’s being logged. I actually agree this sort of content should be in POST requests in most cases but because of shoulder surfing, which escaped your post somehow, given that it’s one of the biggest problems.

    You can build a GET submission and do it securely, even from shoulder surfing with the use of iframes, etc… which you don’t talk to at all. Either way, information disclosure and CSRF have wildly different threat classifications. Granted, it depends on the vulnerability, but information leakage is almost always lower in DREAD severity than trust boundary issues (not always, but most of the time).

    Again, bad advise and bad conclusions related to your understanding of web applications… I’m sensing a theme.

  33. Yvette Francino Says:

    I’m a new site editor for Kevin made me aware of this thread and the debate over his article. He’s recently amended it to add further information. Kevin is also helping us with a rewrite for our definition of CSRF. I’m not sure where the original came from, but appreciate the head’s up about it’s lack of accuracy.

    @RSnake, if you or others would like to offer an alternative viewpoint on the importance of CSRF for publication on our site, please feel free to contact me at You are also welcome to add your input for the definition.

    If in the future, if you see definitions or other areas of concern about the content on, please feel free to contact me at

    Thank you

  34. RSnake Says:

    @Yvette - I see Kevin’s update, but it’s just as bad as the original. This is part of the update that’s just incoherent and wrong:

    CSRF doesn’t exist everywhere. I rarely see CSRF using both automated scanners and manual analysis.

    Don’t you see what’s wrong with these two sentences side by side? He doesn’t find it, so it’s not there? It’s nonsense! If he was doing even a vaguely good job he would find out he’s wrong and it is indeed on almost every dynamic website. Scanners have almost no chance of finding CSRF in most cases so that’s a ridiculous thing to write in the first place - just proving he doesn’t understand.

    Your definition of CSRF looks like it’s been written by someone who only vaguely understands the basics of the attack, so it’s no surprise that Kevin’s updates aren’t helping your cause. It’s just completely wrong in many ways:

    An XSRF attack can be executed by stealing the identity of an existing user and then hacking into a Web server using that identity.

    In no way is that sentence a good definition of CSRF. If you steal a user’s identity you don’t need CSRF - you have their identity and you can just perform the action in question with those credentials. That’s not what anyone who has any clue thinks a CSRF attack is. It’s just plain wrong. Kevin isn’t helping you here.

    Cross-site request forgery (XSRF or CSRF) is a method of attacking a Web site in which an intruder masquerades as a legitimate and trusted user.

    Again, Kevin isn’t helping you here if that’s what he thinks CSRF is. It has nothing to do with masquerading - it’s getting another user to perform an action on an attacker’s behalf. In other places your definition rambles and talks about issues like using TRACE which doesn’t even work in modern browser anymore and hasn’t for years and has nothing at all to do with CSRF. Then onto XSS with one of the worst definitions of that attack ever… *shudder* It’s painful to read:

    …the hacker inserts malicious coding into a link on a Web site that appears to be from a trustworthy source. When an end user clicks on the link, the embedded programming is submitted as part of the client’s Web request and can execute on the user’s computer.

    I mean, holy crap! This is a terrible explanation of one variant, and the way you described it actually could be CSRF as opposed to the crazy definitions above. CSRF can be used to submit the payload (and in fact almost always is - another thing that scares me about Kevin’s understanding of all client side attacks).

    I’m sure others will take up the challenge of helping you re-write it, but you should keep Kevin away from web application security writing in general until you get a good technical editor to fix his assumptions or he gets some expertise on the subject matter.

  35. Malcolm McLaren's Ghost Says:


    I read Kevin’s “Application security checklist: Ways to beat cross-site request forgery” (,289483,sid92_gci1381044,00.html), which is now linked from his updated “Is cross-site request forgery…” article, and had to comment on the (lack of) quality of that as well.

    If I was a developer who didn’t understand CSRF and read “Ways to Beat…”, it would further confuse me and give me no real workable tips to actually fix CSRF in my applications. It would be 1000x better if the article was just a single sentence saying “CSRF is bad; validate all application actions using a one-time nonce.” He doesn’t mention using a nonce at all in the article. Instead, the tips offered to “beat” CSRF are gibberish. Kevin meanders around, making points that are either confusingly explained, incorrect, not effective, or way off point (under-secured wireless networks? weak passwords?).

    For an example of good writing on CSRF, compare iSec Partner’s CSRF whitepaper ( to Kevin’s articles.

  36. RSnake Says:

    @Malcom McLaren’s Ghost - I hadn’t seen that. Good find. One of my favorite quotes:

    Don’t focus solely on browser-side vulnerabilities looking at how HTML and JavaScript objects are handled. If you use Flash or movies or host other files such as Word documents, CSRF may be possible there as well so don’t overlook them.

    Wow - CSRF against Word documents. In fairness, I now get how he sees what CSRF is (I think). It appears that he basically believes the way it gets executed is when someone is allowed to embed content on the site (making it same site request forgery if anything). But at least now I see why he rarely finds it - he’s looking for the wrong thing.

    And for anyone reading this paper, please please don’t take his advise and block on referring URLs that don’t match your domain. That’s amateur hour. You’re going to have a ridiculous amount of false positives as there are lots of security solutions that remove or modify referring URLs as a security practice. Nonces are the only reasonable solution to CSRF and even that requires the site is otherwise free of any vulnerabilities that would allow the attacker to read the content from the domain (XSS, command injection, SQL injection and so on).

  37. llvllatrix Says:

    With respect to CSRF, this thing is kinda scary:

  38. Malcolm McLaren's Ghost Says:

    @RSnake - Yeah, the part about Flash, movies, and Word docs was equally incomprehensible to me. Does he mean exploiting CSRF vulns in those media or *using* them to exploit CSRF? Regarding CSRF and Word docs, is he tipping his hat to and ? I can’t figure out how much of it is just bad writing and how much of it is him not understanding the topic. It’s like reading computer security articles as generated by SCIgen ( :>

    And regarding referer-checking, if Kevin’s going to give bad advice to fix CSRF, at least give correct bad advice:

    Are referrers in the HTTP header validated to ensure requests are not[sic] originating from authorized[or sic] sites?

    I really want to stop discussing this though, as to not bring any more attention to it. With all due respect to Kevin and TechTarget, I hope no developers or security professionals are getting any application security tips from there, at least until the errors are corrected and the content quality improves significantly.

  39. RSnake Says:

    @Malcolm McLaren’s Ghost - I can’t imagine how you would exploit Word using CSRF so it has to be using Word to exploit CSRF flaws on a site somewhere (speaking to the links you pointed out). Kevin’s thoughts are just so poorly written, it’s nearly impossible for me to decipher.

    Funny about the referrer quote - I had missed the word “not” in there as I skimmed it. The funky part is I can’t tell if it’s a typo or that’s what he thinks should happen. I feel like I’m trying to translate into another language.

  40. Jeff Williams Says:

    Unfortunately, Kevin’s worldview is extremely widespread. Even though the visibility you get from running tools alone is extremely limited and not nearly complete enough to make good risk decisions, that’s exactly what lots of organizations are still doing.

    Here’s the link to the similarly flabbergasting discussion I had with Kevin several months back. Shame on all of us for not making the truth more visible.

  41. The_Exploited Says:

    Great post man.


  42. RSnake Says:

    @Jeff Williams - I am astounded with how professionally you handled that interaction with Kevin, considering how he defends his ignorance and accused you of not having enough experience with large customers. Laughable! You are a better man than I.

  43. AppSec Says:

    I’m not going to be critical or defend Kevin for two reasons:
    1) We don’t know the sytsems he’s testing. Maybe he’s been “fortunate” enough to work on systems where XSRF is not really all that possible (multi-page flow transactions where the server is actually enforcing page flow).. Or he could work on a lot of .NET applications (the ViewState does a very good job at preventing XSRF from what I’ve seen — all be that very limited).

    2) I think there’s an inherent (this goes back ot that whole spell checking thing again, doesn’t it RSnake? :-) ) issue with how application security is run — and unfortunately I have not found the way to address that.

    I will be blogging about this later and I hope that I can get people to actually look at it and comment. I’ll just say it deals with three thigs: perceptions and reality of time to deliver, the good old 80/20 rule, and the fact that software engineering is just that — engineering (where art meets science).

    But there is one thing that I’m more surpirsed by then the XSRF is that Kevin hasn’t seen a lot of Insecure Direct Object reference. I see that all over the place — even on apps which have XSRF protection.

  44. RSnake Says:

    More from Kevin:

    Glad to see he’s still in violent agreement with himself! Guess his editor isn’t so sure anymore.

  45. arshan Says:

    When I saw 40+ comments, I knew it would be good - but not this good. In the article where he bangs his head against the wall while Jeff watches, he’s able to siphon data out of a database with a (presumably blind) SQL injection vuln.

    The next article, he can’t find or exploit CSRF? Here’s a pro tip, Kevin. During your next assessment, just pick 5 forms at random on the website, report them as vulnerable, and you’ll probably be 80%+ accurate.

    Maybe all his clients use souped up ViewStates or RoR+protect_from_forgery. Or, maybe - and I’m just spitballing here - he should never write another article again?

  46. Mephisto Says:

    I’m starting to be of the opinion that CSRF should be more widely scoped in its definition. Traditionally, CSRF has been all about executing an action without the users knowledge. However, recently I’ve seen apps that prevent execution of actions, such as change password, yet still allow requests to pages that contain sensitive information.

    I successfully request a user’s “Profile” page on a website via a simple CSRF GET request and that XMLHttpRequest responseText returns me information such as their name, address, city, state, zip code, username, account number, etc…

    I haven’t directly performed an action, but I’ve been able to request a page that returns sensitive information about this person. From there I can execute further attacks (social engineering against user or company, brute force, etc…)

    Just my opinion, but being able to grab potentially sensitive info can be just as bad as sending a CSRF request to change a user’s password.

  47. Jerk Says:

    Kevin is an interesting study in human psychology.

    A primary threat that he should be feeling is to his status among his peers. This is a strong threat, especially for men. The response to this threat is a drastically diminished ability to use his pre-frontal cortex (the logic center).

    Ever since his argument was challenged, his reactions were first to attempt to regain his status through further explanation (”You can read about how I meant this”), and then to reduce the continuing damage to his status either by attempting to stop further discussion (statements like “end of story” or “no continued amount of rationalization, reasoning, or logic will suffice”) or by changing the subject (”It’s easy to take cheap shots in this type of forum”).

    To see such a clear example is quite fascinating.

  48. MrAnderson Says:

    It’s not a big deal. Period.

  49. vampire Says:

    Someone want to try my site if still vulnerable in CSRF??or sql inject.I build this community site secured and no one can hacked it..

  50. austin Says:

    csrf not a big deal?
    i recently made a web mail module for a web app at work, and i had to spend well over 2 weeks just on securing it…its the ONLY place a user can put in information which can display html. and csrf/xss was one of the hardest (sql injections were a little tricky but everyone knows how to sanitize database inputs) because its so diverse.
    few things i had to do:
    1:because they could add attachments i had to make sure that the section of the site which held attachments did not take cookies and did not execute scripts. imagine someone uploads a php file to some area you didnt take this precaution for then uses an xss/csrf to make you go to that page…or hell even just links to the page itself which being php could be damn near anything
    2: i had to make sure that no images linked to the site itself except areas specifically allowed for images and images only.
    3:the server does a header check on any images and if it returns a code between 300 and 400 (304 excluded) then it removed the source from the image.
    4: disable MOST attributes on a tag (anything on* onclick onload etc, also anything which evaluates to or can evaluate to “script”)
    5: no css…period…(you try programatically stopping evaluate e/**/valutate ev/**/aluate and all the myriad ways you can obfuscate that in css
    6: no objects…period…(object type=”text/html” or even object with the clsid and its many ways of obfuscating or any other way they can make an object put out html…just…no…)
    7: a whitelist of acceptable tags (b,a, font,i dont remember them all but there are like 12) so your little obfuscation of the word script wont work.

    i think there are more but those were the biggies…
    things you could potentially do with xss and csrf: delete users, submit forms that use get, create and subsequently submit forms using post, steal a person’s cookies and pretend to be them (that was a big one on a social networking site i was working on. my god the amount of attacks i did on that site and was able to steal cookies. i keep them commented in my profile so i dont forget…and so i can show the boss “all these went through…i have since patched them”) and all sorts of mayhem can result from THAT, make transactions in their name from a site they have visited that also thinks csrf isnt a big deal, etc.
    i have made a feature request to firefox to add an html attribute for images “noRedirect” that tells the browser NOT to follow a redirect on an img tag (may be useful for other tags too) then the server needs only force that attribute onto an img tag rather than doing the lookup themselves slowing down the page load process. hopefully they do and it gets picked up by other browsers or maybe even becomes an html5 standard…that would make stopping img redirect based csrf vectors much easier.

    of course nothing i can do can stop users from clicking a link…short of disallowing links…

  51. keserix Says:

    guys, look owasp top 10 about CSRF and XSS. In security point of view you need to think in risk rating perspective. Probability of exploiting the user with CSRF espicially on any logged in application
    is depends on your chance..

    SO CSRF and XSS on authenticated applications are not a big deal, but its a deal in public applications or stored based scripting forms..

  52. RSnake Says:

    @keserix - please research Microsoft’s DREAD severity. What you’re talking about is “E” exploitability. That doesn’t change the other variables D R A D. It does reduce the overall score slightly, true, but it doesn’t make it a minimal risk. Maybe from a high to a medium for instance, but again, it depends on what it gives the attacker.