Re: CsrfPreventionFilter for REST

[Violeta Georgieva <mi...@gmail.com>]

Hi,

2015-09-17 10:55 GMT+03:00 Christoph Nenning <Christoph.Nenning@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-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
>
>
> This Email was scanned by Sophos Anti Virus