-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
馃殌 Feature: add CSRF tokens to protect from CSRF vulnerability #4967
Comments
@usamashafiqs thanks for raising this issue! 馃檹馃徏 |
@usamashafiqs, as far as I'm aware, CSRF requires an attacker to host a malicious form and trick a user to browse to the from. The form would then auto-submit using the Appwrite cookie. Appwrite should be safe because we check the origin header and block the request if it isn't a registered application. Is there anything I'm missing? |
@usamashafiqs, thanks for providing that. Are you able to build a POC that would perform a CSRF against Appwrite? |
@usamashafiqs feel free to report a vulnerability if you're able to put together a POC. |
馃敄 Feature description
What is a CSRF token?
A CSRF Token is a secret, unique and unpredictable value a server-side application generates in order to protect CSRF vulnerable resources.
The tokens are generated and submitted by the server-side application in a subsequent HTTP request made by the client.
After the request is made, the server side application compares the two tokens found in the user session and in the request. If the token is missing or does not match the value within the user session, the request is rejected, the user session terminated and the event logged as a potential CSRF attack.
馃帳 Pitch
How should CSRF tokens be generated?
Just like session tokens in general, CSRF tokens should contain significant entropy and be strongly unpredictable.
You can achieve this by using a cryptographic strength pseudo-random number generator (PRNG), seeded with the timestamp when it was created and a static secret.
For further security, you can generate individual tokens by chaining their outputs with user-specific entropy and take a strong hash of the whole structure.
This presents an additional obstacle to a malicious user who attempts to analyze the tokens based on a sample that is issued to him.
馃憖 Have you spent some time to check if this issue has been raised before?
馃彚 Have you read the Code of Conduct?
The text was updated successfully, but these errors were encountered: