You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Violeta Georgieva <vi...@apache.org> on 2015/09/16 13:20:03 UTC
Re: CsrfPreventionFilter for REST
Hi,
2012-09-26 12:21 GMT+03:00 Konstantin Kolinko <kn...@gmail.com>:
>
> 2012/9/22 Violeta Georgieva <vi...@apache.org>:
> > 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.
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
>
Re: CsrfPreventionFilter for REST
Posted by 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
Re: CsrfPreventionFilter for REST
Posted by Christoph Nenning <Ch...@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!
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