Is there something like "SQL Firewall"?

Question

SQL

Good afternoon!
Imagine a typical web application with a database. People log in, do something through the web interface, this is reflected in the database. There is a question of safety. Protecting a web muzzle is difficult. Here we have a hundred thousand trillion threats, from SQL Injection, XSS holes in Apache and backdoors in the webmord code. But if the database is on a separate machine, it is already easier to protect it (and the web server is to hell with it, we have secrets in the database).
There is an obvious idea, between the "dangerous" web server (which can never be 100% protected), and the database to put a "layer", a kind of filter, a firewall. Which could do different things, for example:
1. Login verification is allowed (SELECT COUNT(1) FROM users WHERE username='vasya' .... ), access to the users table is allowed for this in the database, but the filter blocks, say, SELECT * from it. That is, even by hacking a website, you cannot steal the entire user base.
2. Protection against SQL Injection. Typical queries are specified in the filter settings, and if you manage to slip a username with SQL special characters and a "pervert" query into the same login check operation, such a query will not be in the allowed list, and the filter will not let it through.
3. Protection from XSS, etc. - for all fields, you can prescribe their syntax (usernames - "[a-z0-9] *"), and it will not be possible to insert a "crooked" value into the database, which would then be "badly" displayed in the browser.
4. Counters. For the same login operation, the web application can pass the "context" to the filter (for example, the IP address from which the request came), and the filter can, for example, block login attempts if there were more than 10 login attempts from one address with different names in an hour.
5. Filtering results. For example, it is impossible in principle for an application to receive a response from a database with more than one row from the users table. Or get rows with different userid values ​​from the payments table (the user Vasya never needs to see Petya's payments).
6. The integrity of the base balance. For example, an INSERT into the order table of a web store for a purchase of $100 will be executed only if $100 was successfully withdrawn from the buyer's balance just in the same session. If there was no magic way to update the balance table, and the application is trying to make a purchase, then fuck you and turn on the sirens.
In principle, all this logic can be messed up in the application itself, but there is no guarantee that the application uses it everywhere, and does not work "bypassing" anywhere. And if the webserver is hacked (and this is likely, because it looks at the Web) - then they can simply not work there as an application, but as a regular client like mysql. In addition, it is convenient to see all the security and "steer" in one place.
I think it's an interesting and useful idea. I'm wondering - is there already something like that (it must be, "everything has already been stolen for us") or do I have to write it myself? Only dubious greensql.com was found (maybe, by the way, someone used it, are there any reviews?)

Answer 1

I'm wondering if there is already something like this

This class of solutions is called Database Firewalls.
Examples: 1 , 2

Answer 2

There is also an option to save all the necessary queries in stored procedures, and allow only their use.

Answer 3

Look at NASXI for more.

Answer 4

Take a look at GreenSQL
www.greensql.com