Empathy List Archives

websecurity@lists.webappsec.org

The Web Security Mailing List

Re: [WEB SECURITY] CS#RF (insecure client side rouring)

Erlend Oftedal

Sat, Jun 30, 2012 12:29 AM

Thank you for replying.
I was thinking of server generated tokens stored in the users session. An app like this would probably get the token in a json together with other login information such as username after login.
An evil server cannot directly get the token because that would require stealing the session (as long as we're on https).
But in this attack it doesn't have to. It just asks a page on the victim page to build the request and send it on behalf of the user.
Yea this is still a CSRF, hence the title. But at least to me it was a new subcategory of CSRF.

Erlend

Hi Thank you for replying. I was thinking of server generated tokens stored in the users session. An app like this would probably get the token in a json together with other login information such as username after login. An evil server cannot directly get the token because that would require stealing the session (as long as we're on https). But in this attack it doesn't have to. It just asks a page on the victim page to build the request and send it on behalf of the user. Yea this is still a CSRF, hence the title. But at least to me it was a new subcategory of CSRF. Erlend

Stefano Di Paola

Mon, Jul 2, 2012 6:00 PM

Hey Erlend,

Absolutely, I'd just like to point out that the Http Parameter Pollution
in its client side nuance is a technique that was used to bypass the
anticsrf against yahoo mail web site (already fixed of course).

http://blog.mindedsecurity.com/2009/05/client-side-http-parameter-pollution.html

I think we are in a very similar scenario here (at least for what I've
understood :).

Cheers,
Stefano

Il giorno sab, 30/06/2012 alle 02.29 +0200, Erlend Oftedal ha scritto:

Thank you for replying.
I was thinking of server generated tokens stored in the users session.
An app like this would probably get the token in a json together with
other login information such as username after login.
An evil server cannot directly get the token because that would
require stealing the session (as long as we're on https).
But in this attack it doesn't have to. It just asks a page on the
victim page to build the request and send it on behalf of the user.
Yea this is still a CSRF, hence the title. But at least to me it was a
new subcategory of CSRF.

Erlend

From: Daniel Herrera
Sent: 30.06.2012 00:08
To: websecurity@lists.webappsec.org; Erlend Oftedal
Subject: Re: [WEB SECURITY] CS#RF (insecure client side rouring)

Erlend,

I can see the unique elements of your example, and yes I have seen
this in the wild. However, I would still consider your example CSRF
and not a secondary class of attack.

There are several implementations in the wild that auto-populate a
required token within a secondary request, that are not related to
JavaScript frameworks. Depending on the implementation, these can also
be susceptible to the same abuse case you described.

In addition, there are several follow-up questions I would ask about
the example you provided:

Is the CSRF token derived client-side or sever-side?

If the token is derived client-side:
How does the application manage access to the logic that generates
valid tokens?
Whats to prevent the attacker from forging valid tokens using the same
methods?

If the token is derived server-side:
How does the application protect requests for valid tokens?
What prevents an attacker from forging these requests and
sub-stringing the token returned within the response?

Let me know your thoughts and if you feel I missed anything in your
previous message/blog post.

Cheers,

Daniel

--- On Fri, 6/29/12, Erlend Oftedal erlend@oftedal.no wrote:

     From: Erlend Oftedal <erlend@oftedal.no>
     Subject: [WEB SECURITY] CS#RF (insecure client side rouring)
     To: websecurity@lists.webappsec.org
     Date: Friday, June 29, 2012, 10:11 AM
     
     Hi
     
     I was wondering if CS#RF was something being found in the wild
     and tested for?
     Basically this is a CSRF attack against a JS driven app that
     has server side CSRF protection, but is using insecure routing
     on the client side, causing the JS to submit the correct CSRF
     token.
     Consider a blog having the following url:
     http://example.com/blog#/comment/123/delete
     The client side JS picks up on the hash, and builds a secured
     request including CSRF token and off to the server we go.
     So tricking a user to visit a minified url, using an iframe or
     other means of getting an authenticated user to visit the
     link, causes the comment to be deleted.
     Typically single page web apps using a routing framework like
     backbone.js may be vulnerable.
     
     Blog post: http://erlend.oftedal.no/blog/?blogid=130
     
     Best regards
     Erlend
     
     
     -----Inline Attachment Follows-----
     
     _______________________________________________
     The Web Security Mailing List
     
     WebSecurity RSS Feed
     http://www.webappsec.org/rss/websecurity.rss
     
     Join WASC on LinkedIn
     http://www.linkedin.com/e/gis/83336/4B20E4374DBA
     
     WASC on Twitter
     http://twitter.com/wascupdates
     
     websecurity@lists.webappsec.org
     http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

The Web Security Mailing List

WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss

Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA

WASC on Twitter
http://twitter.com/wascupdates

websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org

Hey Erlend, Absolutely, I'd just like to point out that the Http Parameter Pollution in its client side nuance is a technique that was used to bypass the anticsrf against yahoo mail web site (already fixed of course). http://blog.mindedsecurity.com/2009/05/client-side-http-parameter-pollution.html I think we are in a very similar scenario here (at least for what I've understood :). Cheers, Stefano Il giorno sab, 30/06/2012 alle 02.29 +0200, Erlend Oftedal ha scritto: > Hi > > Thank you for replying. > I was thinking of server generated tokens stored in the users session. > An app like this would probably get the token in a json together with > other login information such as username after login. > An evil server cannot directly get the token because that would > require stealing the session (as long as we're on https). > But in this attack it doesn't have to. It just asks a page on the > victim page to build the request and send it on behalf of the user. > Yea this is still a CSRF, hence the title. But at least to me it was a > new subcategory of CSRF. > > > Erlend > > > ______________________________________________________________________ > From: Daniel Herrera > Sent: 30.06.2012 00:08 > To: websecurity@lists.webappsec.org; Erlend Oftedal > Subject: Re: [WEB SECURITY] CS#RF (insecure client side rouring) > > Erlend, > > I can see the unique elements of your example, and yes I have seen > this in the wild. However, I would still consider your example CSRF > and not a secondary class of attack. > > There are several implementations in the wild that auto-populate a > required token within a secondary request, that are not related to > JavaScript frameworks. Depending on the implementation, these can also > be susceptible to the same abuse case you described. > > In addition, there are several follow-up questions I would ask about > the example you provided: > > Is the CSRF token derived client-side or sever-side? > > If the token is derived client-side: > How does the application manage access to the logic that generates > valid tokens? > Whats to prevent the attacker from forging valid tokens using the same > methods? > > If the token is derived server-side: > How does the application protect requests for valid tokens? > What prevents an attacker from forging these requests and > sub-stringing the token returned within the response? > > Let me know your thoughts and if you feel I missed anything in your > previous message/blog post. > > Cheers, > > > Daniel > > --- On Fri, 6/29/12, Erlend Oftedal <erlend@oftedal.no> wrote: > > From: Erlend Oftedal <erlend@oftedal.no> > Subject: [WEB SECURITY] CS#RF (insecure client side rouring) > To: websecurity@lists.webappsec.org > Date: Friday, June 29, 2012, 10:11 AM > > Hi > > I was wondering if CS#RF was something being found in the wild > and tested for? > Basically this is a CSRF attack against a JS driven app that > has server side CSRF protection, but is using insecure routing > on the client side, causing the JS to submit the correct CSRF > token. > Consider a blog having the following url: > http://example.com/blog#/comment/123/delete > The client side JS picks up on the hash, and builds a secured > request including CSRF token and off to the server we go. > So tricking a user to visit a minified url, using an iframe or > other means of getting an authenticated user to visit the > link, causes the comment to be deleted. > Typically single page web apps using a routing framework like > backbone.js may be vulnerable. > > Blog post: http://erlend.oftedal.no/blog/?blogid=130 > > Best regards > Erlend > > > -----Inline Attachment Follows----- > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn > http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org