How to cause (or prevent) a massive data breach – secure coding and IDOR

Most infosec professionals are aware of the massive First Financial Corporation data breach that leaked 885 million sensitive documents in 2019. The damage was caused by a vulnerability called IDOR (Insecure Direct Object Reference) that was present in a First Financial Corporation web application. OWASP (the Open Web Application Security Project) recognizes IDOR as one of the top 10 security vulnerabilities for 2020. IDOR falls into the OWASP category known as Broken Access Control. IDOR is arguably one of the most difficult vulnerabilities to systematically detect and defend against in an enterprise codebase. Its ease of exploitation and potential high impact makes it a very high-risk vulnerability. What should developers do? Most industry experts advise them to “think like a hacker,” actively exploring possible attack vectors and implementing access control checks before manipulating resources. They also recommend manual code reviews. While these are good recommendations, they require developers to know how, when, and where to implement access control checks. And, they create a lot of additional manual work. Industry recommendations for QA are somewhat similar: think about attack vectors and make sure to write an extensive set of test cases to cover all potential scenarios. The number of necessary test cases can be immense as IDORs appear in URL parameters, form field parameters, file paths, headers, and cookies. Again, the recommended “best practice” involves a lot of additional manual work. Security officers are encouraged to arrange for manual code audits, which do not scale easily and are expensive. Commercial classic rule-based static code analyzers (SAST) should be able to help in theory, but they produce a lot of false positives and often prove more trouble than they are worth. Modern dynamic code analyzers (DAST) are based on traditional fuzzing techniques and are not suitable for IDOR. This is because traditional fuzzing seeks to break an application with the assumption that crashes indicate the presence of vulnerabilities. This is ineffective since IDOR does not typically crash an application but allows a malicious action to succeed. Our goal was to break through the manual work and provide an efficient automated detection and remediation solution that is effective against IDOR. We were inspired by recent academic advances in defining patterns of vulnerabilities from code representation graphs, the rise of graph query languages (Semmle etc.), and advances in graph neural networks. Integrating all these ideas, we started our journey to automatically find IDORs in targets ranging from applications, libraries, APIs and microservices.