Well, before this starts to look as a flamewar, I will just say this: I did not miss the details of the vulnerability, it was just not part of our discussion about the default behavior. The changes to CSRF protection came in 3 parts.
1-The whitelisting part is clear and I understand I now need to use a token for xhr request because they now are forgeable. As is stated, every non-get request needs a token, which tightens security. I'm certainly not opposing to this change. 2-The second change is that the handling is now fully configurable and people can handle unverified requests in any way that is appropriate for their application. This is a great change as well, indeed for APIs and such. 3-The third change was the change of the default behavior. As far as I can see, changing the default opened up some cases (mainly the empty starter rails app with no authentication) that were protected before. And as far as I can see, it didn't start protecting cases that were unprotected before. I would just have liked if the default stayed to raise (the safest, most catchall), and have people change this to session-reset the moment they implement authentication/login, or implement an API. In other words, secure-by-default, but configurable enough to bind it to any application-internal security/session/authentication logic later on. But as long as everybody is made fully aware of the implications, I don't mind what the default is. So indeed documentation will take away my concerns. Thanks for the feedback. Mathijs On Feb 12, 10:02 am, Michael Koziarski <mich...@koziarski.com> wrote: > > But no matter what we think CSRF protection is about, the old behavior > > was about validating every potentially harmful request, the new one a > > specific type of attack, which was already covered by the old one. > > So we can conclude that the security got loosened somewhat (for > > reasons you mention below). > > The security didn't get loosened, it got changed in a manner that > preserves security for the bulk of use cases while preserving the > restful API support that so many people rely on. > > > As mentioned, I think starting a new sessions from a "clean" IP > > address counts as client-browser specific. > > IP addresses are cheap and plentiful and don't provide the security > you seem to think they do. For example the entire nation of qatar > makes internet requests from the same IP address. Would your > theoretical site only accept a single vote from qatar. > > However that's beside the point, your application could either > override the default handler or require users view the poll question > before voting (making use of the session). Both are perfectly > acceptable answers, what's not acceptable would be rejecting each and > every API request to every rails app on the internet. > > > I don't really see why. The old system was easy to bypass for specific > > controllers and actions, while the default was safe for all abuse- > > cases. The new system is aimed towards applications with an api that > > don't want to use skip_before_filter and that do use a session for > > their security-measures. > > What assumption does not hold anymore? Which rule changed? > > I think you missed the details of the security vulnerability, our > previous method of whitelisting API requests has been broken. > Previously your API requests *didn't trigger CSRF protection*, now > they do. *that* is why the error handling had to change. Previously > we could raise 500 errors because the checking never fired for API > requests. Your entire model of using seperate api controllers for > CSRF protection was completely unnecessary under the old system. > > Please take the time to read the advisory carefully as I think you're > misunderstanding why we undertook this change. Attackers can forge > arbitrary HTTP headers, previously this was not believed to be > possible. Because of this incorrect assumption (made by basically the > entire web security community, not just us) we were able to whitelist > certain requests. We can no longer whitelist anything, everything can > be forged. > > It was not undertaken lightly and it was not done without a lot of > careful consideration. We consulted with security experts, analysed > various alternatives and chose the least-worse option out of a series > of bad options. > > The setting as it is now will not be changed, we may enhance the api > in the future and we will improve the documentation to make sure > people can make informed choices. But the default won't change. > > -- > Cheers > > Koz -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
