3 ms·

Sure, the key will stop CSRF attacks that rely on just an iframe, but if my attack is more sophisticated then I can scrape the token from a legit form and re-po

Sure, the key will stop CSRF attacks that rely on just an iframe, but if my attack is more sophisticated then I can scrape the token from a legit form and re-post with whatever data I want.

crux_ 16y ago
> scrape the token from a legit form Assuming the tokens are strongly tied to a user ID, how do you propose getting yourself a readable copy of this form? (There are a lot of ways of tying the token to a user ID... associations in a backend database/memcache; token = encrypt(userid, garbage); token = garbage + cryptohash(user_id + server-side-secret + that_same_garbage) ... ) (edit: tweak to 'cryptohash' method.)
- deleted 16y ago
  [deleted]
  - crux_ 16y ago
    EDIT: The parent deleted their reply; since I took the time to get all teacher-mode here I figured I'd include it, cut and pasted, but without their username. > If you know the URL of the form, isn't it as simple as using Javascript to pull up the page, parse the token variable out of the page, and then using that? > > Right now, the Javascript just has to: 1) post to http://www.form.com.... > > Now, the Javascript has to: 1) fetch http://www.form.com... 2) parse the response, find <input name="authToken" value="ohSoSecureAuthToken" 3) post to http://www.form.com... with the authToken > > Sure, its more steps, but isn't it just as insecure? You're missing a concept here, and it's one of these two things (most likely the 2nd): 1) The form (& token) is generated server-side based on the currently logged in user, as determined by a cookie (or http authentication, or https client certs, etc.): So each user gets a different form+token, and is only generated with a valid current session. In other words, you can't get this form unless you are successfully impersonating the victim or forcing the victim's logged-in web browser to make the request. 2) In the case that you do force the victim's browser to make the request, the browser security model has a whole bunch of restrictions on what javascript can read which data, collectively known as the same origin policy (http://en.wikipedia.org/wiki/Same_origin_policy http://en.wikipedia.org/wiki/Same_origin_policy). In particular, the same origin policy will make your step two, "parse the response", fail: javascript running on a page from a.com has no access to responses from b.com. Without the same origin policy, we'd all be hosed. Imagine code on a hostile web page that scrapes your contact book if you're logged into email on another tab, your bank account, etc... all of these follow the same basic pattern as steps 1-2 in your reply. Assuming no other security flaws and verifiable and non-forgeable form tokens, then the same origin policy will effectively protect third party websites from submitting requests on behalf of a victim. Note that those are both very big assumptions, e.g. it turns out that you can forge 'secure' tokens from ASP.NET because they screwed up their crypto. (I think the tokens in question are typically used for session cookies, but same general idea.)

Sure, the key will stop CSRF attacks that rely on just an iframe, but if my attack is more sophisticated then I can scrape the token from a legit form and re-post with whatever data I want.

crux_ 16y ago

> scrape the token from a legit form Assuming the tokens are strongly tied to a user ID, how do you propose getting yourself a readable copy of this form? (There are a lot of ways of tying the token to a user ID... associations in a backend database/memcache; token = encrypt(userid, garbage); token = garbage + cryptohash(user_id + server-side-secret + that_same_garbage) ... ) (edit: tweak to 'cryptohash' method.)

deleted 16y ago
[deleted]
- crux_ 16y ago
  EDIT: The parent deleted their reply; since I took the time to get all teacher-mode here I figured I'd include it, cut and pasted, but without their username. > If you know the URL of the form, isn't it as simple as using Javascript to pull up the page, parse the token variable out of the page, and then using that? > > Right now, the Javascript just has to: 1) post to http://www.form.com.... > > Now, the Javascript has to: 1) fetch http://www.form.com... 2) parse the response, find <input name="authToken" value="ohSoSecureAuthToken" 3) post to http://www.form.com... with the authToken > > Sure, its more steps, but isn't it just as insecure? You're missing a concept here, and it's one of these two things (most likely the 2nd): 1) The form (& token) is generated server-side based on the currently logged in user, as determined by a cookie (or http authentication, or https client certs, etc.): So each user gets a different form+token, and is only generated with a valid current session. In other words, you can't get this form unless you are successfully impersonating the victim or forcing the victim's logged-in web browser to make the request. 2) In the case that you do force the victim's browser to make the request, the browser security model has a whole bunch of restrictions on what javascript can read which data, collectively known as the same origin policy (http://en.wikipedia.org/wiki/Same_origin_policy http://en.wikipedia.org/wiki/Same_origin_policy). In particular, the same origin policy will make your step two, "parse the response", fail: javascript running on a page from a.com has no access to responses from b.com. Without the same origin policy, we'd all be hosed. Imagine code on a hostile web page that scrapes your contact book if you're logged into email on another tab, your bank account, etc... all of these follow the same basic pattern as steps 1-2 in your reply. Assuming no other security flaws and verifiable and non-forgeable form tokens, then the same origin policy will effectively protect third party websites from submitting requests on behalf of a victim. Note that those are both very big assumptions, e.g. it turns out that you can forge 'secure' tokens from ASP.NET because they screwed up their crypto. (I think the tokens in question are typically used for session cookies, but same general idea.)