Hi, Chris, On 02/20/2014 11:24 PM, Chris Travers wrote: > Right now, the current 1.4 web services don't provide a great deal of > strong protection against xsrf. The current approach is not really > safe enough, and so right now, unless we find a way to fix this, we'd > need to recommend opening up that section of urls only to trusted > hosts (i.e. servers). While this seems like a big limitation, if you > restrict by client-side certificate you could allow access from > dedicated non-browser mobile clients but not web browsers. > > There is another option though, in that we could allow for some sort > of digital signing of a component of a request. Unfortunately, this is > going to require going with perl modules (which don't have a perfect > cpantester record) or pgcrypto as an extension. However, you could > have a public key, and you could check the signature of a specific set > of information. > > A third option would be a pre-shared auth key that would be submitted > with every request, and tied to the user. The positive side is that > it would be simple. The negative side is that the tokens would be > long-term valuable and if compromised would provide a means to exploit > xsrf via the browser if the user accounts are shared. > > For now (1.4) I think recommending client-side certs would provide the > most protection, but while this provides good protection for dedicated > clients it means effectively locking browsers out of the restful web > services. > > Our current csrf protections for the web app, while better on the > browser than any others that could be implemented there with RESTful > principles, is certainly not RESTful, as it requires effectively > pre-authorizing every write request (i.e. get the authorization token > then add it to the post request). This requires a double-round trip > to make a write effective. > > Anyway, feedback is requested. >
This is an area I was overdue for investigating ;-) I found a bunch of useful links on preventing CSRF on REST APIs, and based on that, I think we should handle this a couple different ways. First of all, if we're going to move more application management to the browser (for example, build an invoice with Javascript and post the result as JSON into the back end when done, which is a pattern Erik and I were discussing yesterday) we want to support having browsers use the RESTful web services. And of course, what use is an API if you can't use it from another service? So yes, we want something relatively simple to implement for both cases. A client-side certificate seems like a lot of extra work when writing a client, and not a common pattern. So we need to cover two cases when authenticating a request: a request from a user logged into the web site, and a request from anywhere else. We already use a session identifier for the web site, so we can detect if a user has recently logged in. To cover this case, I am thinking the "double-submit" pattern described here would be sufficient: http://appsandsecurity.blogspot.com/2012/01/stateless-csrf-protection.html (and make sure we don't require that for GET requests). That is, the client sends the same value in a Cookie as well as in the data of a POST, PUT, or DELETE request. That does not even need to be generated server side to prevent CSRF -- the server should just verify that for authenticated sessions, these values match. For API calls that do not involve a session, we already require authentication. I think it's reasonable, if we require a session for authentication, for a web service client to either do a double-submit or a "synchronizer token" (which I think describes our current anti-CSRF protection) -- the client can route all requests through a central broker to apply the next token to the data before submitting. Here's what I found useful: http://appsandsecurity.blogspot.com/2012/01/stateless-csrf-protection.html https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet https://www.owasp.org/index.php/REST_Security_Cheat_Sheet http://security.stackexchange.com/questions/20187/oauth2-cross-site-request-forgery-and-state-parameter The key thing for CSRF attacks is the attacker does not have access to the credentials themselves, or any cookie values. If we can detect all requests coming from our app and double-check against state that cannot be accessed from a different site, we block a CSRF attack. For any other API consumer, the app already needs to supply authentication. Cheers, John Locke http://www.freelock.com Cheers, John Locke ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
