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