[dragonwriter]

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.

[exevp]

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.

[dragonwriter]

> bypassing some timer in an API service requires the API to accept the string „Infinity“ and convert it to the JavaScript value Infinity

Yeah, a more realistic bypass would be entering “3000000000”, which would trigger the same behavior.

[code4money]

Will bypass a few validations if server accepts as param from client:

Number(Infinity) -> Infinity

Infinity < 5000 -> will return false even though Infinity is acting as a 0 here

[exevp]

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.

[goldenkey]

parseFloat('Infinity'), JSON.parse('1e1024'), or parseFloat('1e1024') work just fine ;-)

[goldenkey]

JSON.parse converts 1.0e+1024 to Infinity just fine. ;-)