Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

#1 CSRF Is A Vulnerability In All Browsers

homakov.blogspot.com

Post reply on HN
Print view View original

61–70 of 256 posts

Re: #1 CSRF Is A Vulnerability In All Browsers

#61

Post by someone13 »

A bit of a note regarding REST:

RESTful services are as vulnerable to CSRF as anything else. See [1] for more information (and I'm really sad that there's no second post, like mentioned). However, since RESTful services imply no state on the server (i.e. no token), the question is, how do you prevent CSRF attacks?

One really simple method is to deny all requests (on the server) with the application/x-www-form-urlencoded content type, and deny all multipart/form-data requests that include non-file parameters, which are the only two content types that can be sent from an HTML form. For your application, XMLHttpRequest can change the content type, and isn't affected by CSRF.

EDIT: Also, sort-of-related: I recommend you set the X-Frame-Options header too, in order to prevent clickjacking. Info at [2].

[1]: http://blogs.msdn.com/b/bryansul/archive/2008/08/15/rest-and... [2]: https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_respons...

Re: #1 CSRF Is A Vulnerability In All Browsers

#62

Post by gibybo »

davepeck wrote: post #25

My app's web site is built with Django. I use the built-in CSRF tools. (I should emphasize that my site is strictly HTTPS.) In theory, no normal user will ever fail CSRF checks. In practice, tons of people have complained that they see Django's (very confusing) CSRF error page when they try to sign up for my service. This was surprising to me; I thought we were _way_ past this point. Digging into it, I've learned tha…

I am not familair with Django's CSRF tools, but you could write your own that didn't depend on cookies. Init a js var with a random token in the html somewhere, then require that the browser includes it with any state changing actions.

Re: #1 CSRF Is A Vulnerability In All Browsers

#63

Post by seanp2k2 »

rdl wrote: post #34
homakov wrote: post #28

Earlier quoted context omitted.

how? If I report nobody pays even 'thank you'.

Fuck reporting it, unless you're contractually obligated because they've retained you (or, if it's an open source project you like, and want to support). If vendors won't even listen to you, clearly they don't value your time or their product, or their customers. You can sell security vulnerabilities to a variety of parties. If you want introductions, email me. Some people view this as "wrong" in some ethical way, bu…

>"Money is good -- it can be exchanged for valuable goods and services."

Money is not "good". Money is "necessary" in our society because people are greedy bullies.

Re: #1 CSRF Is A Vulnerability In All Browsers

#64

Post by timmaxw »

postfuturist wrote: post #53

Google allows a logout from a GET request, on Chrome of all browsers? Is there a way to run browser tabs completely sandboxed regarding cookies/auth? (private browsing mode and running different browsers is a bit too clunky)

Chrome allows you to set up multiple user profiles; each one is isolated from the others. Like Incognito mode, it's per-window, not per-tab. I have one for GMail, one for Facebook, and one for everything else.

Re: #1 CSRF Is A Vulnerability In All Browsers

#65

Post by homakov »

mcherm wrote: post #43
homakov wrote: post #28

Earlier quoted context omitted.

how? If I report nobody pays even 'thank you'.

That is true for some people, but NOT for all. Recognized security experts, or anyone with a reputation in the field CAN get themselves heard, and information which they report will NOT be ignored. (Whether you will get paid for it is another matter. It depends.) You used to be a "nobody" -- just some unknown developer whose English communication skills are a bit weak and who was likely to get ignored. That is no lon…

>are a bit weak don't be too polite ) I reported holes that definitely should be reported.

Re: #1 CSRF Is A Vulnerability In All Browsers

#66

Post by someone13 »

gibybo wrote: post #56
ck2 wrote: post #44

Don't allow actions through GET, always use POST.

That doesn't solve it because the attacker can just create a and auto submit it with js (or make a translucent submit button that is the size of the entire page if you have JS disabled).

For example:
The massive button is left as an exercise to the reader ;-)

Re: #1 CSRF Is A Vulnerability In All Browsers

#67

Post by citricsquid »

kaolinite wrote: post #48
citricsquid wrote: post #40

Maybe this is a good time to ask: I found an xss vulnerability in a website that can be used to cause noticeable problems (enough that fixing it should be a priority) so I contacted the developers behind the site and informed them what caused it, how to fix and an example of it in practice and why it's bad: they've done nothing in over a month. What do I do? I guess the answer is "forget it", but I feel like if I don…

Is it a persistent XSS vuln or does it depend on malicious input being passed via the URL or POST? It's persistent if it can be saved in a comment or on a profile, etc, and is much more dangerous if so. Non-persistent XSS realistically isn't too big a deal, most sites are vulnerable and it's usually only a problem if you're a big website and therefore vulnerable to phishing attacks.

I can link someone to a page and it can associate them with something they can then never disassociate themselves with. For example I could create an account, post illegal content (child pornography etc.) on the site then get people to click a link and forcibly associate their account with that content, which they are then tied to until a site administrator realises and fixes it. (edit: without them ever knowing)

Imagine if I could make you the author of this comment, it's like that.

Re: #1 CSRF Is A Vulnerability In All Browsers

#68

Post by txt »

Adding a extra token for protection against CSRF attacks will only work if is changed on each request. Some of the biggest sites out there do not do this. I know of one site in particular (I won't name it, but its HUGE) that generates a unique token every time a user logs in. The token doesn't change until the user logs out even if the user closes the browser and doesn't go back to the site for a week, the token will be the same. So it does its job, until somebody like me pokes around and finds a hole that will parse out that token, and generate a form that can make any request on behalf of that user in a iframe without that user knowing a thing. Evil yes, but I found this months ago, and it still works..and I haven't used it in anyway, besides a proof of concept.

Re: #1 CSRF Is A Vulnerability In All Browsers

#69

Post by iamwil »

I'm having a bit of trouble parsing the post. Did he just discover CSRF and is trying to raise awareness? Or did he discover a new variant of CSRF that makes previous counter-measures ineffective?

For completeness, Rails guide covers these security holes http://guides.rubyonrails.org/security.html#cross-site-reque...

Re: #1 CSRF Is A Vulnerability In All Browsers

#70

Post by vectorpush »

it took me a long time to understand the point behind CSR (cross-site requests) and CRSF fully enough to find them EXTREMELY malicious.

I think this is a very important line. The sense I get around most of my colleagues is that CSRF exploits are only something "bad programmers" get wrong. Of course, they're all rockstars who've never been exploited (yet/AFATK) so it's not like they need to spend a weekend or five paging through droll security papers. A little modesty would do us all well.

90% of developers just don't care and don't spend time on that.

Indeed. It takes time to learn, time to code, and unless you're working at a big shop, there's little pressure (or even acknowledgement of the need) to get this stuff right.

Keep up the good work OP.

Post reply on HN