3 ms·
This is pretty cool. It's kind of funny how after all the admin interfaces and fancy forms, people always end up wanting to just write their own custom SQL. On
by sehrope 13y ago
This is pretty cool. It's kind of funny how after all the admin interfaces and fancy forms, people always end up wanting to just write their own custom SQL.
On the security front, the SQL blacklist definitely has to go. It's a false sense of security (ex: string concat + dynamic execution gets around it). The suggestion to use a read only user is a good one but even better is to use a read only database (ex: a Postgres replication slave).
Have you checked out JackDB? (http://www.jackdb.com/ http://www.jackdb.com/ full disclosure: I'm the founder) It's a full featured database client that runs entirely in your browser.
- sendob 13y ago+1 to read only, fortunately databases are very good at enforcing this thing, unfortunately the users of databases generally less so. RE: circumventing the blacklist, I think immediately of accessing a function with postgresql aka select my_destructive_function();
- numlocked 13y agoYep, no disagreement there :) The blacklist has no chance of defending against malicious users. Luckily (at the moment) we are using this purely internally and the blacklist is really just preventing people from shooting themselves in the foot. We're moving to a read-only user role shortly, and the suggestion to go with a read-only db is a great one.