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
>>
>>

Reply via email to