10 ms·
#1 CSRF Is A Vulnerability In All Browsers
First article that makes the point.
- akavlie 15y agoFor those who didn't see the recent kerfuffle: This guy recently found and demonstrated a major Rails exploit on github. He seems to know a thing or two about security exploits.
- rosser 15y agoClarification: 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.
- seanp2k2 15y agoAnd we all saw what happened: Github got in gear real quick and rolled out a fix FAST. Point, dood.
- sounds 15y agoLet'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.
- arohner 15y agoHis relatively harmless change demonstrated a Major Security Vulnerability in the site that hosts thousands of companies secure code.
- jbri 15y agoAnd got it fixed. Security vulnerabilities aren't the sort of things that go away just because you don't know they're there.
- tptacek 15y agoFrom experience: had he simply told Github about it, they would have fixed it quickly, and there would have been no window of public exposure. That's the point being made here.
- sounds 15y agoFair enough, that's basically what was said in the bug he filed with Ruby on Rails. I won't try to impute motives but I think he did it this way because he felt like he was being treated poorly.
- arohner 15y agoThere are two different issues here. 1) A bad security vulnerability at GitHub. 2) Poor design in Rails that makes it easy to produce security vulnerabilities. Igor found 2, and got ignored by the Rails team. His frustration led him to publicly demonstrating 1, which caused a whole lot of people a whole lot of trouble. The people that are irritated at him are irritated at him because of 1, not 2.
- deleted 15y ago[deleted]
- mhurron 15y agoWhat kind of serious company puts important or 'secure' code on github?
- ig1 15y agoNo, he was making noise about a class of exploits and then exploited a particular instance of that exploit, which is completely different. It's like the difference between the class of buffer overflow exploits and the buffer overflow exploit in a particular piece of software. There's a significant difference between the two.
- technoweenie 15y agoAnother clarification: He wasn't making noises for a long time with _GitHub_ and being ignored. His support responses were replied to nearly immediately (except where the timezone differences came into play). We take security reports very seriously. We'd have preferred a more responsible disclosure, and I hope he (and others) are more careful about this in the future. Most reporters we get act very responsible, and we are always gracious (and even contract work from them in some cases) In his case, we saw activity that he didn't report to us, and suspended his account while we did a deeper investigation. The Rails community and we still think that his proposed solution is not a good idea, but it did provoke exploration in some other ideas. https://github.com/rails/rails/issues/5228 https://github.com/rails/rails/issues/5228 http://techno-weenie.net/2012/3/19/ending-the-mass-assignment-party/ http://techno-weenie.net/2012/3/19/ending-the-mass-assignmen... http://weblog.rubyonrails.org/2012/3/21/strong-parameters/ http://weblog.rubyonrails.org/2012/3/21/strong-parameters/
- ricardobeat 15y agoI'm sorry, but why should he? If I find a major hole in SHA1 key handling, should I contact GitHub since you are users of it? Of course not.
- nbpoole 15y agoThere's a difference between complaining about a class of vulnerability and exploiting a particular instance of a vulnerability that you seem to be failing to grasp. If you find a major hole in a part of Git, you are by no means obligated to tell GitHub. You are, however, legally obligated not to compromise their site using that hole. Or, a better example: you can talk about XSS mitigation strategies all you want. You can't go around looking for XSS vulnerabilities on random websites and then exploiting them.
- ricardobeat 15y agotechnoweenie pointed out that he wasn't being ignored by GitHub, I was saying that's irrelevant. GH is just one of thousands of Rails apps that were/are vulnerable. > You can't go around looking for XSS vulnerabilities on random websites and then exploiting them. exploit: to use a situation so that you get benefit from it, even if it is wrong or unfair to do this; to utilize, especially for profit; etc
- homakov 15y agoI'd not say so. All new - well forgotten old.
- jorgem 15y ago"April fools day" will not be a good day for him to publish "secret stuff".
- elisee 15y agoJust in case it might be a problem for anyone: The article uses the CSRF vulnerability to log you out of all Google services (and says so in a PS at the bottom). Don't open the article if you don't want to have to log in to Google again afterwards (might be a problem if you're using two-factor auth and you don't have your phone handy for instance).
- homakov 15y agohm yep. should I hide that thing? hm.. Sorry guys in advance.
- spicyj 15y agoIt'd be nicer if you had a link to a separate page that does it so that people can read the post first.
- olex 15y agoYou could make it into a button: "Log me out of Google" or something like that. That way, you can still demonstrate it's easily done, but only people who are interested will see it.
- sedictor 15y agoWell, you are jerk
- jerrya 15y agoFWIW, Worked in firefox. Didn't work in Chrome or Opera.
- redthrowaway 15y agoWorked in Chrome for me on Vista (work comp).
- colkassad 15y agoworked in Chrome for me
- 15y ago
- spamizbad 15y agoI'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?
- homakov 15y agonope. Token Pattern is ugly workaround browsers' vulnerability - that's the point.
- spamizbad 15y agoYou know more about this stuff than me, but I always assumed it was the cost of using the HTTP protocol due to its stateless nature. Even if browsers "fix" this issue, you're still placing a measure of trust in the client by not implementing server-side protections.
- tptacek 15y agoHe is incorrect on this point. Authentication of requests is not an "ugly workaround" to a browser security issue. The browser isn't just doing what it's "supposed to be doing" (always a flimsy argument in favor of the status quo, I agree!) but also all it can do, since only the server has the information needed to judge how sensitive a request is. It's true that servers & browsers work together to create a semblance of a security model for the web. But the bulk of the job belongs to the server; there are hundreds of thousands of different applications each with different needs. And the servers have a means of enforcing controls flexibly: by authenticating requests. The browser isn't protecting your email. The server is. The browser isn't protecting your bank account. The server is. The browser isn't protecting your HN karma. The server is. The browser isn't protecting your code repository. The server is. No simple HTTP standard will cover all these cases, and so it's silly to suggest that HTTP is where this security controlled should be expressed.
- epimenov 15y agohe discovered that you can log out from google via a GET request (surprise!)
- dfc 15y agoRequestPolicy + NoScript are the big reason I have not switched to chromium. In order for requestpolicy to block this it needs to be in a fairly locked down state too...
- rdl 15y agoYou realize you could be monetizing these security vulnerabilities, right?
- homakov 15y agohow? If I report nobody pays even 'thank you'.
- rdl 15y agoFuck 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, but meh. Money is good -- it can be exchanged for valuable goods and services. There have been a lot of arguments for "responsible disclosure", "anti-sec", "full disclosure", etc. over the years. I'd draw the line at blackhatting yourself with the vulnerability, but just selling the info is legal. Generally, security companies are buyers, and their clients tend to be governments, generally western (USA).
- mcherm 15y agoThat 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 longer true. You are now "famous" in security circles, and if you approach people in a professional manner then I am confident that you will be heard.
- tlogan 15y agoI 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.
- marshray 15y agoI 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.
- brian_peiris 15y agoHe logs you out of Google with a simple <img style="display: none;" src="https //mail.google.com/mail/u/0/?logout">
- davepeck 15y agoMy 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 that tons of people use extensions that muck about with cookies in ways that break Django's CSRF feature. I don't really know a way around it. How common is this, in your experience?
- homakov 15y agoI've been examining django sites either. confirm
- gibybo 15y agoI 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.
- riffraff 15y agoAFAICT 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 :)
- jasonkeene 15y agoYeah 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 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/ https://addons.mozilla.org/en-US/firefox/addon/refcontrol/ set to forge for django sites.
- seanalltogether 15y agoIs a GET request in an iframe now considered a CSRF vulnerability? As far as I know, he hasn't actually done any cross site scripting. If i submit this as a link on hacker news and get a bunch of people to click it, have I forged a cross domain request as well? https://mail.google.com/mail/u/0/?logout https://mail.google.com/mail/u/0/?logout
- homakov 15y agoIt has nothing to do with future posts, I repeat...
- ketralnis 15y agoI interpret CSRF (cross-site request forgery) to be different from XSS (cross-site scripting). This particular vulnerability is indeed a CSRF, but not an XSS which is what it sounds like you're confusing it for.
- christianmann 15y agoCross site scripting (XSS) is not the same thing as CSRF. If you were to do that, it wouldn't be a CSRF, because the action originated with the user. Normally CSRFs are automatic, either in the form of an image (<img src="https://...?logout https://...?logout />) or an iframe src attribute. So, if you included the above image tag on your page, then it would be a CSRF, sometimes also called a Confused Deputy Attack.
- gibybo 15y agoCross site request forgery is separate from cross site scripting. He is not clamming to have done any cross site scripting. Secure sites generally require a token to perform any state changing effects, it's just odd that Google doesn't require it for logging out. Facebook uses http://facebook.com/logout.php http://facebook.com/logout.php to log you out, but clicking that link won't do it.
- streptomycin 15y agoIf Google would prefer that any random website can't log its users out of its services, then yes, it's a CSRF vulnerability.
- djbender 15y ago"Jeff Antwood" Entertaining read.
- infinitivium 15y agoOkay, this is a good idea, but how would it handle legitimate requests to other domains? Issues: - some users would click allow anyway, so it doesn't completely solve the problem - what about apps built using CORS.. etc
- HeyImAlex 15y agoAren't you protected if you just use csrf tokens on sensitive POSTs? I thought it was good practice to always do that anyways.
- sedictor 15y agoWOW You've discovered absolutely new type of vulnerability! Awesome work! lol lmao
- homakov 15y agono food for troll here
- jiggy2011 15y agoCSRF is a bit of a pain to work around but how much of a problem is it in the wild? Most sites where this could do real damage (and have real gains for the attacker), banks etc are going to be well protected. You could use it to comment spam a blog but that's going to be a crapshoot. Guessing which blog people are logged into etc, you would need very targeted attacks. Sure , signing out of google is annoying but if you have lastpass or similar signing back in is pretty frictionless.
- homakov 15y ago>Most sites where this could do real damage (and have real gains for the attacker), banks etc are going to be well protected. You think so. In "the wild" even serious systems are vulnerable #OpApril1
- ceol 15y agoWhy are you spacing out the "release" of your information? I assume you've found some CSRF vulnerabilities?
- gibybo 15y agoGmail has had more serious CSRF vulnerabilities in the past - you could use it to download the entire address book of anyone who visited your site.
- citricsquid 15y agoMaybe 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't do anything someone malicious will discover the issue and cause harm to users of the website...
- kaolinite 15y agoIs 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.
- citricsquid 15y agoI 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.
- kami8845 15y agodo some friendly hacking to annoy the admins (but only them), and watch them fix the issue in real-time
- inchcombec 15y agoThat 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.
- ck2 15y agoDon't allow actions through GET, always use POST.
- gibybo 15y agoThat doesn't solve it because the attacker can just create a <form> 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).
- someone13 15y agoFor example: <body onload="javascript:document.evil.submit()"> <form name="evil" method="POST" action="https://mail.google.com/mail/u/0/?logout"> </form> </body> The massive button is left as an exercise to the reader ;-)
- postfuturist 15y agoGoogle 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)
- timmaxw 15y agoChrome 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.
- kaolinite 15y agoThis 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.
- homakov 15y agoread again, it's not about GET and google trick is just trick.
- brian_peiris 15y agoHere's Google's reply to this particular "vulnerability": http://www.google.com/about/company/rewardprogram.html#logout-forgery http://www.google.com/about/company/rewardprogram.html#logou...
- simonw 15y agoI don't understand why Google say that this is an issue that can't be solved - why can't they use a CSRF token on their logout feature, either by switching to using a POST form or by appending a CSRF token to the query string?
- deleted 15y ago[deleted]
- wglb 15y agoIf you think of the damage that can be done by a logout CSRF, it is not going to harm very much. Really a low-level issue.
- simonw 15y agoI get that - but the Google security FAQ suggests that fixing the issue is essentially impossible, whereas I'm pretty sure fixing it is the same as fixing any other CSRF hole.
- nbpoole 15y agoThe point that those blog posts make is that it's possible for a malicious attacker to log people out of a third-party site in multiple ways (specifically by messing with the user's cookies). Protecting one of those ways provides little to no benefit if the others are still unprotected. One reason I've also heard cited is that you always want the logout links in your application to work: you want users to be able to terminate their sessions quickly and easily. If you have a CSRF token tied to your user's session and that user happens to click on an old logout link (maybe they had an old tab open or something), the user won't be logged out of the application.
- Zirro 15y agoAm 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 lot of sites today. Few popular sites keep everything under the same domain (CDN´s, commentsystems, captchas and Facebook/Google/Twitter-resources, for example). http://www.memebase.com http://www.memebase.com is probably the worst "offender" I've come across. Hacker News isn't one of them, which I'm happy to see. Although if this was implemented I could see a lot of sites moving quickly to remedy this, reducing the alerts. It'd still be a pretty hard transition-period, though. Want to see how much would break today (and if the fix would work for the average user)? Try: https://www.requestpolicy.com https://www.requestpolicy.com
- nbpoole 15y ago"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.
- driverdan 15y agoAs my other comment highlighted, disabling 3rd party cookies will prevent most CSRF. As an added bonus it will also increase your privacy by preventing some (but not all) cross domain tracking.
- someone13 15y agoA 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-xsrf-part-one.aspx http://blogs.msdn.com/b/bryansul/archive/2008/08/15/rest-and... [2]: https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_respons...
- txt 15y agoAdding 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.
- eurleif 15y agoYou shouldn't be able to get the token from another domain, regardless of how long it lasts. How are you able to?
- yuliyp 15y agoDid you consider reporting it? Many such "huge" sites have bug bounty/white hat programs.
- txt 15y agoIm getting it on the same domain, but the request can be sent from any domain, as long as the user is logged in. And yeah, but they aren't offering anything that would be worth the time.
- iamwil 15y agoI'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-request-forgery-csrf http://guides.rubyonrails.org/security.html#cross-site-reque...
- vectorpush 15y agoit 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.
- divtxt 15y agoCSRF is like a kafka-esque joke. Here's my take away from every CSRF article: A malicious site will load your site in an iframe, fill in your form and post it. Fixing it requires some a token in your form, but I can see you don't understand how an extra hidden field in your form will make a difference so you're clearly not going to handle it correctly. You're screwed. Go home. As far as I can tell, CSRF should have existed since javascript & frames. How have the browser vendors not fixed such a huge insecure-by-design flaw?
- phleet 15y agoThe difficulty is how to deny this happening. Pages making GET requests across domains is so common and necessary that several technology standards would have to come together to propose a real fix. Every image or script loaded from a CDN. Anyone hosting their own static assets domains. Anyone using a plugin from Google, Facebook, Twitter, Disqus uses this ability. The tech companies can't even easily create a system to whitelist sites allowed to embed them, because that would severely limit third party's ability to use their services freely and would introduce a huge performance bottleneck. I haven't seen any particularly compelling solution to solving this. Things only guarded behind a GET request can be loaded by script, link, embed, object, img and iframe tags, and all of those have legitimate reasons for loading resources cross domain without requesting permissions for each one from the user.
- beneth 15y agoIs 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?
- lucb1e 15y agoI wonder what will happen to websites which use cross-domain post requests to log in securely, e.g. http://example.com http://example.com submitting the login form to https://secure.example.com https://secure.example.com
- lojack 15y agoIf they are using tokens then this should be viable as long as the state is shared across servers.
- deleted 15y ago[deleted]
- huhtenberg 15y ago[ 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 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_%28CSRF%29_Prevention_Cheat_Sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%...
- nbpoole 15y agoBecause a script (I assume you're referring to JavaScript) can't fill in a form on or read the contents of a third-party website. That's a violation of the same-origin policy. CSRF tokens are a well-understood solution to this issue. In order to submit a valid request, you must include what is essentially a secret token that is on the page (although the secret token can just be your session ID). For an attacker to get that token, they would need to be able to do at least one of the following: A. Guess it, by having you make multiple requests. (so you make the token long enough that it's infeasible to guess) B. Be able to read it by intercepting the HTTP response or reading it in some way, in which case you have much larger security issues. C. Be able to read the token in the HTTP request that the browser makes. Again, if an attacker can do this, your session is already compromised.
- huhtenberg 15y agoRight, the same-origin policy, thanks. Just found it after a minute of jsfiddling. Now, let's say my script is not loading bank's page into an iframe, but rather fetches it with an ajax call. Wouldn't that page (again) include a valid CSRF token? Or is this mitigated by checking a referrer on the bank's side?
- 15y ago
- driverdan 15y agoPreventing this in the browser is actually pretty trivial for most sites. Simply block 3rd party cookies. If the site uses cookies to track sessions the request won't have your session cookie and won't work. It's not up to browsers to prevent this. Just like how you can't rely on client side data validation you must always take proper precautions on the server. Browsers taking additional precautions to prevent this would be nice but it's not the whole solution and never will be. Edit: If you're going to downvote this please leave a reply stating why. I don't understand an opposing point of view unless you use 3rd party cookies to track people across domains.
- aprescott 15y agoIf Google required a POST to log out (as it should be, since logging someone out is changing the session state and therefore not a "safe" GET-able request[1]), we could fall back to CORS as protection which removes the need for a CSRF token. Since the only way (I believe) to get a POST to fire cross-domain, without explicit user interaction through, say, a regular HTML form, is through JavaScript, the browser would refuse to make the request unless the CORS headers explicitly allowed it. Still, using <form> buttons for logging out, consistently across the entire web, would take some effort. CSRF tokens are probably less intrusive. [1]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1...
- nbpoole 15y ago"Since the only way (I believe) to get a POST to fire cross-domain, without explicit user interaction through, say, a regular HTML form, is through JavaScript, the browser would refuse to make the request unless the CORS headers explicitly allowed it." I'm not quite sure what you're trying to say here. But you can make cross-domain POST requests in two ways, both involving JavaScript: 1. Create an HTML form, use JavaScript to submit it. 2. Use XMLHttpRequest to make a cross-domain POST.
- aprescott 15y agoYes: "the only way [...] to get a POST to fire cross-domain [...] is through JavaScript". The request would go against the same-origin policy, at which point CORS comes into play. Edit: Ah, but creating a form in the DOM and submitting it via JavaScript... that one I hadn't thought of.
- nbpoole 15y agoTo fire automatically, yes: getting people to click on a button of their own free will is easy though.
- driverdan 15y agoCORS isn't available in all browsers. You still need additional protection for browsers that don't support it. Plus it has nothing to do with using JS to submit a form.
- deleted 15y ago[deleted]
- javajosh 15y agoThis attack vector requires: 1) previous authentication to a service. 2) service which supports destructive actions as guessable URLs. 3) "third-party cookie" support in the user agent. [1] 4) a visit to a page with a malicious resource construct (an image, script, iframe, external style sheet, or object). Note that this resource could be generated by JavaScript, although this is not necessary. Sadly, the first three criteria are widely met. If we are to systematically remove this threat, then we have to look at removing each in turn: 1) Previous authentication to a service can be mitigated by simply logging out when you are done, but this is inconvenient and requires manual user intervention. However, there is an interesting possibility to limit "important" services to a separate process - a browser, an "incognito" window, etc. 2) Services should be built with an unguessable component that is provided just prior to calling by a known-good API, probably with additional referrer verification. 3) It is my belief that disabling third-party cookies is the right solution here: users rarely, if ever, get value from third-party cookies. Denying them would allow API authors to write simpler APIs that do not have a secret component, and would allow users to maintain the same behavior and login to all their services from the same browser. 4) While it seems that little can be done on this front apart from releasing some chemical agent into the atmosphere that made people trustworthy and good, actually it may be possible for browser makers to do some simple analysis of resource URLs to detect possible hanky-panky. [1] https://en.wikipedia.org/wiki/HTTP_cookie#Privacy_and_third-party_cookies https://en.wikipedia.org/wiki/HTTP_cookie#Privacy_and_third-...
- eurleif 15y agoThird party cookie support isn't necessary. You could just use a link instead of an image.
- javajosh 15y agoYes, that's the active form of the attack. To me, the passive form is far more pernicious (you are taking destructive action passively). At least with the active form you know that you've done something unintentional. But this does imply that the final onus is on the programmers of services to design services that do not have guessable, destructive one-step inputs.
- deleted 15y ago[deleted]
- tptacek 15y agoCSRF isn't a browser vulnerability. It's a serverside application vulnerability. To say otherwise is to say there there is some trivial policy, just an HTTP header away, that would allow IE, Firefox, and Webkit to coherently express cross-domain request policy for every conceivable application --- or to say that no FORM element on any website should be able to POST off-site (which, for the non-developers on HN, is an extremely common pattern). There is a list (I am not particularly fond of it) managed by OWASP of the Top Ten vulnerabilities in application security. CSRF has been on it since at least 2007. For at least five years, the appsec community has been trying to educate application developers about CSRF. Applications already have fine-grained controls for preventing CSRF. Homakov calls these controls "an ugly workaround". I can't argue about ugliness or elegance, but forgery tokens are fundamentally no less elegant than cryptographically secure cookies, which form the basis for virtually all application security on the entire Internet. The difference between browser-based CSRF protections (which don't exist) and token-based protections is the End to End Argument In System Design (also worth a Google). E2E suggests that when there are many options for implementing something, the best long-term solution is the one that pushes logic as far out to the edges as possible. Baking CSRF protection into the HTTP protocol is the opposite: it creates a "smart middleman" that will in the long term hamper security. This blog post seems to suppose that most readers aren't even familiar with CSRF. From the comments on this thread, he may be right! But he's naive if he thinks Google wasn't aware of the logout CSRF, since it's been discussed ad nauseam on the Internet since at least 2008 (as the top of the first search result for [Google logout CSRF] would tell you). Presumably, the reason this hasn't been addressed is that Google is willing to accept the extremely low impact of users having to re-enter their passwords to get to Google. Incidentally, I am, like Egor, a fan of Rails. But to suggest that Rails is the most advanced framework with respect to CSRF is to betray a lack of attention to every other popular framework in the field. ASP.NET has protected against CSRF for as long as there's been a MAC'd VIEWSTATE. Struts has a token. The Zend PHP framework provides a form authentication system; check out Stefan Esser's secure PHP development deck on their site. Django, of course, provides CSRF protection as a middleware module.
- javajosh 15y agoIt's clear that developers need a simple way to specify that a piece of API should not be accesible from third-party sites. I propose a new set of HTTP verbs, "SECPOST", "SECGET", etc that comes with the implication that it is never intended to be called by third-party sites or even navigated to from third-party sites. It is a resource that can only be called from the same origin. Application developers (and framework authors) could make sure to implement their destructive/sensitive APIs behind those verbs, and browser vendors could make sure to prevent any and all CSRF on that verb (including links and redirects).
- gcb 15y agoWeb is already too useless because people can't think about security in a decent way. Still baffles me that i can't allow a script at one domain to automate something in another domain for me.
- chubbard 15y agoBravo! If you thought you were immune because you only visit "reputable" sites it'll make you think twice. I tried putting it in a incognito tab in Chrome and Google apps in a normal tab. That didn't log out, but if I put both google apps and this site in incognito tabs or normal tabs then it logged me out. Pretty important to log out of sites when you aren't using them. But, more important to fix my sites!
- peteretep 15y agoI am hesitant to post this, because from experience, smart people frequently misread or misunderstand it, but: The easiest first-step solution is just to check the HTTP Referer field, and check it matches your domain. Yes, this is easily faked by someone crafting their own HTTP requests. This is /not/ easily faked by someone causing your browser to make requests, though. And it provides very good coverage against the attack here.
- nbpoole 15y agoStandard caveat with checking the Referer header: there is software out there which strips out the header in the name of privacy. If you use the Referer as a source of validation, you have to be prepared to deal with users of Norton Internet Security and other such products who will be unable to use your site. And you can't "fail open" by accepting any request without a referer, since there are plenty of techniques an attacker can use to remove the referer as well.
- nikcub 15y agoIf you do that, you then have to make sure your app doesn't have any redirector anywhere or anything that writes Location. Almost all apps do. This is because you can get the site to insert the right referrer. for eg. if the URL of the attack request is (both of these are close to real life examples that work(ed)) http://www.site.com/mail/filter?create=*%2Cattacker%40hush.com http://www.site.com/mail/filter?create=*%2Cattacker%40hush.c... usually the site will have a redirector on the login action, which takes the user back to the page that they were on after login, so you just use the attack URL as the redir URL http://www.site.com/login?return_to=%2Fmail%2Ffilter%3Fcreate=*%2Cattacker%40hush.com http://www.site.com/login?return_to=%2Fmail%2Ffilter%3Fcreat... amazing how many login scripts still do the redirect even if the user is already logged in, or still do the redirect even if there is no real login even if you do a javascript in-place login, there is usually a mobile version that has this pattern. I rarely meet a site that doesn't have a way to bounce between URLs and fake the referrer. I guess the real conclusion is that these types of attacks are complicated and better understood fully than implying a single short solution - because the next response is always "but, if you do that, then" and so forth, like a matryoshka doll
- jim_lawless 15y agoI had envisioned what I think is a more solid defense against CSRF ... I just haven't had time to build a proof. Earlier commenters have noted that each request back to the server should include an unguessable token that cannot be derived by mining other pages on the site with cross-site AJAX requests. My hypothetical solution is to embed that token in the prefix to the hostname after logging into the given site. The token would then be sent in the Host: header for all dynamic requests. Step 1: You log in to www.somesite.kom. Step 2: You are then forwarded to dynXXXXXXXX.somesite.kom where XXXXXXXX represents a unique, dynamically-generated token tied to your session. The attacker must now know XXXXXXXX to properly form up a GET or POST request to attack your account. The site itself could then use relative URL's for dynamic content or could use the appropriate templating system to ensure that any dynamic URL's ( either in HTML markup or script text ) contain the generated hostname.
- swah 15y agoAre REST APIs susceptible in the same way? Or as long as we don't store our auth token on the client cookie we're ok?
- slurgfest 15y agoThere is a HUGE vested commercial interest in the CONTINUATION of the insecure status quo, in which all the control is on the server side (hence, with the companies doing tracking and advertising using third party requests, rather than with the end user). Furthermore, the players funding browser development all share strongly in that vested interest. (Even for Firefox, follow the money - and if Firefox did try to lock down without industry agreement, it would lose, which Mozilla knows). So you will not see any change. This also explains the degree of heat directed at the suggestion that client behavior could be less insecure by default, with regard to third party requests. This is not new. Much of HTTP as originally conceived actually dictated a great deal more user control over what happened. Those standards had to be compromised from the word go in order to reach the present state.