51–60 of 129 posts
Earlier quoted context omitted.
You're correct about JS numbers. It works like this presumably because the implementation is written in C++ or the like and uses an int32 for this, because "25 days ought to be enough for everyone".
I thought most non-abandoned C/C++ projects have long switched to time_t or similar. 2038 is not that far in the future.
Earlier quoted context omitted.
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.
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.
Rate limits are implemented with e.g., token buckets which fill to a limit at a fixed rate. Timed tasks would then on run try to take a token, and if none is present wait for one. This would then be dutifully enforced regardless of the current state of scheduled tasks.
Only consideration for the timer itself would be to always add random jitter to avoid having peak loads coalesce.
I wish that I could actually see the code. I understand that it's chaining timeouts, but the git site is just garbage
Earlier quoted context omitted.
No, it pretty much just does exactly that. const subtractNextDelay = () => { if (typeof remainingDelay === "number") { remainingDelay -= MAX_REAL_DELAY; } else { remainingDelay -= BigInt(MAX_REAL_DELAY); } };
Oh yikes. Yeah; not ideal.
I've had too many sleep functions not work as they should to still rely on this, especially on mobile devices and webpages where background power consumption is a concern. It doesn't excuse new bad implementations but it's also not exactly surprising
Earlier quoted context omitted.
> That's just terrible input validation and has nothing to do with setTimeout. Except for the fact that this behaviour is surprising. > 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. Indeed, so why doesn't setTimeout internally do that?
> Indeed, so why doesn't setTimeout internally do that? Given that `setTimeout` is a part of JavaScript's ancient reptilian brain, I wouldn't be surprised it doesn't do those checks just because there's some silly compatibility requirement still lingering and no one in the committees is brave enough to make a breaking change. (And then, what should setTimeout do if delay is NaN? Do nothing? Call immediately? Throw an…
instead of chaining together shorter timeouts, why not calculate the datetime of the delay and then invoke via window.requestAnimationFrame (by checking the current date ofc).
Earlier quoted context omitted.
You're correct about JS numbers. It works like this presumably because the implementation is written in C++ or the like and uses an int32 for this, because "25 days ought to be enough for everyone".
I thought most non-abandoned C/C++ projects have long switched to time_t or similar. 2038 is not that far in the future.
Earlier quoted context omitted.
You're correct about JS numbers. It works like this presumably because the implementation is written in C++ or the like and uses an int32 for this, because "25 days ought to be enough for everyone".
I thought most non-abandoned C/C++ projects have long switched to time_t or similar. 2038 is not that far in the future.
Earlier quoted context omitted.
Don’t ever use attacker controlled data directly in your source code without validation. Don’t blame setTimeout for this, it’s impolite!
The problem is the validation. You'd expect you just have to validate a lower bound, but you also have to validate an upper bound.