Hi Kinn, On Wed, May 11, 2016 at 8:36 PM, Kinn Julião <kin...@gmail.com> 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). > > Any other remote source would still be able to use your "example". > > "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". > "B is spamming your site's contact form, with a csrf token remotely > requested, and the same stored in its session". > > Which means: B still being able to CSRF. Which is tottaly different from > Session Hijacking.
You've said > The cross site can request the "get_csrf_token.php", store on its session > (even curl can save the session id cookie or whatever), get the token and > request the endpoint with the retrieved token and session id. I probably understand the reason why you misunderstood now. This CSRF protection is works like Trans SID as RFC introduction states. It is as secure as Trans SID. If you are curious, study Trans SID and why it is adequately safe. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
