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
Fix XSS vulnerability in expression parser. #3019
Conversation
|
Hi, not sure if a patch at that level will be enough: In this case it builds a wrong AST and the code generation removes the whitespace, inserting a comment. |
|
Thanks @cgvwzq, I've updated the PR to safeguard the code generation as well. |
|
Glad to help :) However, I'm not sure this is the right way to fix the overall threat, as this patch only prevents the specific payload I used. My experience with JS sandboxing based on parsing/rewriting is that it is extremely hard to get right, and if someone looks into it more security issues will certainly emerge. Just looking at some other features, signals and events seem another source of similar problems. I do not want to turn this into a cat-and-mouse game (as fun as it could be :P), so I would rather suggest to try to rethink the overall eval business. If you need it, I would at least try to make sure that all generated code runs in a sandboxed iframe in isolation (you can rely on postMessage to communicate all data (and events?). |
|
Is there a specify reason that you have to use If you already have an AST couldn't you also just evaluate that AST? {
BinaryExpression: n => {
switch(n.operator) {
case '*': return visit(n.left) * visit(n.right);
case '+': return visit(n.left) + visit(n.right);
case '==': return visit(n.left) == visit(n.right);
...
}
},
UnaryExpression: n =>{
switch(n.operator) {
case '!': return !visit(n.argument);
case '-': return -visit(n.argument);
...
}
},
...
}That would at least prevent any mismatch between interpretation by your parser and the evaluation. |
|
@jheer actually added an interpreter mode to Vega but it's slightly slower so it's not the default: https://github.com/vega/vega/tree/master/packages/vega-interpreter. |
vega-expression
Fix #3018.