New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot evel multiple lines of code #12
Comments
Hmm, tempting to fix that but please be aware that this project does not "work" as I'd originally hoped: #11 |
No problem! It was a noble attempt, has yielded insight and identified pitfalls. I'm hunting for a solution but it sounds like it will require a 'metacircular interpreter' approach where the code is actually interpreted by an interpreter built in js. Hmm I do have one more idea to salvage this attempt though... let me try it out. As long as you can see this issue being trivially resolved. |
I have some questions - I'm |
This is now the most critical issue, until I find another glaring security hole : ) |
I dealt with some annoying eval-like stuff in https://github.com/natevw/ddoc/blob/master/index.js#L19 — the string munging solution there is pretty lame and I'm not sure if it's relevant since it looks like I simply use the built-in "eval" to handle the multiple statements case. Anyway, maybe I shouldn't worry — at the rate you're going you'll probably have figured this one out too by the time I'm up again 👍 |
Yeah this is a tricky one eh. AFAICT, it would require modifying the code to have a return statement on the last line of the program. This would be easy using |
Yeah, this seems tricky. Replacing semicolons with commas would work in some of the cases, but to do it right you'd still need to parse and so at that point you might as well just add the return statement. One early thought, haven't fully reviewed where we're at with your recent progress, but IIRC originally the builtin
So (again haven't reviewed) maybe the way to handle eval is to a) not override |
Ah, that is an important discrepancy I was not aware of. and I think we may not be able to provide that 'feature' or eval. var x = 123
evel('console.log(x)')
//=> undefined
eval('console.log(x)')
//=> 123
Function('console.log(x)')()
//=> 123 (wait wut, i thought it wasn't in scope) EDIT: now i realize that |
I mean if |
To reiterate the discussion on #14, the unfettered use of So this is looking like a tougher one. Note that we already don't support all the code that built-in Function/eval due (since not all existing code works under strict mode). So if we can't support this "easily", it might need to simply be another caveat. |
heh, looking at this issue again, this is a prrety significant 'caveat' |
The discussion here got interspersed with various discussion of unpatched bypasses, so I thought I'd summarize where this ticket is at: No one has proposed an correct-but-tiny way of doing this yet. I haven't ruled it out (hence leaving this ticket open) but I haven't stumbled across one yet either… You can sometimes get away with using some relatively simple regex/string manipulation to e.g. wrap the code in a called function, adding a return in front of the last line/statement. However, I have concerns with this approach in fully general use. If you like this library's crazy-but-tiny experiment with sandboxing, but still need multi-line eval I would recommend wrapping The only other way I [currently] know to do this right involves static analysis — truly parsing the JS code into a sort of "abstract syntax tree" and then manipulating that so (converted back to code) it will execute having All this to say — I'm content to leave this open for a while yet, hoping someone will come along as happened with past vulnerabilities that seemed even more insurmountable. But meanwhile my advice is either:
|
You can easily wrap your code in a self executing function like this:
Maybe @natevw can implement the self executing function somehow native into the code? |
i think the requirement to return a value so it can be displayed is overvalued against just supporting multiple lines. you can always open the console and explicitly |
Really old thread, but after reviewing this I'm still inclined to leave this limitation in place unless a reliable but simple trick is found. I think these workarounds are acceptable in the meantime:
|
https://github.com/natevw/evel/blob/gh-pages/evel.js#L3
The text was updated successfully, but these errors were encountered: