3 ms·
Absolutely agreed. This is something I bang on about a lot in the last few years. So many exploit classes go away entirely if you write an app using standard O
by mike_hearn 4y ago
Absolutely agreed.
This is something I bang on about a lot in the last few years. So many exploit classes go away entirely if you write an app using standard OOP desktop UI frameworks and tooling. Take a toolkit like Jetpack Compose, JavaFX, WPF and combine it with gRPC or, alternatively, log in directly to the database (as your own user). Now it becomes nigh on impossible to mount injection attacks.
In particular, if your ACL logic is expressed in the database itself (row level security, security-definer views, stored procedures etc), and every user of the system has a database user, then SQL injection goes away entirely by design because you're now designing on the assumption that the user can run arbitrary SQL anyway. If something goes wrong with the containment it's a flaw in the database or your declarative ACLs, and can be patched in one place (+if it's a db bug you can hold the vendor responsible if you license a commercial rdbms).
Now, this type of design can't solve all the problems that cropped up in their explorations, and it adds a few new ones - you have to be careful to configure your database correctly, obviously, and you might become more vulnerable to DoS attacks, although for web apps like dealer consoles DoS is probably not your primary concern. But you will at least have one place to declaratively assert what data everyone should be able to see, and authorization is enforced by centralized logic. Some of the problems found in these websites seem to be caused by devs losing track of what bits of code are meant to enforce security. There are auth tokens everywhere but nothing is being enforced properly. Two tier direct-to-db designs would fix that.
Still, the worst vulns here all seem to be related to creation of new accounts for semi-private systems and the onboarding process for how to assign roles to them. Most auth systems consider account creation and role assignment to be out of scope, which encourages/forces everyone to roll their own account system on top of the web. The results speak for themselves.