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

[Stefano Di Paola]

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 at 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 at oftedal.no> wrote:
>         
>         From: Erlend Oftedal <erlend at oftedal.no>
>         Subject: [WEB SECURITY] CS#RF (insecure client side rouring)
>         To: websecurity at 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 at 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 at lists.webappsec.org
> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org