Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

setBigTimeout

evanhahn.com

Post reply on HN
Print view View original

21–30 of 129 posts

Re: setBigTimeout

#21

Post by n2d4 »

sfvisser wrote: post #16
n2d4 wrote: post #10

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 { 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 so…

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.

Re: setBigTimeout

#23

Post by adregan »

issafram wrote: post #18

I wish that I could actually see the code. I understand that it's chaining timeouts, but the git site is just garbage

This reminds me of when I am trying to find something in a cabinet, but don’t really look very hard, and my wife will say “did you even try?” and find it in ~1second.

https://git.sr.ht/~evanhahn/setBigTimeout/tree/main/item/mod...

Re: setBigTimeout

#24

Post by yesco »

> In most JavaScript runtimes, this duration is represented as a 32-bit signed integer

I thought all numbers in JavaScript were basically some variation of double precision floating points, if so, why is setTimeout limited to a smaller 32bit signed integer?

If this is true, then if I pass something like "0.5", does it round the number when casting it to an integer? Or does it execute the callback after half a millisecond like you would expect it would?

Re: setBigTimeout

#25

Post by egwynn »

zgk7iqea wrote: post #22
issafram wrote: post #18

I wish that I could actually see the code. I understand that it's chaining timeouts, but the git site is just garbage

yes, sourcehuts interface is just godawful

I agree it’s not the prettiest, but I had no trouble clicking on “tree” to get to the folder and then “mod.ts” to see the code.

Re: setBigTimeout

#27

Post by a_cardboard_box »

arghwhat wrote: post #13
n2d4 wrote: post #10

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 { 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 so…

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.

Re: setBigTimeout

#28

Post by arp242 »

yesco wrote: post #24

> In most JavaScript runtimes, this duration is represented as a 32-bit signed integer I thought all numbers in JavaScript were basically some variation of double precision floating points, if so, why is setTimeout limited to a smaller 32bit signed integer? If this is true, then if I pass something like "0.5", does it round the number when casting it to an integer? Or does it execute the callback after half a millise…

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".

Re: setBigTimeout

#29

Post by blixt »

yesco wrote: post #24

> In most JavaScript runtimes, this duration is represented as a 32-bit signed integer I thought all numbers in JavaScript were basically some variation of double precision floating points, if so, why is setTimeout limited to a smaller 32bit signed integer? If this is true, then if I pass something like "0.5", does it round the number when casting it to an integer? Or does it execute the callback after half a millise…

JS numbers technically have 53 bits for integers (mantissa) but all binary operators turns it into a 32-bit signed integer. Maybe this is related somehow to the setTimeout limitation. JavaScript also has the >>> unsigned bit shift operator so you can squeeze that last bit out of it if you only care about positive values: ((2*32-1)>>>0).toString(2).length === 32

Re: setBigTimeout

#30

Post by darepublic »

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).
Post reply on HN