search

small-tech / jsdb

A transparent, in-memory, streaming write-on-update JavaScript database for Small Web applications that persists to a JavaScript transaction log.
Other
236 stars 8 forks source link

Is not using .js files as a DB on servers quite dangerous and prone to cause vulnerabilities? #11

Open rugk opened 2 years ago

rugk commented 2 years ago

This all sounds nice to store data in .js files directory, however, is not this quite dangerous when you think about it?

The problem

Because as soon as you use it for some sensitive data of some kind – which almost always happens when you use a database, even aggregations of what seems to be quite public data can be sensitive – it gets somewhat critical. (And BTW; you talk about privacy in your Readme, so clearly you consider the fact that there could be private data in the DBs.) The technical issue of course is easy: By default, when .js files are placed on a webserver, anyone can download them, as .js files are of course intended to be used like databases.

This is not at all theoretical. After all data leaks are very common and simply downloading files from random webservers under well-known locations is somewhat shockingly incredible common, so that even tools exist to automate that. See also the list of breaches and linked news articles here which have all that in common. And people forget .git directories or saved nano/vim backup copies of files… so it is easy to forget. Or database dumps… etc. See the talk also linked there e.g.. I could go on here, talk about a vulnerability/problem in a project I am affiliated with, where we ended up using a config.ini.php instead of config.ini file, because that is guaranteed to be parsed by most web servers by default and thus won't expose sensitive data. (That's also why most public CMSes based on PHP e.g. do it like this…)

Solution?

It may be obvious to you that of course you should not use the project like this/keep the database files private, but stating the obvious is always a good idea when it comes to security. As such, at least document that you (obviously, as said, but well… keeping .ini files private is also obvious, yet it happens that these are exposed due to accidental misconfiguration etc.…) should somehow place the files into a directory not-accessible by any webserver. Maybe you can also do some further hardening with user permissions, SeLinux or webserver onfiguration… E.g. what may an – arguably ugly – workaround is if you save your files as database.js.php, which makes the files being non-accessible if they are on a PHP-compatible webserver. Otherwise, a different file ending such as .jsdb or another not-served by webservers file extension may be used – though of course the protection effect depends on how webservers treat such a file extension by default. (After all, remember people are lazy… manually adjusting webserver configs is likely not being done. :wink:)

Also, of course, it should be remembered people may take this into care when directly working with this here, respectively, if they know they work with that here. However, when used in third-party projects like your Site.js that information/risk can soon be forgotten about.

aral commented 2 years ago

@rugk Good point on documenting that the database files should not be kept in web directories. However, in this regard, it is no more or less secure than any other database that keeps its data in files. So the same concern applies to SQLite, for example. There’s nothing inherently more dangerous to have the data in JS files apart from the fact that you could easily query the data when it loads in a browser vs, say, having to launch SQLite to do so after you’ve downloaded the database. Either way, if you serve a database file from your web server, the data will be compromised.

PS. I’m about to move this repository to Codeberg. I’ll make sure the documentation issue is tracked there.