Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upCross-platforms method to enumerate all globals? #1240
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ljharb
Jun 20, 2018
Member
The globals are Object.getOwnPropertyNames(global) where global is Function(‘return this’)() or the equivalent. I’m not sure what you’re asking for.
Separately, if you’re looking into sandboxing, you may want to look into prior art: Caja and SES.
|
The globals are Separately, if you’re looking into sandboxing, you may want to look into prior art: Caja and SES. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gardhr
Jun 20, 2018
@ljharb Thank you so much, precisely what I was looking for! And yes, somewhat familiar with Caja and SES but this is more of a "safe eval" type of project. Hadn't found anything yet along those lines so I decided to take a stab at it myself. Anyhow, thanks again for the prompt, helpful response. Cheers!
gardhr
commented
Jun 20, 2018
|
@ljharb Thank you so much, precisely what I was looking for! And yes, somewhat familiar with Caja and SES but this is more of a "safe eval" type of project. Hadn't found anything yet along those lines so I decided to take a stab at it myself. Anyhow, thanks again for the prompt, helpful response. Cheers! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
loganfsmyth
Jun 20, 2018
Contributor
Object.getOwnPropertyNames(global) is as close as you'll get I think, but it will only enumerate all var-scoped globals like var and function declarations, it will not enumerate lexical globals, so it won't catch let/const/class declarations in the global scope.
Whether or not that matters probably depends on the details of what you're doing, but it is worth mentioning at least.
|
Whether or not that matters probably depends on the details of what you're doing, but it is worth mentioning at least. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gardhr
Jun 20, 2018
@loganfsmyth True, but as far as this project goes I really just want to provide a mechanism to prevent scripts from accessing/modifying properties of native types and platform-specific globals. Thank you for pointing that out though, definitely worth noting and I'll be sure to mention that in the documentation nonetheless.
gardhr
commented
Jun 20, 2018
|
@loganfsmyth True, but as far as this project goes I really just want to provide a mechanism to prevent scripts from accessing/modifying properties of native types and platform-specific globals. Thank you for pointing that out though, definitely worth noting and I'll be sure to mention that in the documentation nonetheless. |
ljharb
added
the
question
label
Jun 20, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Closing; but we can continue discussing as needed. |
ljharb
closed this
Jun 20, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
robpalme
Jun 20, 2018
robpalme
commented
Jun 20, 2018
|
I don't think this safety is possible without a frozen realm because the
caller can always get to certain globals.
[].__proto__.smoosh = ...
…On Wed, 20 Jun 2018, 20:16 Sebastian Garth, ***@***.***> wrote:
@loganfsmyth <https://github.com/loganfsmyth> True, but as far as this
project goes I really just want to provide a mechanism to prevent scripts
from accessing/modifying properties of native types and platform-specific
globals. Thank you for pointing that out though, definitely worth noting
and I'll be sure to mention that in the documentation nonetheless.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1240 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGni9dxvXoRvbKQQjr2MkCOAo6MqLjkFks5t-p94gaJpZM4UvUql>
.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
IgnoredAmbience
Jun 20, 2018
Member
The source code for Caja/SES is here, it is well worth reading to get an understanding for many of the JS edge cases that permit sandbox escapes, the startSES.js file is an appropriate place to begin reading. The codebase is well-commented.
|
The source code for Caja/SES is here, it is well worth reading to get an understanding for many of the JS edge cases that permit sandbox escapes, the |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gardhr
Jun 20, 2018
@robpalme Hmm, I can't seem to produce anything meaningful from that. Would you mind providing a working example?
EDIT: Also, in the above case would it be sufficient to simply call Object.freeze([].__proto__) ?
gardhr
commented
Jun 20, 2018
•
|
@robpalme Hmm, I can't seem to produce anything meaningful from that. Would you mind providing a working example? EDIT: Also, in the above case would it be sufficient to simply call |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gardhr
commented
Jun 20, 2018
|
@IgnoredAmbience Thanks, I'll have a look at that! |
gardhr commentedJun 20, 2018
•
edited
I'm currently working on a project to allow sandboxed loading of scripts. The basic approach is to selectively declare "shadow" variables for defined globals and native types. The problem is I'm not sure how to do this in the most generic way across all platforms. My current naive attempt is essentially:
`
`
That seems to work okay so far, but it's just too easy for things to fall through the cracks. Is there a more generic method to do this that is guaranteed to catch all possible definitions?