[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. ;-)