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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
