Well it's not some huge security risk, though it reveals some potential interference at least.
Suppose we have those very well closed JavaScript modules that is loaded into my page without knowing about each other. They are from "trusted" however some developer in lib2 made a mistake, see the code.
Lib1 http://good.site/libs/the-famous-important-lib1.js
setInterval(function(){
alert('I am doing some important stuff');
}, 1000);
Lib2 http://not-excelent.site/libs/the-cool-lib2.js
var i = setInterval(function(){}, 0);
for(; i >= 0; i-=1) {
clearInterval(i);
}
My Html
<script src="http://good.site/libs/the-famous-important-lib1.js" type="text/javascript"></script>
<script src="http://not-excelent.site/libs/the-cool-lib2.js" type="text/javascript"></script>
In a browser or at least on Firefox, Loading Lib2 would actually break Lib1 totally. Some might say this is not important, and how silly to make such mistake.
I consider that as a bad behavior. Since we are loading more and more 3rd party libs in our websites. Maybe a proper solution is that setInterval
, and setTimeout
should return an Ojbect to be really unique and un-fakable, instead of just numeric auto increment ID.
Someone might cam up with a real-world exploitation for this (still didn't test if it is cross frames, I doubt it really).
The question is: Is it? and Does strict mode in es5 overcomes that?
Sink functions such as eval(), setTimeout() and setInterval() are dangerous, since they make it possible to execute even text passed through them. The input to these functions is controlled completely on the client-side.
In case of time intensive synchronous operations, setTimeInterval may break the rhythm. Also, if any error occurs in setInterval code block, it will not stop execution but keeps on running faulty code. Not to mention they need a clearInterval function to stop it.
In WebExtensions, setTimeout() does not work reliably. Extension authors should use the alarms API instead.
Explanation: setTimeout() is non-blocking which means it will run when the statements outside of it have executed and then after one second it will execute. All other statements that are not part of setTimeout() are blocking which means no other statement will execute before the current statement finishes.
Does strict mode in es5 overcomes that?
No. setInterval
and setTimeout
are part of the DOM bindings -- they are not EcmaScript builtins so are not specified in any version of EcmaScript. Nothing in strict mode specifically affects them.
This will probably change in the next version of EcmaScript since the TC39 committee thinks that concurrency is a core language feature that needs to be specified and will probably retain event loop concurrency.
Those changes are unlikely to affect the problem you raise though. Caja / Secure EcmaScript (SES) does make sure that interval and timeout ids are not guessable.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With