3 ms·
Having your DB server (regardless of type) exposed to the entire internet is a bad idea but that's not the real problem here (it just makes this really scary fo
by sehrope 14y ago
Having your DB server (regardless of type) exposed to the entire internet is a bad idea but that's not the real problem here (it just makes this really scary for people running wide open MongoDB instances). This is a lack of validation of client inputs by the server itself and (in my opinion) a dangerous default choice of trusting your client.
Most DBs allow something similar to this though it's generally locked down by default.
For PostgreSQL you can do it via untrusted languages though by default only super users can use those: http://www.postgresql.org/docs/9.1/static/plperl-trusted.html http://www.postgresql.org/docs/9.1/static/plperl-trusted.htm...
For Oracle here's a bunch of ways to accomplish the same thing though again, by default, all are blocked for non-DBA users: http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:16212348050 http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTI...
Note that there are some times when it's useful to be able to execute misc things like this. About 6 or 7 years back I wrote something on Oracle that would execute shell commands to get iostat/vmstat output and save it on regular intervals. Could have been done from outside in (data gets pushed from unix => DB) but having it initiated by the DB itself let us control when it runs based on DB actions (triggers, DBMS_JOBs, etc). To get that setup though we had to whitelist the executables we were calling as by default on Oracle everything is blocked. It's not a common thing to do and I think it's sensible that things like that should be locked down by default.