Empathy List Archives

websecurity@lists.webappsec.org

The Web Security Mailing List

CS#RF (insecure client side rouring)

Erlend Oftedal

Fri, Jun 29, 2012 5:11 PM

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

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

Daniel Herrera

Fri, Jun 29, 2012 10:08 PM

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

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

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