Comments 5
Thx for the article. It was as crazy as usual, good job.
Could you plz clarify this:
But what about infinite loops? They are quite easy to detect… you can detect it after the fact and delete it automatically or manually
Do you mean detecting infinite loops without running the code? Just analyze it? Hm… I didn't catch the idea.
Some other thoughts:
- Anyone who wants to play with the sandbox, do not forget
return
keyword. As a whole it's just a function. - If anyone thought why don't just use
with(...){}
—with
doesn't work instrict
mode - Unfortunately
debugger
didn't work there either :( Even though usually it works witheval
(e.g. it helps to test autoclosing popovers withsetTimeout('debugger', 3000)
). - Probably if there's a way to hack this it would include such things as throwing errors, weird using RegExp,
__proto__
, etc.
Do you mean detecting infinite loops without running the code? Just analyze it? Hm… I didn't catch the idea.
I mean, we can run code on the user's device when he write it to prevent saving of unstoppable code. And we can run code on the server in separate thread to guard from hackers which bypassed UI. However, yes, it won't help if the code stops only occasionally depending on the input data. But we can detect long freeze (ie Chrome allow user to halt script after 15 s), mark this code as broken, and user as banned.
However, shadowed window
and document
objects from inner iframe are accessible
const o = __proto__.__proto__.__proto__.__proto__.constructor;
try{o.defineProperty(__proto__, "w", {get: function() { return this } });}catch(e){};
const d = w.document;
Sign up to leave a comment.
$mol_func_sandbox: hack me if you might!.