Les Bell

Welcome to today's daily briefing on security news relevant to our CISSP (and other) courses. Links within stories may lead to further details in the course notes of some of our courses, and will only be accessible if you are enrolled in the corresponding course - this is a shallow ploy to encourage ongoing study. However, each item ends with a link to the original source.

News Stories

ACSC, CISA, NSA Joint Advisory on Web Application Access Control Abuse

The Australian Cyber Security Centre, US Cybersecurity & Infrastructure Security Agency and the US National Security Agency have released a joint cybersecurity advisory to address the risks posed by insecure direct object reference (IDOR) vulnerabilities. The advisory is aimed primarily at designers, architects and developers of web applications.

IDOR vulnerabilities are often easy to spot, which makes them attractive to threat actors. When you see something like this in the URL bar of your browser:

https://www.bigcorp.com/account/statement?acctid=320345465423

then you are looking at a likely IDOR. The object in question is your account with BigCorp, and the direct reference is the account ID or number appearing as a URL argument. The question that should immediately pop into the mind of a security-aware observer is: if the acctid was set to a different number, would the page display someone else's account statement? If it would, then that is an insecure direct object reference.

Of course, insecure direct references need not appear in the URL - they could equally well be hidden or visible form fields

The fact is, there is no need for this direct reference at all. In most cases, you have but one account with BigCorp, and 'you' are identified by a session token generated when you logged in and passed between server and browser in the form of a secure cookie (if you didn't need to log in, then the IDOR is not your biggest problem!). Since the server knows who you are, it also knows your account number, and there is no need for the client to pass it back, whether in the HTTP header of a POST request or in the URL of a GET request.

If you do have multiple accounts - for example, with a bank where the customer has a mix of cheque, savings, credit card and other accounts - then they can be referenced indirectly, for example by an index into an array of account references maintained within the server-side code, or even better, via a mapping which uses a cryptographically strong random value.

In practice, the presence of IDOR vulnerabilities signals deeper problems within a web application such as missing function level access control or even broken authentication and session management. The latter is near-inexcusable; every web developer should be familiar with good authentication and session management techniques, but in practice even that is not strictly necessary since many projects are based on platforms (such as WordPress, Joomla, etc.) and frameworks that provide the required code.

In my courses, I teach that web development projects should start with the selection of a suitable access control model; for many web applications this will be role-based access control (RBAC). And again, many platforms provide the required functionality in the form of flexibly-defined permissions which can be associated with roles and then allocated to users. Attendees at our CISSP Fast Track Review course have access to a basic relational database schema for RBAC and PHP code which will perform an access check on every user request, only allowing the code to run if that user occupies a role with the required permissions.

The joint advisory delves into more detail for developers, with a useful list of suggested mitigations:

• Implement secure-by-design and -by-default principles and practice in development methodologies
• Follow secure coding practices
• Test code to identify vulnerabilities
• Coduct role-based training for developers
• Exercise due diligence when selecting third-party platforms, frameworks or libraries
• Establish a vulnerability disclosure program

End-user organizations are offered a similar list:

• Exercise due diligence when selecting web applications
• Apply software patches for these applications as soon as possible
• Configure web applications to log and generate alerts from tampering attempts
• Create, maintain and exercise a basic cyber incident response plan and related crisis communications plan
• Conduct regular, proactive penetration testing
• Use dynamic application security testing tools and vulnerability scanners
• Use a web application firewall to filter, monitor and block malicious traffic
• Use a data loss prevention tool
• Immediately report detected vulnerabilities to the vendor or developer
• Consider establishing a vulnerability disclosure program
  

For each of these points, the advisory provides additional explanatory detail.

CISA, Preventing Web Application Access Control Abuse, cybersecurity advisory, 27 July 2023. Available online at https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-208a.

These news brief blog articles are collected at https://www.lesbell.com.au/blog/index.php?courseid=1. If you would prefer an RSS feed for your reader, the feed can be found at https://www.lesbell.com.au/rss/file.php/1/dd977d83ae51998b0b79799c822ac0a1/blog/user/3/rss.xml.

Copyright to linked articles is held by their individual authors or publishers. Our commentary is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License and is labeled TLP:CLEAR.