The point with your example is: 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.
Got it? On May 10, 2016 10:53 PM, "Kinn Julião" <kin...@gmail.com> wrote: > You seemed to misunderstood your own "get_csrf_token.php" and how > attackers would benefit from that. > > Anyway, you're trying to transfer an application behaviour to the core... > Stick to -1. > On May 10, 2016 10:18 PM, "Yasuo Ohgaki" <yohg...@ohgaki.net> wrote: > >> Hi Kinn, >> >> On Wed, May 11, 2016 at 10:20 AM, Kinn Julião <kin...@gmail.com> wrote: >> >> JS code that does not have pages at all may obtain CSRF token manually. >> > >> > That's against CSRF protection... in fact, a remote app can obtain the >> token >> > also and make the cross site request forgery... >> > >> > -1 >> >> You seem to __misunderstood__ behavior. >> >> Random CSRF token generation key is stored in session data which is >> private to users. >> CSRF token is generated by using the secret key. >> >> Therefore, attacker cannot get CSRF token unless they have stolen >> session already (which is not scope of this RFC) >> >> Regards, >> >> -- >> Yasuo Ohgaki >> yohg...@ohgaki.net >> >
