←back to thread

setBigTimeout

(evanhahn.com)
210 points cfj | 1 comments | | HN request time: 0s | source
Show context
n2d4 ◴[] No.41880898[source]
The default behaviour of setTimeout seems problematic. Could be used for an exploit, because code like this might not work as expected:

    const attackerControlled = ...;
    if (attackerControlled < 60_000) {
      throw new Error("Must wait at least 1min!");
    }

    setTimeout(() => {
      console.log("Surely at least 1min has passed!");
    }, attackerControlled);

The attacker could set the value to a comically large number and the callback would execute immediately. This also seems to be true for NaN. The better solution (imo) would be to throw an error, but I assume we can't due to backwards compatibility.
replies(6): >>41881042 #>>41881074 #>>41881774 #>>41882110 #>>41884470 #>>41884957 #
swatcoder ◴[] No.41881774[source]
That's just terrible input validation and has nothing to do with setTimeout.

If your code would misbehave outside a certain range of values and you're input might span a larger range, you should be checking your input against the range that's valid. Your sample code simply doesn't do that, and that's why there's a bug.

That the bug happens to involve a timer is irrelevant.

replies(3): >>41881907 #>>41885121 #>>41888700 #
ashkankiani ◴[] No.41885121[source]
You are a bad programmer if you think silently doing the wrong thing is not a bug. The right thing to do with unexpected input as the setTimeout library author is to raise an exception.
replies(2): >>41885327 #>>41888753 #
1. balls187 ◴[] No.41888753[source]
The wrong thing, or the undefined thing?

Feel free to make a proposal to ECMA.