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
Checking the signature with == allows an attacker to compare timing results between attempts, walking the prefix of the signature until the whole signature is found.
Using a plain == operator is not advised. A method like secure_compare performs a "constant time" string comparison, which helps mitigate certain timing attacks against regular equality operators.
There's a possibility that with a pure JavaScript implementation the JIT optimizer will still detect the early return path, causing the timing vulnerability to still exist. That's why I use a count rather than a simple boolean, and run the compare in a separate function. If the optimizer sees that it needs to return the value of count, it should be less likely to short circuit the loop.
The text was updated successfully, but these errors were encountered:
Checking the signature with
==
allows an attacker to compare timing results between attempts, walking the prefix of the signature until the whole signature is found.x-hub-signature/src/XHubSignature.js
Line 27 in 78e3768
https://docs.github.com/en/webhooks-and-events/webhooks/securing-your-webhooks
Node provides
crypto.timingSafeEqual(a, b)
.A runtime-agnostic alternative would be to loop over the string like so:
There's a possibility that with a pure JavaScript implementation the JIT optimizer will still detect the early return path, causing the timing vulnerability to still exist. That's why I use a count rather than a simple boolean, and run the compare in a separate function. If the optimizer sees that it needs to return the value of count, it should be less likely to short circuit the loop.
The text was updated successfully, but these errors were encountered: