Hi, 2015-09-17 10:55 GMT+03:00 Christoph Nenning <christoph.nenn...@lex-com.net >: > > Violeta, > > > > > > > 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. > > > > > Yes, it would be very interesting if tomcat would provide such a filter!
You can take a look at the sources in trunk. Regards, Violeta > > Regards, > Christoph > > > > > > > > > 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 > > > > > > This Email was scanned by Sophos Anti Virus