On July 27, 2023, the Cybersecurity & Infrastructure Security Agency (CISA) released a joint advisory with the Australian Signals Directorate’s Australian Cyber Security Centre (ACSC) and U.S. National Security Agency (NSA). “Preventing Web Application Control Abuse” (the Advisory) provides recommendations for designers and developers to help protect against insecure direct object reference (IDOR) vulnerabilities.
If you’re a developer, here’s the tl;dr (too long; didn’t read) for CISA’s Guidance on “Preventing Web Application Control Abuse.”
CISA’s High-Level Recommendations for Vendors, Designers, and Developers
The Advisory breaks recommendations down into three audience categories. For vendors, designers, and developers, the document’s first directive is to implement secure-by-design-and-default principles.
The three primary CISA directives boil down to the following:
- Use automated code review tools
- Map all indirect references to prevent exposing information
- Do research before selecting third-party libraries or frameworks, and update dependencies regularly
IDOR Vulnerabilities and Application Threats
At a technical level, IDOR vulnerabilities occur when an application or API leaves the object identifier exposed, passed externally, or easily guessed while failing to check the user’s authenticity or authorization properly. IDOR vulnerabilities provide users access to data that they shouldn’t be able to access, essentially unauthorized access with valid credentials.
The four types of IDOR vulnerability are:
- Horizontal: unauthorized access to data at the same privilege level
- Vertical: unauthorized access to data that requires a higher privilege level
- Object-level: unauthorized ability to modify or delete an object
- Function-level: unauthorized access to a function or action
Once malicious actors have this access, they can engage in:
- Body manipulation: modifying the HTML form field data in a POST request’s body to impact targeted records
- URL tampering: modifying identifiers in URLs to impact targeted records
- Cookie ID manipulation: modifying a cookie identifier to a different user’s identifier (like admin user) to access the account
- HTTP/JSON request tampering: intercepting and altering arbitrary portions of legitimate requests with a web proxy
Recommended Mitigations
The two top-tier recommendations for vendors and developers are:
- Implement and inject secure-by-design-and-default principles into the software development life cycle (SDLC)
- Establish a vulnerability disclosure program
However, within the secure-by-design-and-default recommendation, the Advisory further outlines six best practices.
Conduct code reviews with automated code analysis tools
CISA recommends that developers use automated code analysis tools when reviewing code to look for backdoors, malicious content, or logic flaws.
Follow secure coding best practices
Referencing the Secure Software Development Framework (SSDF), CISA aligns this recommendation to Producce Well-Secured Software (PW) 5.1. To help identify the best practices for minimizing vulnerabilities during source code creation, CISA provides additional suggestions.
Use indirect reference maps
Review that URLs don’t expose IDs, names, and keys, and replace any idenfiers with cryptographically strong, random values.
Deny access by default
Configure applications so that their default is to deny access, ensuring that they perform authentication and authorization checks. Further, CISA suggests that applications:
- Normalize requests
- Implement syntactic and logical validation checks
- Use CAPTCHA where feasible
- Use memory-safe programming languages
Test code according to PW 8.2
Identify vulnerabilities and verify compliance by using your tracking system to record and triage all discovered issues and recommended remediations.
CISA suggests the following:
- Using automated testing tools
- Fuzz testing tools
- Penetration testing
- Dynamic application security testing (DAST)
Conduct role-based training
Personnel responsible for secure software development should be trained according to SSDF Prepare the Organization (PO) 2.2, including periodic reviews to ensure people know what to do.
Engage in due diligence
When incorporating third-party libraries or frameworks into your application, you should:
- Review and evaluate all components
- Verify integrity through hash or signature verification
- Review any available Software Bill of Materials (SBOM)
- Identify and catalog dependencies
- Update all third-party frameworks and dependencies
- Use tools to identify third-party code vulnerabilities when possible
Qwiet AI: Automation to Secure Code And Prevent Access Control Abuse
A primary throughline in the CISA Advisory is that developers don’t have to – and, in fact, shouldn’t – “go it alone.” Manual code reviews are time-consuming and prone to human error, especially as source code becomes increasingly complex. As you integrate more third-party libraries and frameworks into your source code, you could be integrating unknown or known risks.
You can integrate Qwiet AI into your existing CI/CD pipelines, ticketing systems, and development tools, enabling you to implement CISA’s recommendations without slowing down your processes. Further, Qwiet AI’s preZero platform gives you visibility into all third-party libraries and frameworks while focusing only on those vulnerabilities that pose an actual threat to your application. By focusing on reachability, our AI/ML considers the context of a vulnerability within your source code, giving you a way to prioritize your remediation activities. With preZero’s combination of known vulnerabilities, heuristic detections, and guided AI, developers spend less time hunting down false positives or upgrades that could be completed later for faster time to market.
Take our preZero platform for a free spin to see how Qwiet AI can help you prevent access control abuse.