Skip to content

Comments

Add Cross-Site-Forgery-Request (CSRF) protection#753

Merged
yannickwurm merged 1 commit intomasterfrom
tt/csrf
Jun 25, 2024
Merged

Add Cross-Site-Forgery-Request (CSRF) protection#753
yannickwurm merged 1 commit intomasterfrom
tt/csrf

Conversation

@tadast
Copy link
Collaborator

@tadast tadast commented Jun 25, 2024

Cross-Site Request Forgery (CSRF) is a type of malicious exploit of a website where unauthorized commands are transmitted from a user that the web application trusts. Without the user's knowledge, the attacker tricks the victim into performing actions on their behalf. i.e. copy-pasting JS commands to dev tools console or similar. This vulnerability exploits the trust that a site has in a user's browser, allowing attackers to perform actions on behalf of the user without their consent or awareness.

To protect from this attack we're adding a crsf token, that is generated randomly, stored in session, and added to each form submission/POST request. Requests fail if the token value submitted does not match the value in the session, significantly reducing the risk of malicious or unintentional requests on behalf of the user.

While this is not really necessary for locally running instances or public instances, folks hosting their own private instances or exposing locally hosted instances to the internet will benefit from this.

Cross-Site Request Forgery (CSRF) is a type of malicious exploit of a
website where unauthorized commands are transmitted from a user that
the web application trusts. Without the user's knowledge, the attacker
tricks the victim into performing actions on their behalf.
i.e. copy-pasting JS commands to dev tools console or similar.
This vulnerability exploits the trust that a site has in a user's browser,
allowing attackers to perform actions on behalf of the user without
their consent or awareness.

To protect from this attack we're adding a crsf token, that is generated
randomly, stored in session, and added to each form submission/POST
request. Requests fail if the token value submitted does not match
the value in the session, significantly reducing the risk of malicious
or unintentional requests on behalf of the user.

While this is not really necessary for locally running instances or
public instances, folks hosting their own private instances or exposing
locally hosted instances to the internet will benefit from this.
@tadast tadast requested a review from yannickwurm June 25, 2024 16:41
@yannickwurm yannickwurm merged commit 741acd8 into master Jun 25, 2024
@yannickwurm yannickwurm deleted the tt/csrf branch June 25, 2024 22:10
@nathanweeks
Copy link
Contributor

@tadast Did the ability to POST an input_sequence (#491) break (InvalidCsrfToken error) when CSRF protection was added?

@tadast
Copy link
Collaborator Author

tadast commented Aug 20, 2024

@tadast Did the ability to POST an input_sequence (#491) break (InvalidCsrfToken error) when CSRF protection was added?

Hi @nathanweeks, very likely yes. Unfortunately this is an undocumented feature that very few users use, so it may take a bit longer to update.

If you have any capacity, we'd welcome a PR which either optionally turns on this feature but with CSRF protection disabled for this endpoint, or alternatively allows to configure whitelisted hostnames from where the CSRF token can be fetched (this might need to be in the same domain for the session cookie to be valid). The latter is much more involved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants