Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-71102

Augment the access api to allow the removal of XSS risk against capabilities




      Lets say we have two clients A and B. For client A they have the requirement to allow course managers to do funky stuff which could be an xss, while B does not have that requirement. More often than not, for a highly security conscious client they do not want this risk, and from a technical reason there is not reason for them to have it - they only have it because unrelated other clients or the Moodle community at large want to be able to do things in a less secure / more flexible way. This is often flagged by pen tests and it an ongoing point of contention.

      So I want a way to be able to configure the roles in a way so that B's course managers can be given a capability but without introducing the xss risk along side that. Which means changing the way that data is validated / cleaned when added or edited.

      I've been mulling and refining on a few different thoughts:

      1) Have two different capabilities, eg 'courseedit' + 'courseedit-noxss' but this gets weird if one person with the first cap adds some script tag, now a person with the second cap can't edit the content anymore. So this must be something honored at the cap level and universal to the site.

      2) I'd like to have something simple like in a new admin page a list of all the capabilities with an XSS risk and just a checkbox which turns off the risk. But of course for any cap which has this turned off there must be code behind this which honors that setting. So this can't be something new across the board for any caps with an XSS risk.

      3) So we need each capability to declare in some way that the XSS risk is optional and incrementally convert them over as needed.

      So proposing:

      a) any give cap an instead of declaring RISK_XSS it could instead declare RISK_OPTIONAL_XSS

      b) with default config it's treated exactly the same way in all the role reports

      c) have an admin setting / page which lists all of the optional xss risks and you can flip them

      d) have an new access api function which lets calling code know which level of strictness to apply for a chunk of data.

      e) touch each bit of code case by case to honor that an setting. Probably starting with a small set of course manager level XSS risks which often don't need this. 







            Unassigned Unassigned
            brendanheywood Brendan Heywood
            Component watchers:
            Amaia Anabitarte, Carlos Escobedo, Ferran Recio, Ilya Tregubov, Sara Arjona (@sarjona)
            0 Vote for this issue
            3 Start watching this issue