search

wavedrom / wavedrom

:ocean: Digital timing diagram rendering engine
https://wavedrom.com
MIT License
2.95k stars 364 forks source link

Secure JSON parser #75

Open drom opened 10 years ago

drom commented 10 years ago

From alex.d...@gmail.com on June 30, 2013 21:57:49

Currently using JavaScript eval(). Thinking about secure JSON parser.

eval()

Pros: Non-strict object notation: allow_singlequote {'foo':'bar'} allow_barekey {foo:"bar"} list items can have an end-comma ...

Cons: The solution has Security issues.

JSON.parse

Pros: Secure Cons: Very strict.

Own the parser

???

Original issue: http://code.google.com/p/wavedrom/issues/detail?id=75

nturley commented 8 years ago

Another alternative is to run the json through a linter before sending it into JSON.parse. That way you don't need to maintain a json parser but can still accept weak json. I'm sure there are dozens of json linters on npm.

drom commented 8 years ago

@nturley current editor window accepts JS code as valid WaveDrom source. So, one can run some configurable diagrams. And it is useful. I think. There are so many ways to write infinite loop in JS, or run out of memory that it might be hard to detect. I have relaxed JSON parser (https://github.com/drom/jsof) that extracts data object but will not run code. Other option would be running WaveDrom code in a separate worker, and kill it after some timeout 200ms?

itsayellow commented 8 years ago

As you know, I am heavily using javascript code in my wave specification. I find it so useful, for really advanced stuff (hbounds) but also just for simple stuff, like code that repeats the same section of waveform multiple times. It would be a shame to lose this functionality.

It's a cheap way to make wavedrom extensible without having to add the features directly to wavedrom itself.

That being said, it would be nice to have some sort of checking. Even something that would act like jshint.com and give you some clue where your error is. I like the idea of a linter. Also the timeout sounds like a pretty painless way to prevent infinite looping. I might set it long--it's ok if you have to wait a second or two for bad code--it shouldn't happen that often. I've actually made an infinite loop before, but it was using the CLI version of wavedrom, so fairly easy to break out of it.