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? 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
