Its not “bypassing” if you have to write the code used to setup the timer to do it.
I suppose it implies the existence of a class of potential problems if an application (1) accepts user input for timer delays, (2) requires a certain minimum delay, (3) only checks that the entered amount is >= the minimum without considering overflow behavior. But, since this behavior is well-documented (the MDN page on setTimeout covers it), it doesn't seem like any kind of notable discovery.
Also the example of bypassing this is rather contrived:
1) bypassing some timer in an API service requires the API to accept the string „Infinity“ and convert it to the JavaScript value Infinity - which is highly unlikely. Instead, the value would just fail the numeric validation.
2) bypassing some timer in client-side code by injecting Infinity seems overly complex - if you alter client-side code you might aswell just remove the validation instead of abusing edge cases of the language runtime.
This is probably a good opportunity to have a heated discussion over parseInt() vs Number() since parseInt('Infinity') yields NaN.
I know people prefer Number() for reasons but in this case it reveals the weakness of using basically a typecast with implicit language semantics for interpreting string inputs.
If a NodeJS application accepts a value from the client application, but validates against an early call (e.g. min 25 mins from now) the Infinity value can bypass that validation.
Because it's a relatively unknown side effect, most validations probably wouldn't check for Infinity.
Plus although Infinity pops off the timer at 0 seconds, a validation based on millisecond math would fail because Infinity > 25 minutes in milliseconds.
11 comments
[ 3.1 ms ] story [ 39.5 ms ] threadI suppose it implies the existence of a class of potential problems if an application (1) accepts user input for timer delays, (2) requires a certain minimum delay, (3) only checks that the entered amount is >= the minimum without considering overflow behavior. But, since this behavior is well-documented (the MDN page on setTimeout covers it), it doesn't seem like any kind of notable discovery.
1) bypassing some timer in an API service requires the API to accept the string „Infinity“ and convert it to the JavaScript value Infinity - which is highly unlikely. Instead, the value would just fail the numeric validation.
2) bypassing some timer in client-side code by injecting Infinity seems overly complex - if you alter client-side code you might aswell just remove the validation instead of abusing edge cases of the language runtime.
Yeah, a more realistic bypass would be entering “3000000000”, which would trigger the same behavior.
Number(Infinity) -> Infinity
Infinity < 5000 -> will return false even though Infinity is acting as a 0 here
Because it's a relatively unknown side effect, most validations probably wouldn't check for Infinity.
Plus although Infinity pops off the timer at 0 seconds, a validation based on millisecond math would fail because Infinity > 25 minutes in milliseconds.