Would Insecure Direct References and SQL Injection be solved by using Row-Level Security and Per-User Connection Strings?

Question

Regarding the following OWASP Vulnerabilities:

• Insecure Direct Object References. By that I mean letting someone see /account/123/not-theirs (this could be the wrong reference I'm using above).

• SQL Injection.

Can these be solved by using a database that supports Row Level Security and by creating real user accounts in the database for each user and having them login to the database as themselves (via the web server)?

Any issues in this approach to be aware of (other than it killing connection pooling)?

EDIT:

One obviously needs some sort of record access control. How is moving record access control from the web layer to the database layer worse, when it's more centralized? (Databases tend to live longer than applications, and databases sometimes have more than one application.)

User authentication (storage) happens in a different system.

Users are not be superusers and would have the minimum required privileges (by that I mean they can't run command shells in SQL or other silliness).

Users would not have direct db access, only access through a web application.

Would use hierarchical roles.

Would still use parameterized queries, however not all queries are parameterizable, developers make mistakes, and systems like Wordpress have shown that plugins can get you.

Answer 1

Not effectively, no. You're always going to have cases where row-level security can't properly emulate the business processes. You'd also need to have a lot of "general purpose" accounts for things like user signup. The whole thing would be convoluted, difficult to maintain, and largely ineffective.

Keep in mind, also, that SQL injection potentially does not only affect the data, but also the database. Special commands (like xp_cmdshell in TSQL, debug segfault in Redis) have all sorts of secondary impacts outside that of row data.

Regardless, SQL injection is largely a solved problem, so it's really not worth creating inferior solutions that are much more complex and costly.

Answer 2

No, because SQL Injection and Insecure Direct Object References includes the case of 'ability to run SQL that the user has access to but the application was designed to not allow'. Your method will limit the ability to get at stuff outside their permissions, but in most cases that includes things that aren't intended to be open, as well as system information which is usually accessible by design.

What can help is the use of stored procedures instead of application-side code, but that's not common because it makes the overall application more static and fragile.