I wonder what will happen to websites which use cross-domain post requests to log in securely, e.g. http://example.com submitting the login form to https://secure.example.com
#1 CSRF Is A Vulnerability In All Browsers
81–90 of 256 posts
Re: #1 CSRF Is A Vulnerability In All Browsers
#82Earlier quoted context omitted.
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 contac…
Thank you. I hope so
Re: #1 CSRF Is A Vulnerability In All Browsers
#83Earlier quoted context omitted.
Clarification: he didn't recently find the exploit. He's been making noises about it for a very long time and being ignored, so he took the (dubious, to some) step of using the exploit publicly and loudly, to draw attention to the problem.
Let's be fair to homakov: He used the exploit publicly and loudly (full disclosure to almost all affected parties) by doing a relatively harmless change to _rails_ _master_ on github. If his actions should be called an attack, then it was highly targeted - at the people who could fix it - to get their attention.
His relatively harmless change demonstrated a Major Security Vulnerability in the site that hosts thousands of companies secure code.
Re: #1 CSRF Is A Vulnerability In All Browsers
#84Am I correct in interpreting that the proposed fix would the be the same as the functionality provided by RequestPolicy (which he mentions in the post)? I've used it for quite a while now, and although it works well for me as a power-user (who is concerned about security), I can't imagine the confusion and pain a user will feel despite the message suggested. Blocking resources loaded over separate domains breaks a lo…
"Am I correct in interpreting that the fix would the be the same as the functionality provided by RequestPolicy (which he mentions in the post)? I've used that for it for quite a while now, and although it works well for me as a power-user (who is concerned about security), I can't imagine the confusion and pain a user will feel despite the message suggested."
That was my interpretation as well and I reached the same conclusion. Having the average user make application-level security decisions is a very bad idea.
RequestPolicy is a wonderful extension and I think its use should be encouraged. But the average user does not understand enough about an application and how it interacts with third-party websites to make informed decisions about whether a particular interaction is good or not. False positives (where the user flags a good interaction) will lead to loss of functionality while false negatives (where the user fails to flag a bad interaction) will lead to security vulnerabilities that website owners can't prevent.
Re: #1 CSRF Is A Vulnerability In All Browsers
#85My 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…
Yeah this is something I run into often as I don't accept cookies from sites by default and don't send Referer header (both are required for django's CSRF middleware if over https). This is a good read if you are interested in the rational behind these decisions -> https://code.djangoproject.com/wiki/CsrfProtection
As far as a solution for your users, I'd just let them know that you require cookies to login (obviously) and if you are posting over https make sure they have the Referer header which can be forged to just be the domain and not the entire URL if they prefer. I use https://addons.mozilla.org/en-US/firefox/addon/refcontrol/ set to forge for django sites.
Re: #1 CSRF Is A Vulnerability In All Browsers
#86[deleted]
Re: #1 CSRF Is A Vulnerability In All Browsers
#87I'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-…
are the contents of an iframe open from another domain available to you?
Re: #1 CSRF Is A Vulnerability In All Browsers
#88[ repost from below ]
I just read on CSRF and its mitigation with Synchronized Tokens on [1] and there's one thing I don't seem to understand. What does 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/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?
Can anyone comment? It damn sure looks like a big gaping hole that is virtually impossible to plug.
[1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%...
Re: #1 CSRF Is A Vulnerability In All Browsers
#89My 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…
Yeah this is something I run into often as I don't accept cookies from sites by default and don't send Referer header (both are required for django's CSRF middleware if over https). This is a good read if you are interested in the rational behind these decisions -> https://code.djangoproject.com/wiki/CsrfProtection As far as a solution for your users, I'd just let them know that you require cookies to login (obviousl…
Yeah, there are plenty of reasons to do what you're doing that seem fair to me. But at the same time, through no fault of yours, your requests are indistinguishable from potentially malicious ones. The whole thing is a mess, effectively a band-aid on top of deeper issues with HTTP's statelessness.
Also: that's a good link. Thanks.
Re: #1 CSRF Is A Vulnerability In All Browsers
#90Earlier quoted context omitted.
Let's be fair to homakov: He used the exploit publicly and loudly (full disclosure to almost all affected parties) by doing a relatively harmless change to _rails_ _master_ on github. If his actions should be called an attack, then it was highly targeted - at the people who could fix it - to get their attention.
His relatively harmless change demonstrated a Major Security Vulnerability in the site that hosts thousands of companies secure code.
And got it fixed.
Security vulnerabilities aren't the sort of things that go away just because you don't know they're there.