←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 #
arghwhat ◴[] No.41881042[source]
A scenario where an attacker can control a timeout where having the callback run sooner than one minute later would lead to security failures, but having it set to run days later is perfectly fine and so no upper bound check is required seems… quite a constructed edge case.

The problem here is having an attacker control a security sensitive timer in the first place.

replies(2): >>41881665 #>>41888952 #
a_cardboard_box ◴[] No.41881665[source]
The exploit could be a DoS attack. I don't think it's that contrived to have a service that runs an expensive operation at a fixed rate, controlled by the user, limited to 1 operation per minute.
replies(2): >>41882211 #>>41883672 #
lucideer ◴[] No.41882211[source]
> I don't think it's that contrived to have a service that runs an expensive operation at a fixed rate, controlled by the user

Maybe not contrived but definitely insecure by definition. Allowing user control of rates is definitely useful & a power devs will need to grant but it should never be direct control.

replies(1): >>41882396 #
shawnz ◴[] No.41882396[source]
Can you elaborate on what indirect control would look like in your opinion?

No matter how many layers of abstraction you put in between, you're still eventually going to be passing a value to the setTimeout function that was computed based on something the user inputted, right?

If you're not aware of these caveats about extremely high timeout values, how do any layers of abstraction in between help you prevent this? As far as I can see, the only prevention is knowing about the caveats and specifically adding validation for them.

replies(2): >>41882973 #>>41885728 #
1. bryanrasmussen ◴[] No.41885728[source]
>Can you elaborate on what indirect control would look like in your opinion?

although not the OP this is what I would mean by indirect control.

pseudo if userAccountType === "free" then rate = longRate

if userAccountType === "base" then rate = infrequentRate

if userAccountType === "important" then rate = frequentRate

obviously rate determination would probably be more complicated than just userAccountType