4 ms·

I want to know why exposing databases on the Internet publicly is considered a problem. Is it because a vulnerability found in a database would allow to exploit

I want to know why exposing databases on the Internet publicly is considered a problem. Is it because a vulnerability found in a database would allow to exploit the database directly? I ask this because people expose web-apps on the Internet publicly too and an SQL injection vulnerability on the web-app would also be equally catastrophic. I guess exposing web-apps on the Internet is a risk we need to accept because it has to be available to users of the Internet. But we should not expose anything else that we don't need to? Is that the reason why exposing databases publicly is considered best practice. I would like to know what experienced professionals think about this.

brightball 9y ago
A web app has a connection to a database that can be limited to its exact permission needs, input can be sanitized, database execution can be limited to exactly what the interface has available. Apps can also use connection pools to manage limits of the database. If the database itself is publicly exposed, even if a read only connection with access to an empty table is provided an attacker could simply max out the connection pool to kill your application. If a vulnerability was published or a password with more access was available they can not only access all of your data but they can corrupt it and/or delete it. SQL injection has been pretty trivial to stop for a couple of decades now.
yjftsjthsd-h 9y ago
I think you've hit it; never expose anything without good reason, and the database doesn't need to be exposed. This is compounded because, while apps can have injection vulnerabilities, I expect it to be easier to sanitize things at that level rather than exposing the database but expecting it to filter things enough. Or if you prefer: The failure mode of an app is that it passes raw (escapable) queries to the database. If you expose the DB, then raw queries are the starting line.
james-mcelwain 9y ago
> But we should not expose anything else that we don't need to? Yes. Why would you ever need public logins from the open internet to your production database? Even if you need to ability to log in from a random computer, there are better ways, like requiring the use of a vpn so logins are always coming from a white listed ip.
zzzeek 9y ago
a web app presents a coarse-grained API, in that it exposes a very small, fixed number of API calls with very generic, non-system specific parameters and responses, each of which has been tailored for public exposure. The database OTOH represents an entire programming shell, e.g. extremely fine-grained and in many cases linked directly to the underlying system as was shown in this article - additionally, the number of entrypoints is undefined. If you somehow were convinced that you've locked down every single function of your database from attack, the next day you upgrade the database to a new version and it can very well expose new functions that are again exposed.

brightball 9y ago

A web app has a connection to a database that can be limited to its exact permission needs, input can be sanitized, database execution can be limited to exactly what the interface has available. Apps can also use connection pools to manage limits of the database. If the database itself is publicly exposed, even if a read only connection with access to an empty table is provided an attacker could simply max out the connection pool to kill your application. If a vulnerability was published or a password with more access was available they can not only access all of your data but they can corrupt it and/or delete it. SQL injection has been pretty trivial to stop for a couple of decades now.

yjftsjthsd-h 9y ago

I think you've hit it; never expose anything without good reason, and the database doesn't need to be exposed. This is compounded because, while apps can have injection vulnerabilities, I expect it to be easier to sanitize things at that level rather than exposing the database but expecting it to filter things enough. Or if you prefer: The failure mode of an app is that it passes raw (escapable) queries to the database. If you expose the DB, then raw queries are the starting line.

james-mcelwain 9y ago

> But we should not expose anything else that we don't need to? Yes. Why would you ever need public logins from the open internet to your production database? Even if you need to ability to log in from a random computer, there are better ways, like requiring the use of a vpn so logins are always coming from a white listed ip.

zzzeek 9y ago

a web app presents a coarse-grained API, in that it exposes a very small, fixed number of API calls with very generic, non-system specific parameters and responses, each of which has been tailored for public exposure. The database OTOH represents an entire programming shell, e.g. extremely fine-grained and in many cases linked directly to the underlying system as was shown in this article - additionally, the number of entrypoints is undefined. If you somehow were convinced that you've locked down every single function of your database from attack, the next day you upgrade the database to a new version and it can very well expose new functions that are again exposed.