search

openwebwork / webwork2

Course management front end for WeBWorK
http://webwork.maa.org/wiki/Main_Page
Other
141 stars 164 forks source link

Cross site scripting vulnerability #2336

Open drgrice1 opened 5 months ago

drgrice1 commented 5 months ago

This was reported in https://webwork.maa.org/moodle/mod/forum/discuss.php?d=4295 (4 years ago), and I don't know why an issue was not made at that time. The issue is with how we use the status_message URL parameter to pass html when redirects occur. An example of this in action was given in that forum post. Here is a simpler example that work now:

https://your.server.domain/webwork2/courseID?status_message=<script>console.log('hello')</script>

The console.log does get executed.

The approach of passing HTML in a URL parameter, and then injecting that into the DOM without begin properly sanitized is a clear vulnerability. There is a note in the forum post about using HTML::Scrubber to sanitize input, but I do not believe this URL parameter has ever been put through any such scrutiny. Furthermore, I don't think that even HTML::Scrubber would catch the instance noted in that post. That is (modified a bit):

https://your.server.com/webwork2/courseID?status_message=<audio%20src=x%20onerror=alert('hello')>

The alert in that is executed also. HTML::Scrubber might catch the first example with a script tag, but wouldn't catch the onerror attribute.

The good news is that with #2332 there is a safe mechanism that could be implemented to pass such messages securely via the session without using a URL parameter.

I am noting this issue mainly for myself to work on.

drgrice1 commented 5 months ago

I should note that this does not affect the internal status_message usage that is not passed through a URL parameter. So addmessage and methods that go through that (addbadmessage and addgoodmessage) are not a problem when they only use internal content. It is passing the status_message URL parameter into those methods that is the problem.