tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: CsrfPreventionFilter for REST
Date Wed, 26 Sep 2012 09:21:25 GMT
2012/9/22 Violeta Georgieva <>:
> Hello,****
> ** **
> *Background information:*
> We are trying to protect our RESTful
> APIs<>
> 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<>
> 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
> , 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:
For additional commands, e-mail:

View raw message