Impact
An attacker could leverage the cross-site scripting vulnerability to conduct an attack against a user and gain access to sensitive information such as their cookie. The attacker could take over the accounts of other users and execute actions in their name.
The improper access control vulnerability could be leveraged by a malicious user to access sensitive project related documents and upload content to a project that they should not have access to.
Technical Analysis
Cross Site Scripting
In order to exploit this vulnerability, we logged in as a user on the website where the application was hosted. This user had access to the User Management module. Then, we clicked on the Users tab in the menu bar and edited another user’s details. We changed the last name of this user to an XSS payload:
<img src="" onerror=" alert(document.cookie)"/>
This is just a simple payload to demonstrate our ability to execute arbitrary JavaScript code. The payload will open a pop-up window that displays the cookie of the user being attacked.
To trigger the payload, we clicked on that user’s details page and as expected, a pop-up appeared displaying a cookie:
Improper Access Control
To demonstrate this vulnerability, we first logged in as a user with access to the User Management module. We chose one of the other users in the Users tab and edited their permissions. We removed their permission to access projects by unchecking the checkbox named “Access to all projects”. Then, we clicked on one of the projects in the Projects tab and copied its URL. We saved this URL for later.
Finally, we logged in as the user whose access we removed in the first step. We navigated to the project URL directly by pasting it in the address bar and realized that we were still able to interact with the project. For example, we were able to upload and download project attachments even though our account did not have the permissions to do so.
Mitigation
Cross Site Scripting (XSS)
Encode User input
To protect the application against cross site scripting, all user input should be encoded when returned to the client. The type of encoding used depends on the context where the input is returned. OWASP has an article on XSS prevention.
Allow only specific input characters
User input fields should only accept characters that are known to be good. This is known as an allowlist approach: only the input values that are explicitly allowed by the server are accepted, and the other ones are rejected. This will prevent attackers from writing code in input fields, which will make it harder for them to exploit cross site scripting bugs. Note that this must be done on the server side, because attackers can bypass all client-side restrictions.
Improper Access Control
Validate Authorization
Access should be properly validated before returning information to the client. The server should make sure that user has the right to view the requested resource before serving it. OWASP also has a cheat sheet on access control.
Conclusion
Vulnerabilities like XSS and Improper Access Control are well known but still very prevalent. However, by using well-known security solutions and following secure development practices, you can avoid vulnerabilities like these and keep your application secure.
These vulnerabilities were assigned CVE-2019-20483 and CVE-2019-20484 respectively and have been disclosed to the vendor following our responsible disclosure process.
If you want to know about another vulnerability affecting Vera, read our previous blog post about a Remote Code Execution vulnerability in version 4.9.1.26180.
Hat tip to Francis Labelle for his assistance in the writing of this blog post.
