So following your example then. You could place an HTML page on a completelu different site... maybe this page: https://gist.github.com/kinncj/6ad5f5ef8d8c36eb5f844fb802a67b7a#file-attacker_example_net :-)
As I mentioned in comments there: /* >From this point, this attack will only work if: 1 - CORS is missconfigured */ The understanding is: the user must be responsible to configure it properly, to secure it properly. If the user must be responsible to secure it properly, why should be this magic added to the core? On Wed, May 11, 2016 at 8:48 AM, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 11/05/2016 13:22, Kinn Julião wrote: > >> CSRF is not related to spam or rate limiting, it is related to >>> >> impersonation. A spam bot can simply repeatedly request new HTML forms >> and scrape out the hidden input. >> >> The Spam bot was just an example, contering his own example. >> >> And it still a cross site request... Either if it comes from a bot or not. >> > > No, it's just "a request". I ask for a URL, I get some content. There is > no "cross-site" involved, and no "forgery". > > > About the pixel, what can prevent a mail pixel to point to >> "attacker.com/img.jpg <http://attacker.com/img.jpg>" which fetches the >> "whatever_his_enpoint_to_return_the_token.php", grab the token and >> forward to the form? The same as what prevets it from scraping the html? >> Nothing... So in the end, this RFC improves nothing as mentioned above. >> > > What you are saying there is "all CSRF tokens are pointless". The large > number of articles recommending them and libraries implementing them should > be a pretty big clue that they are not. > > I think you are misunderstanding how the attack works; here is a simple > example. If you are logged into a site called victim.example.com, I can > place an HTML page on a completely different site (say, > attacker.example.net) with the following code: > > <img src=" > http://victim.example.com/change_password.php?new_password=h4xx0r";> > > Your browser will then send a request to the specified URL, and execute > the command. At no point does the server at attacker.example.net receive > any data from victim.example.com, but it can trick you into sending > commands to it, with your authenticated privileges. > > With a CSRF token in place, the passive attack above will be rejected - > "missing or invalid CSRF token". In the response, a fresh CSRF token may > well be forwarded to your browser, but it is never forwarded to the > attacker. > > Let's say we have an endpoint that simply checks the request cookies and > generates a new CSRF token, as in Yasuo's example, the attacker could of > course write this: > > <img src="http://victim.example.com/generate_csrf_token.php";> > > But this is no use - it tricks you into sending a command that generates a > new token, but the attacker can't see what token was generated, so can't > impersonate you. > > > If you can read the value of that response, that is an XSS vulnerability. > As the OWASP page linked to earlier says "any cross-site scripting > vulnerability can be used to defeat token, Double-Submit cookie, referer > and origin based CSRF defenses": > https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#No_Cross-Site_Scripting_.28XSS.29_Vulnerabilities > > > Regards, > -- > Rowan Collins > [IMSoP] > -- *--* *Kinn Coelho Julião* *Toronto - ON/Canada*
