5 ms·
Millions of people's data stolen because web devs forget to check access perms
- vogon_laureate 3y ago“Configure applications to deny access by default and ensure the application performs authentication and authorization checks for every request to modify data, delete data, and access sensitive data." So why aren’t devs coding basic auth checks into every request? Is it something about the tooling? Maybe the way they structure auth and tokens? Are they worried about performance? Is it ignorance? Why would a company like Microsoft not know to wall off API requests to non-authenticated and logged-in accounts?
- eddd-ddde 3y agoAt school, EVERY SINGLE project we did, there wasn't one instance of them doing authentication for objects, just get the id and return the data. I was even more surprised were at my first job they were doing the exact same. Mind you this was production software already with hundreds of user dealing with sensitive personal data. People just don't know what they are doing. The best part was their s3 bucket with all of user's data was completely public read because "if we make it private we cant display the pdfs on the web site".
- sublinear 3y ago> Are they worried about performance? Yes. You use a gateway to protect your service from unauthorized requests slowing everything down. A cluster of reverse proxies taking the impact of a denial of service attempt is exactly what you want. You also delegate the auth to another service so that attempts to log in and determining permissions does not slow down your core functionality. Auth headers and the identifier are passed from the internet user to the auth service via the proxy and it looks up the permissions on the given identifier for that user to confirm or deny the request. The API service on the backend doesn't necessarily need to know about any of this to be secure. It just needs to be walled off from everything that's not the gateway.
- sublinear 3y agoI have a few thoughts on this. How can you check a user's permissions without "user input"? That part is poorly written. Also, they present a query parameter containing an identifier in the URL as an example of an IDOR, but really everything on the web ultimately does this. This is not the vulnerability. It's that there aren't additional HTTP auth headers or auth parameters in the URL. I also question whether this web service was meant to be internet facing or an internal one. If so that's misuse of the software by people who aren't the web devs. It's common for auth to be handled by another service where the gateway in front of this is the security layer. If that gateway was misconfigured or just completely missing, that's the middleware team's fault. Also, > To help prevent data breaches due to IDOR bugs, the agencies suggest that vendors and web app developers implement secure-by-design principles at each stage of the software development process. Automated code analysis tools can also check for this kind of buggy code so that weaknesses can be fixed before stuff reaches production. This is such a piss poor answer to the actual problem here. Not everything boils down to code. This sounds like a lack of coordination due to mismanagement of a project. Blaming devs for this is a really bad look.