Straight forward XSS and CSRF issues in Concrete CMS when adding a calendar event. The XSS was closed as a non-issue because the application provides users control over the HTML, including adding scripts. The CSRF aspect though is just another illustration as to how easy of a vulnerability it is to creep up when you don’t design the code around centralized security.

This was simply a case of the CSRF token not being validated at all, the fix commit shows how simple the issue was. It was just missing a call to $this->validateAction(). In my opinion where there is one of these sorts of issues, there are bound to be more.

Websockets have always been a little bit special when it comes to security considerations, they are a newer technology and the security concerns are often not well understood. Websocket Hijacking tends to occur because websocket connections are not protected by the usual Same-Origin-Policy (SOP) that more traditional resources would be, so malicious websites can by default connect to a foreign websocket using a victims cookies (assuming SameSite is not at play).

What happened in this case is that the author discovered, first that the websocket the application used did not properly validate the origin of the connection, and would broadcast replies to userinitiated events to all of the user’s connections. One event in-partical, the change password event would leak the session id in the response, making it visible to any malicious website connected at the same time.

The first issue was that the endpoint for changing a user’s password took as an argument a user id which was not validated against the currently logged in user allowing any user to change the password to any other account providing they knew the users unique id. These ID values were thankfully not easily guessed.

The second issue was an IDOR on the checkout/api/user/ endpoint which would would take as one of its arguments an email address, and the response would include the associated user-id. Combining these two issues provide the ability to access any user’s accounts, any all information associated with them such as credit card and billing information.

Unfortunately, the program did not pay out for this issue as authenticated testing, and testing of the signup pages were considered out-of-scope (terrible policy).

An attacker with write access to the repository could bypass branch protection rules that require all pull requests undergo a code-review before being merged. The issue is just a logic issue rooted in the fact that firstly, anyone with write access can create an unprotected branch and define GitHub Actions for it, and secondly that a GitHub action can perform code reviews (though restrictions can be added on who the approved reviewers are). So by creating a branch with an action that will use the GITHUB_TOKEN to add a review to a pending PR an attacker could bypass some forms of branch protection rules.

It is worth pointing out that this does write write access to the repository already, but the purpose of branch protection rules is precisely that situation, to mitigate the damage a compromised but authorized user could do.

The fundamental issue is as basic as it gets, one of the first attacks many budding hackers learn is ' or 1=1 in a login page. Well this was a SQLi in the username of a login form, taken a little further by enabling xp_cmdshell and gaining code execution. While its not an unheard of attack, it is uncommon to see SQL injection be so directly leveraged for RCE these days.