Introducing JSDB
“It’s all JavaScript… What I mean by that is that even the data is stored as JavaScript code. Not JSON. JavaScript.”
@aral I have to admit I'm a bit concerned what my good friend Bobby Tables might do with a database that stores data as JS that gets evaled at run time.
@kyle Let me know if my reply to James addresses your concern. Also, it’s a tiny codebase (~1,000 lines of code not including tests and comments) so if you do get a chance to peek at it and notice any issues, I’d love it if you could let me know.
@aral I'll have to admit that I am not fluent in Javascript. My worries were more triggered by the overall concept of data being stored as executable code that was evaled when reading, and what an attacker could do who could write to that database or bypass sanitization attempts, since they would, in theory, have the full range of JS capabilities at their disposal (arbitrary code exec) instead of the more limited set of standard DB queries (data leak).
@kyle Yep, valid concerns. As far as I can see, the sanitation routines I’ve implemented address those attack vectors. The only time the person using JSDB has to implement their own sanitation at the moment is if they’re creating a custom query themselves using string manipulation with untrusted content. Otherwise, I believe I’ve blocked (at least the obvious) arbitrary code execution and also the query extension/data leak pathways. Hopefully more eyes can verify or improve it :)