And again, I'm bashing against/based in his poor example for asynchronous requests... On May 11, 2016 8:22 AM, "Kinn Julião" <kin...@gmail.com> 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. > > About the pixel, what can prevent a mail pixel to point to " > 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. > On May 11, 2016 8:16 AM, "Rowan Collins" <rowan.coll...@gmail.com> wrote: > >> On 11/05/2016 12:36, Kinn Julião wrote: >> >>> You're making confusion between CSRF and Session Hijacking... In any >>> moment >>> I mentioned about hijacking someone else's session, but to still being >>> able >>> to CSRF (Cross Site Request Forgery). >>> >> >> CSRF generally implies tricking an authenticated user into making a >> request using their own session. Without any form of token check, an >> identical request will be sent from any user, so you don't need to know >> anything about the user or their session to perform the attack - it can in >> fact be entirely passive, e.g. the src of an <img> embedded in another page. >> >> With a CSRF token bound to each session, you can't perform a passive >> attack, because you need to first discover some information from their >> session, and target the attack. >> >> Without tricking the user into submitting the request with their own >> authentication, there is no forgery, and no attack. >> >> >> Any other remote source would still be able to use your "example". >>> >> >> A remote source would only be able to read their own CSRF token, not that >> of another user. If they are not authorised to submit the content, it is >> not the CSRF token's job to enforce that. >> >> >> "A is using your own site's contact form, with a plotted csrf token as a >>> hidden field in the form, and the same stored in the session". >>> With your token solution for asynchronous requests: >>> "A is using your own site's contact form, with a csrf token remotely >>> requested, and the same stored in its session". >>> >> >> All CSRF tokens are "remotely requested", in that they are sent from the >> server to the client's browser during a legitimate request. There is no >> difference in exposure between an HTML hidden input in the response to "GET >> /display_comment_form.php" and a JSON value in the response to "GET >> /generate_form_token.php". >> >> >> "B is spamming your site's contact form, with a csrf token remotely >>> requested, and the same stored in its session". >>> >> >> 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. >> >> Regards, >> -- >> Rowan Collins >> [IMSoP] >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >>
