Hi, all. I upgrade Moodle, recently. I check new security feature. I found some security problems. I fixed almost all of them. However, when I check XSS trusted users. I don't know how to fix it.
Any ideas?
TIA
Mónico
Hello,
im new here in that forum and in moodle
I have the same problem, what das XSS trustes mean?
I'm looking forward for any suggestions to fix that problem.
Greet Jürgen
im new here in that forum and in moodle
I have the same problem, what das XSS trustes mean?
I'm looking forward for any suggestions to fix that problem.
Greet Jürgen
This is not so much a 'problem' that can be 'solved', but a compromise you have to be aware of.
Some forms of rich Multimedia content, like embedding Flash applets, or bits of JavaScript, which teachers want to use to enhance their courses, use exactly the same technologies that evil people use for Cross-site scripting attacks.
If you were solely concerned with Security, you would not allow this. However, Moodle is also concerned with education, so we have to make a compromise. Historically, the compromise was that Teachers, Course Creators, and Admins were trusted, and could post complex, but potentially risky content; while students and guests were not trusted, and anything they posted had the risky stuff stripped out.
These days, with configurable roles, it is a bit more complex, because there may be other roles, or the permissions of the standard roles may have been changed. (But that is why we have a column of risk items on the right of the define/override roles screen, so when you are editing the student role, you can be aware of the consequences of what you are doing.)
If you click on the 'XSS trusted users' link in the first column of the security report. Then Moodle will compute a list of all the people who have the permissions to post potentially dangerous content somewhere in your Moodle site. And all you can to do is check that list, and make sure that all the names in that list are people you trust.
Some forms of rich Multimedia content, like embedding Flash applets, or bits of JavaScript, which teachers want to use to enhance their courses, use exactly the same technologies that evil people use for Cross-site scripting attacks.
If you were solely concerned with Security, you would not allow this. However, Moodle is also concerned with education, so we have to make a compromise. Historically, the compromise was that Teachers, Course Creators, and Admins were trusted, and could post complex, but potentially risky content; while students and guests were not trusted, and anything they posted had the risky stuff stripped out.
These days, with configurable roles, it is a bit more complex, because there may be other roles, or the permissions of the standard roles may have been changed. (But that is why we have a column of risk items on the right of the define/override roles screen, so when you are editing the student role, you can be aware of the consequences of what you are doing.)
If you click on the 'XSS trusted users' link in the first column of the security report. Then Moodle will compute a list of all the people who have the permissions to post potentially dangerous content somewhere in your Moodle site. And all you can to do is check that list, and make sure that all the names in that list are people you trust.
Tim, thanks for your explanation. 
I've added a link to this discussion from the security overview documentation.
I've added a link to this discussion from the security overview documentation.
Thank you very mutch!
Hi Tim. I appreciate your time to explain about XSS trusted users problem. Thanks.
Cheers
Mónico
Cheers
Mónico
so there is nothing we can do about it except check that those poeple on the list are the trusted user and leave it as it is?
Hi Tim,
I show about 10 people that are typical students under this XSS list. How do I remove them from this entrusted list when I haven't activated (checked the box) it from Admin-->Security-->Site Policies?
Thanks.
There is a somewhat indirect chain to get from a particular user to having a risk.
A User -> has a role assignment somewhere -> that gives them a capability -> that has a risk associated with it.
The right way to break that chain is either to un-assign the role, or edit the role definition so it no longer confers the risky capability.
Therefore, you need to track down the details of the chain. I can't remember how many clues the Security report gives you to help with this. You may find the users roles report (downloadable from the modules and plugins database) is helpful here.
A User -> has a role assignment somewhere -> that gives them a capability -> that has a risk associated with it.
The right way to break that chain is either to un-assign the role, or edit the role definition so it no longer confers the risky capability.
Therefore, you need to track down the details of the chain. I can't remember how many clues the Security report gives you to help with this. You may find the users roles report (downloadable from the modules and plugins database) is helpful here.
Hi Tim,
I have gone though the list of users generated by the XSS trusted users problem and downgraded a most of them from teachers to non editing teachers. This is as low as they can go as they need these privileges associated with this role to do their jobs. However, there are all still flagged as being at risk.
Two questions.
Simon
I have gone though the list of users generated by the XSS trusted users problem and downgraded a most of them from teachers to non editing teachers. This is as low as they can go as they need these privileges associated with this role to do their jobs. However, there are all still flagged as being at risk.
Two questions.
- Is there is specific privilege (s) that will generate this warning? The list is long and none of them seem to explicitly mention the XSS risk. If there are not too many and if they do not impact on their ability to function perhaps I can set the privilege to disallow. Typically, we do not post anything too fancy on the site.
- Once I have reduced the number of users for whom this warning is generated is there any way that I can turn off this warning? It seems to me that any site must have at least one user for whom this warning will be generated. If that is the case the warning will be always on and perhaps it looses its effectiveness.
Simon
Dear Tim,
Just following up on this thread. What if my Moodle site reports 0 XSS trusted users? Should this still be flagged as a "warning" in the system?
Thanks for clarifying (see attached image which occurs on one of my test servers running Moodle 2.8.3+ (Build: 20150219).
-Thom
Just following up on this thread. What if my Moodle site reports 0 XSS trusted users? Should this still be flagged as a "warning" in the system?
Thanks for clarifying (see attached image which occurs on one of my test servers running Moodle 2.8.3+ (Build: 20150219).
-Thom
I don't know why it is showing as a warning if there are 0 users.