#1 CSRF Is A Vulnerability In All Browsers • Hacker News Board

Re: #1 CSRF Is A Vulnerability In All Browsers

#71

Post by eurleif » Fri, Mar 30, 2012, 10:16 PM UTC

txt wrote: post #68

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…

You shouldn't be able to get the token from another domain, regardless of how long it lasts. How are you able to?

Re: #1 CSRF Is A Vulnerability In All Browsers

#72

Post by kami8845 » Fri, Mar 30, 2012, 10:17 PM UTC

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…

do some friendly hacking to annoy the admins (but only them), and watch them fix the issue in real-time

Re: #1 CSRF Is A Vulnerability In All Browsers

#73

Post by marshray » Fri, Mar 30, 2012, 10:17 PM UTC

tlogan wrote: post #22

I 100% agree - CSRF is a huge hack: basically telling programes to add CSRF to all their forms and requests shows that all these cookies and security measures in browsers are worth shit. It seems like the entire web security needs to be redesigned from scratch.

I agree that web security needs to be rethunk from the ground up, but I don't think it's fair to blame browsers for things that are fundamentally HTTP protocol and server app problems.

Re: #1 CSRF Is A Vulnerability In All Browsers

#74

Post by jberryman » Fri, Mar 30, 2012, 10:18 PM UTC

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…

> but I feel like if I don't do anything someone malicious will discover the issue and cause harm to users of the website.

They certainly will. Usually responsible disclosure is defined as some form of contacting the party involved, working out some window of time that you both agree on during which they can fix the bug (~30 days say), then disclosing details of the vulnerability. This is like a very polite and necessary threat.

If you care I would contact them again and let them know you plan to make the vulnerability public, and ask how much time they need to fix it.

Re: #1 CSRF Is A Vulnerability In All Browsers

#75

Post by DevX101 » Fri, Mar 30, 2012, 10:18 PM UTC

homakov wrote: post #28

rdl wrote: post #20

You realize you could be monetizing these security vulnerabilities, right?

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

Homakov, by doing what you are doing.

A lot of people are watching you from your blog posts and some of these watchers would pay you good money to do a security audit.

I don't know the breadth of your expertise but I would reach out to some well respected security consulting firm and use your blog to demonstrate your interest/passion for web security. This might be a great way to broaden your expertise.

If you contacted 10 security firms, I'm sure at least one would hire you and cover VISA issues if you plan on leaving the country.

Re: #1 CSRF Is A Vulnerability In All Browsers

#76

Post by beneth » Fri, Mar 30, 2012, 10:23 PM UTC

Is this what's happening with "hacked" twitter accounts that don't ever seem to have had anyone access them or change the password and seem to suddenly start spewing bizopp spam for a day or two?

Re: #1 CSRF Is A Vulnerability In All Browsers

#77

Post by huhtenberg » Fri, Mar 30, 2012, 10:24 PM UTC

spamizbad wrote: post #10

I'm having a little trouble parsing this post. Is he saying he's discovered a variant of CSRF that cannot be stopped by using the Synchronizer Token Pattern? Or has he found something that a lot of site's protection patterns don't follow?

You seem to be familiar with the subject. I just read through CSRF and Token stuff on [1] and there's one thing I don't seem to understand.

What would prevent an attacker from open an original site's page in an iframe and then have a script fill in and submit the form on it? In other words, say I am logged in into my bank's site. I then open a malicious page that has an iframe pointing at http://bank/operations/move-funds that contains a fund transfer form. Wouldn't this page include a correct CSRFToken, making the form readily submittable by a malicious script?

[1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%...

Re: #1 CSRF Is A Vulnerability In All Browsers

#78

Post by riffraff » Fri, Mar 30, 2012, 10:24 PM UTC

gibybo wrote: post #62

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.

AFAICT django requires the token as a form parameter, which would be what you suggest doing with javascript.

The issue is the "require that the browser includes it", as the information on the token must be available to the server too, and django apparently puts that in a cookie (rails does too, if the session is stored in the cookie).

So I believe you have suggested a fix for the bit that works already, but not for grandparent's actual problem :)

Re: #1 CSRF Is A Vulnerability In All Browsers

#79

Post by homakov » Fri, Mar 30, 2012, 10:25 PM UTC

kaolinite wrote: post #57

This is a problem with app developers, not browser makers. Applications should follow the HTTP spec and not do any persistent changes via GET. The "I can log you out of Facebook/etc" trick is one of those techniques that script-kiddies love using on forums.

read again, it's not about GET and google trick is just trick.

Re: #1 CSRF Is A Vulnerability In All Browsers

#80

Post by inchcombec » Fri, Mar 30, 2012, 10:26 PM UTC

kami8845 wrote: post #72

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…

do some friendly hacking to annoy the admins (but only them), and watch them fix the issue in real-time

That is TERRIBLE advice. I don't know exactly what you mean by 'friendly hacking' but ANY exploitation of a website vulnerability without that site's permission would be a crime pretty much anywhere; even if it isn't malicious. It would be far from the first time that an administrator or owner didn't understand that the person was trying to help or just didn't really want to deal with it and it then just ended up being an issue of the vulnerability discoverer vs. law enforcement. Never a fun situation even if you win.