-
Notifications
You must be signed in to change notification settings - Fork 167
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use time-constant comparison for CSRF tokens #9875
Conversation
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected.
SonarQube analysis reported 3 issues Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:
|
No tests since this is functionality equivalent to the previous implementation aside from timing differences that would be very fragile to verify in an automated test. |
I approved the changes. The only drawback is about sacrificing the performance just a little bit for preventing a timing attack, which I assume not be that huge due to the size of the Token. |
Cherry picked to |
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. (cherry picked from commit 292b3a0)
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected.
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected.
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected.
This is the same as #9875, but also applied for the upload security key and the push id since both of those are also used to protect against cross-site attacks. In addition, documentation for the push id is clarified to point out its role.
This is the same as #9875, but also applied for the upload security key and the push id since both of those are also used to protect against cross-site attacks. In addition, documentation for the push id is clarified to point out its role.
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. (cherry picked from commit 292b3a0)
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. (cherry picked from commit 292b3a0)
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. (cherry picked from commit 292b3a0)
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. Cherry-picked from: vaadin/flow#9875
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected.
This is the same as #9875, but also applied for the upload security key and the push id since both of those are also used to protect against cross-site attacks. In addition, documentation for the push id is clarified to point out its role.
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected.
This is the same as #9875, but also applied for the upload security key and the push id since both of those are also used to protect against cross-site attacks. In addition, documentation for the push id is clarified to point out its role.
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. Cherry-picked from: vaadin/flow#9875
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. Cherry-picked from: vaadin/flow#9875 Authored-by: Tatu Lund <tatu@vaadin.com>
This is the same as #9875, but also applied for the upload security key and the push id since both of those are also used to protect against cross-site attacks. In addition, documentation for the push id is clarified to point out its role. Co-authored-by: Leif Åstrand <leif@vaadin.com>
This is the same as #9875, but also applied for the upload security key and the push id since both of those are also used to protect against cross-site attacks. In addition, documentation for the push id is clarified to point out its role. Co-authored-by: Leif Åstrand <leif@vaadin.com>
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected.
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected.
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. No tests since this functionality is equivalent to the previous implementation aside from timing differences that would be very fragile to verify in an automated test. Related to #9875
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. No tests since this functionality is equivalent to the previous implementation aside from timing differences that would be very fragile to verify in an automated test. Related to #9875
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. No tests since this functionality is equivalent to the previous implementation aside from timing differences that would be very fragile to verify in an automated test. Related to #9875
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. No tests since this functionality is equivalent to the previous implementation aside from timing differences that would be very fragile to verify in an automated test. Related to #9875
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. No tests since this functionality is equivalent to the previous implementation aside from timing differences that would be very fragile to verify in an automated test. Related to #9875
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. No tests since this functionality is equivalent to the previous implementation aside from timing differences that would be very fragile to verify in an automated test. Related to vaadin/flow#9875
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. No tests since this functionality is equivalent to the previous implementation aside from timing differences that would be very fragile to verify in an automated test. Related to vaadin/flow#9875
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. No tests since this functionality is equivalent to the previous implementation aside from timing differences that would be very fragile to verify in an automated test. Related to vaadin/flow#9875
This hardens the framework against a theoretical timing attack based on comparing how quickly a request with an invalid CSRF token is rejected. No tests since this functionality is equivalent to the previous implementation aside from timing differences that would be very fragile to verify in an automated test. Related to vaadin/flow#9875
This hardens the framework against a theoretical timing attack based on
comparing how quickly a request with an invalid CSRF token is rejected.