tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Nenning <Christoph.Nenn...@lex-com.net>
Subject Re: CsrfPreventionFilter for REST
Date Thu, 17 Sep 2015 07:55:21 GMT
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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >


This Email was scanned by Sophos Anti Virus
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message