|
|
|
|
|
|
by ajanuary
3188 days ago
|
|
|
There is a difference between a recogniser, which answers the question "does this belong to the language", and a parser, which outputs a data structure. All you need here is a recogniser, and then pass the string through to eval which will do it's own parsing. Recognisers are smaller than parsers. If you relax the rules, as the gp said, you can get away with something like a regex to do the job. While regex's are bad at context free grammars [0], if you forgo balancing brackets etc. a regex will do just fine. All that said, with the crazy things JS lets you do [1] a recogniser for a relaxed language is likely to still let potentially dangerous code though. [0] Yes, with most regex engines you can parse CFGs, but it's not nice, and at that point you _do_ want a grammar based parser [1] http://www.jsfuck.com/ |
|
|
Please note that the term "recogniser" is very fuzzy, it could mean a regex matcher, a parser or even a turing-complete thing. Not very helpful for this discussion.
> a parser, which outputs a data structure
Please note that a parser is not required to output a data structure. In classic computer science, the parser of a context-free grammar usually has a minimal (boolean) output: it just either accepts or rejects the input.
If your "recognizer" is too weak (e.g. regexes), you risk not properly checking the language (see below).
If your "recognizer" is too powerful (e.g. turing complete), you risk tons of loopholes which are hard to find and hard to analyze. You probably won't be able to prove the security, and even if you do, it will probably be hard work, and even harder for others to follow and to verify.
But if your "recognizer" is a parser, you have a good chance to succeed in a safe way with minimal effort. Proving security is as simple as comparing your grammar with the ECMAscript standard.
> you can get away with something like a regex to do the job [...] with the crazy things JS lets you do a recogniser for a relaxed language is likely to still let potentially dangerous code though
That's exactly my point: Sure, you can try to build a protection wall based on regexes, but there's no reason to do that. Use a proper parser right away and don't waste your time with repeating well-known anti-patterns.