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.
@jamesgecko @kyle Thanks, James. The attack vectors are not really different to any other web app: your major one is arbitrary code execution via injection attacks. JSDB sanitises strings automatically by escaping backticks, backslashes, and dollar signs (https://source.small-tech.org/site.js/lib/jsdb/-/issues/9). Beyond that, you should never load in a JSDF file from a domain you don’t own and control yourself and have a secure connection to. If you can think of other attack vectors, please do let me know :)
@jamesgecko @kyle PS. I’m now also implementing sanitisation of query input so that developer’s using the library are not expected to do it.
@jamesgecko @kyle Hey both, thanks again for raising this issue. It did get me thinking that JSDB should automatically sanitise queries also, so I’ve just published version 1.1.0 which does that. If you get a chance to peek at the code / explanation of the strategy in the readme and let me know if you see any issues, I’d appreciate it :)
@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 :)
@kyle @aral Yeah, I like that it's so transparent and small. I admire that you've limited even the implementation details of nearly the entire small-tech stack to JavaScript; JSDB is probably the easiest to understand database I've seen. But whenever I see the lines between code and data blurring like this I start getting nervous about exposing it to the internet.