You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CSRF Verification + Authentication on Scratch #342
hey, I have some questions about scratch's CSRF token system and authentication system in general. I have a basic understanding of what these tokens are for, but I don't specifically understand what scratch did here. In some api requests, there seems to be 2 csrf tokens, once in the cookies and once as a x-csrftoken header. that kinda makes sense since the server can check if both are equal and let the request pass through or not based on that. but I also remember seeing requests made to /csrf in the past, I just can't see them anymore. did they make changes to the api? I'm sorry for all the questions, but right now im not really sure about what x-token, sessionid and the csrf tokens are in scratch. thanks for your patience,
~alas
hey, I have some questions about scratch's CSRF token system and
authentication system in general. I have a basic understanding of what
these tokens are for, but I don't specifically understand what scratch did
here. In some api requests, there seems to be 2 csrf tokens, once in the
cookies and once as a x-csrftoken header. that kinda makes sense since the
server can check if both are equal and let the request pass through or not
based on that. but I also remember seeing requests made to /csrf in the
past, I just can't see them anymore. did they make changes to the api? I'm
sorry for all the questions, but right now im not really sure about what
x-token, sessionid and the csrf tokens are in scratch. thanks for your
patience,
~alas
—
Reply to this email directly, view it on GitHub
<#342>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATCKMZVFI5AI7OL4F7D6K232OOHUPAVCNFSM6AAAAABWUASOOKVHI2DSMVQWIX3LMV43ASLTON2WKOZSHAZTMMBYG44TAMA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
It has something to do with making sure that requests are coming from scratch.mit.edu, and it lies not in the content of the cookie, but the fields. This (and some other CSRF things across Scratch) ensures that you can't, for example, post on the forums by submitting a form on another website.
It has something to do with making sure that requests are coming from scratch.mit.edu, and it lies not in the content of the cookie, but the fields. This (and some other CSRF things across Scratch) ensures that you can't, for example, post on the forums by submitting a form on another website.
Interesting. Could you please provide more details for how it lies in the fields? From what I've seen, this is what i figured out but I'm not sure:
In some requests there are 2 fields for csrf tokens, one is the cookie and the other is x-csrftoken. if a malicious website submits a request to it and the browser automatically sends the cookies, the x-csrftoken field is not part of it and the attacker would still need to input a static value for it, cuz they still can't read the cookies. the only thing the server does here is to check if both are equal.
Yeah, we knew that but why doesn't the website just generate the cookie using js was the question
yes, thats weird. there must be some server side validation of the value itself too...
i saw the /csrf_token endpoint is still there on the old scratch 2.0 login page, it's made before the /login request. no authentication data except for the existing saved csrf token is sent.
I think it's because the server needs to set a samesite rule that's strict so that you have to start the request and end the request on Scratch.mit.edu.
Activity
TheCommCraft commentedon Feb 6, 2025
Alastrantia commentedon Feb 6, 2025
why does the scratch app make requests to it tho if it's not needed?
TheCommCraft commentedon Feb 6, 2025
TheCommCraft commentedon Feb 6, 2025
Maybe some browsers don't support setting cookies using js
50-scratch-tabs commentedon Feb 9, 2025
It has something to do with making sure that requests are coming from scratch.mit.edu, and it lies not in the content of the cookie, but the fields. This (and some other CSRF things across Scratch) ensures that you can't, for example, post on the forums by submitting a form on another website.
Alastrantia commentedon Feb 9, 2025
Interesting. Could you please provide more details for how it lies in the fields? From what I've seen, this is what i figured out but I'm not sure:
In some requests there are 2 fields for csrf tokens, one is the cookie and the other is x-csrftoken. if a malicious website submits a request to it and the browser automatically sends the cookies, the x-csrftoken field is not part of it and the attacker would still need to input a static value for it, cuz they still can't read the cookies. the only thing the server does here is to check if both are equal.
Is that correct? Is there more to it?
thank you
TheCommCraft commentedon Feb 9, 2025
Yeah, we knew that but why doesn't the website just generate the cookie using js was the question
Alastrantia commentedon Feb 9, 2025
yes, thats weird. there must be some server side validation of the value itself too...
i saw the /csrf_token endpoint is still there on the old scratch 2.0 login page, it's made before the /login request. no authentication data except for the existing saved csrf token is sent.
50-scratch-tabs commentedon Feb 9, 2025
I think it's because the server needs to set a samesite rule that's strict so that you have to start the request and end the request on Scratch.mit.edu.