Skip to content

CSRF Verification + Authentication on Scratch #342

Closed

Description

@Alastrantia

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

Activity

  1. TheCommCraft commented on Feb 6, 2025

    @TheCommCraft
    Collaborator
  2. Alastrantia commented on Feb 6, 2025

    @Alastrantia
    Author

    why does the scratch app make requests to it tho if it's not needed?

  3. TheCommCraft commented on Feb 6, 2025

    @TheCommCraft
    Collaborator
  4. TheCommCraft commented on Feb 6, 2025

    @TheCommCraft
    Collaborator

    Maybe some browsers don't support setting cookies using js

  5. 50-scratch-tabs commented on Feb 9, 2025

    @50-scratch-tabs
    Contributor

    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.

  6. Alastrantia commented on Feb 9, 2025

    @Alastrantia
    Author

    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.

    Is that correct? Is there more to it?
    thank you

  7. TheCommCraft commented on Feb 9, 2025

    @TheCommCraft
    Collaborator

    Yeah, we knew that but why doesn't the website just generate the cookie using js was the question

  8. Alastrantia commented on Feb 9, 2025

    @Alastrantia
    Author

    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.

  9. 50-scratch-tabs commented on Feb 9, 2025

    @50-scratch-tabs
    Contributor

    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.

  10. Repository owner locked and limited conversation to collaborators on Apr 13, 2025
  11. converted this issue into a discussion #380 on Apr 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions