4 ms·

A few recurring patterns here: - Broken API authentication mechanisms, SSO that doesn't work properly. The frequency with which they could simply register acco

A few recurring patterns here: - Broken API authentication mechanisms, SSO that doesn't work properly. The frequency with which they could simply register accounts and then make themselves some sort of admin by sending ordinary HTTP requests, without ever once needing to confirm with anyone in person, is quite astounding. - Everything being totally exposed on the internet: frontends, backends, all of it. Apparently IP firewalls are history. - Stringly typed APIs and protocols in which adding escaped control characters in various places allows bypass of critical comparison logic. - And a bit of SQL injection. Apparently only worth looking for on old web apps - progress? It feels like the ad-hoc way user accounts were added to the web platform have led to a universe of different implementations and varying exploits. Still, it'd be good to know what their failure rate was. How many companies did they attack without finding any (serious) problem?

TeMPOraL 4y ago
> And a bit of SQL injection. Apparently only worth looking for on old web apps - progress? Yes, but very minimal and disappointing. Sure, people got serious about this and today, SQL injection is hard to near-impossible to introduce using modern frameworks and practices. But we got there by learning the wrong lesson. We've treated SQL injection as its own vulnerability class. We've taught a generation of developers to Not Write SQL Statements By Hand, to Use Prepared Statements or Use ORMs. Libraries and frameworks were changed accordingly. Sanitizing, which evolved to "Web Application Firewalls", was introduced to detect and block SQL injection attempts. We've solved this as a specific case, instead of learning the general principle: never work with structured operations on structured data in their string representation form. "Stringly typed APIs" you mention are just another form of this, they're the same class of problems as SQL injection. So are XSS attacks. So are ${any other query language} injection attacks. So is your site breaking apart because of a stupid mistake or malformed user input that broke your templating engine. All of them are caused by gluing unstructured strings together and then deserializing the result. Operations like "interpolate this value in this place of structure/query" aren't string-level operations, they're structure representation level operations (e.g. DOM node replacements). If you do them in their natural representation, injection vulnerabilities cease to exist.
- 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.
- still_grokking 4y ago
  > never work with structured operations on structured data in their string representation form. Still people insist on writing their code as text strings mumbling "something something but my vim". As long as people think strings are some "universal format" this madness won't stop.
  - TeMPOraL 4y ago

TeMPOraL 4y ago

> And a bit of SQL injection. Apparently only worth looking for on old web apps - progress? Yes, but very minimal and disappointing. Sure, people got serious about this and today, SQL injection is hard to near-impossible to introduce using modern frameworks and practices. But we got there by learning the wrong lesson. We've treated SQL injection as its own vulnerability class. We've taught a generation of developers to Not Write SQL Statements By Hand, to Use Prepared Statements or Use ORMs. Libraries and frameworks were changed accordingly. Sanitizing, which evolved to "Web Application Firewalls", was introduced to detect and block SQL injection attempts. We've solved this as a specific case, instead of learning the general principle: never work with structured operations on structured data in their string representation form. "Stringly typed APIs" you mention are just another form of this, they're the same class of problems as SQL injection. So are XSS attacks. So are ${any other query language} injection attacks. So is your site breaking apart because of a stupid mistake or malformed user input that broke your templating engine. All of them are caused by gluing unstructured strings together and then deserializing the result. Operations like "interpolate this value in this place of structure/query" aren't string-level operations, they're structure representation level operations (e.g. DOM node replacements). If you do them in their natural representation, injection vulnerabilities cease to exist.

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.
still_grokking 4y ago
> never work with structured operations on structured data in their string representation form. Still people insist on writing their code as text strings mumbling "something something but my vim". As long as people think strings are some "universal format" this madness won't stop.
- TeMPOraL 4y ago