Note: Post archived from previous website - some links, images, and/or post formatting may not display correctly. Contact us using the contact page below if you have any questions about post contents.
Developers must never rely on client-side access control checks.1
With this simple statement, OWASP are putting a very big question mark over the head of any document editor that performs access controls in browser. So what is the big deal, and are client-side access controls really that bad? In this quick post, we’ll find out.
Distributing Data
What happens when a government employee views your tax records, the bank assesses your mortgage application, or your lawyers share documents regarding your case with each other? Depending on the application they are using, it turns out the first operation may well be for the server to make copies of the document for every editor or viewer, before sending the copies to each user’s device. In case it isn’t immediately obvious, this distributive flavour of document editing is extremely concerning for a number of reasons.
1. Lack of Server-Side Enforcement
As mentioned above, one of the core principles of OWASP regulations is enforcing security measures at the server-side. However, when full documents files are sent to the browser for editing, the server loses control over the data. This immediately undermines any ability to enforce security policy.
2. Vulnerabilities
If data files are sent with code to execute policy in the browser, then a malicious script, acting as a “browser” can simply download the document data and discard the policy logic. This exposes the data to potential cyber-attacks and data breaches. OWASP regulation 4.1.1 states this very simply as, “Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed”2, since “client-side logic is often easy to bypass”3. Whilst organisations rightly have training about whether secure USB sticks should or shouldn’t be used with company laptops, nobody is talking about the 3rd party access freely given by company servers to anything pretending to be a browser.
3. Duplicates
When dealing with sensitive (or arguably any) data, the last thing we should think about doing is photocopying it. TOP SECRET – EYES ONLY is a phrase we are familiar with from the world of spies and espionage, yet so often overlooked in the online world. We naively assume that this couldn’t be an issue with our document editor, yet with many services this is precisely what happens when we start a viewing session. Regulation 4.1.5 states developers should “Verify that access controls fail securely including when an exception occurs.” It’s impossible to imagine how any developer can possibly verify such a fail-safe system however when the one of the primary functions of a data centre is duplicating files before distribution to any user.
4. Data Sovereignty and Compliance
Many industries are bound by strict compliance requirements and regulations. Whilst the question of where large data centres are based is beginning to be understood and grappled with, many are overlooking the question of data stored in the cache of users’ browser. Call it what you want, but if this is the way your document editor functions, you are operating a series of international data centres. With just a few clicks and the magic password ‘F12’, the browser will show the cached documents straight away.
Conclusion:
Governments or organisations that handle financial records, medical information, intellectual property, or indeed any other data, need to carefully assess whether their document editor is operating in a manner consistent with their own regulations and OWASP guidelines. The implications of sending full copies of documents to every browser are many, and extremely questionable. Genuine server-side policy enforcement is the only way to maintain real security. Collabora Online sends a pixel based view of a document to the end user, whilst the full document data remains safely under your control.
Keep your data secure with Collabora Online.
Collabora Online – Safe, Powerful, Flexible.
1 https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
2 https://raw.githubusercontent.com/OWASP/ASVS/v4.0.3/4.0/OWASP%20Application%20Security%20Verification%20Standard%204.0.3-en.pdf
V4.1 General Access Control Design
4.1.1 Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.
4.1.2 Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.
4.1.3 Verify that the principle of least privilege exists – users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. (C7)
4.1.4 [DELETED, DUPLICATE OF 4.1.3]
4.1.5 Verify that access controls fail securely including when an exception occurs.
3 https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
