> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
