Hi, 2012-09-26 12:21 GMT+03:00 Konstantin Kolinko <knst.koli...@gmail.com>: > > 2012/9/22 Violeta Georgieva <violet...@apache.org>: > > Hello,**** > > > > ** ** > > > > *Background information:* > > > > We are trying to protect our RESTful > > APIs<http://en.wikipedia.org/wiki/Representational_state_transfer> > > from > > CSRF attack.**** > > > > The current Tomcat’s CSRF protection filter provides proper protection for > > web resources that are supposed to be accessed via some sort of navigation > > i.e. there’s an entry point which points to them (for example include > > links/post forms to them) . With REST APIs you do not have such entry > > points as the requests are done independently from each other. We are > > interested do you consider supporting CSRF protection for RESTful APIs?**** > > > > ** ** > > > > *Example attack:* > > > > Here is an example how to reproduce CSRF attack of RESTful APIs using the > > attached apps:**** > > > > > > 1. Check customers initial state: > > http://localhost:8080/restDemo/services/customers/ + login with > > tomcat/tomcat > > 2. **In the same browser open attacker’s app: > > http://localhost:8080/XSRFAttackerApp/ > > > > ** > > > > Behind the scenes request 2. takes advantage of your credentials stored in > > the browser and makes attacking POST request to a state changing operation > > http://localhost:8080/restDemo/services/customers/removeFirst on your > > behalf. After that the customer list is empty.**** > > > > ** ** > > > > The problem is that if we use the CSRF filter to protect this API > > /services/customers/removeFirst, this URL is then always served with *403 > > Forbidden* (due to the missing csrf token). In fact the REST API becomes > > unusable.**** > > > > ** ** > > > > *Research:* > > > > We’ve made some research on the topic and it seems that there is no > > absolutely secure and at the same time clear stateless solution. Since it > > is possible for an attacker to insert custom headers in the attacking > > requests, the validation over header presence is not secure enough.**** > > > > The ability to insert headers (or tokens in the request string as > Tomcat's CSRF filter requires) is irrelevant, because the attacker > has to know the exact token value and the value is random. > > If you are constantly receiving 403 on your POST requests it means > that you are requesting wrong URL (one that does not contain the CSRF > token) or your requests are not a part of the session. > > > > The only stable solution is again based on Synchronizer Token > > Pattern< https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet > > > but > > instead of encoded in URLs, the csrf token value can be transferred from > > and to the client through a custom csrf token header. The rest csrf token > > value needs to be stored in some sort of state on client and server side. > > In addition REST clients need to adopt this csrf token transfer mechanism.** > > ** > > > > *Proposal:* > > > > You can find on the link > > https://docs.google.com/open?id=0B-HUwAvkRIKJTVViWUFkNFl6alU , the > > CsrfPreventionFilter extended so that it is able to successfully protect > > state changing REST requests. They are validated based on the > > “X-CSRF-Token” header (the header name is configurable). > > > > (...) > > > > The main task of Tomcat's CSRFProtectionFilter is to protect the > Manager application. The application does not use XMLHttpRequest so it > cannot set the headers. > So I see no point in implementing support for passing the token value > in a header, as there is no use for it. Is there enough API available > to extend the filter in a subclass to cover your specific use case?
I would like to know whether there is an interest for such filter as part of the filters that Tomcat provides by default to its users. Thanks and Regards, Violeta > Note that CSRF protection has some specific task. It would not protect > you if an attacker is able to request the "welcome" page and parse it > to extract the token. It would not protect you if you are using > non-secured HTTP and an attacker is able to sniff network traffic. > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
