Can cause arbitrary SWF files to execute in the browser

Bug #1190788 reported by Aaron Wells on 2013-06-13
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Robert Lyon
Robert Lyon

Bug Description

Subject: Found Critical XSS Vulnerability on Your System


I found a really critical XSS (Cross Site Scripting) vulnerability on The vulnerability works as follows:

1) I opened the demo account on Mahara and logged in the admin account by using the link "".

2) Then I clicked admin avatar picture to go to user details page.

3) After that I clicked "edit this page" button.

4) Then I dragged "File(s) to Download image to About me section of the page.
5) I created a .swf file that contains ActionScript codes. I also attached that file to this email.

6) I uploaded that XSS.swf file.

7) When I open XSS.swf file on browser, I saw the alert message showing SOLVER (my nickname)

8) Example script:

By using this XSS vulnerability, an attacker can steal Mahara users' cookies, and their accounts. Furthermore, the attacker can redirect users to a harmful website that contains trojan horse, malware or a JavaScript downloader to get full access on the users' computers. This issue can get bigger by using a XSS Worm, and influence even some other Mahara product users.

As a simple solution, the content of the file that is about to be uploaded should be checked against harmful scripts and codes.

CVE References

Aaron Wells (u-aaronw) wrote :
information type: Public → Private Security
Aaron Wells (u-aaronw) wrote :

Flash files are only able to access the content of the page they're loaded in, if they are hosted at the same domain as the page. For this reason, most sites that host user-uploaded Flash files (including launchpad, and, host them at a different domain than the webpage itself.

Since Mahara is a hosted app, well, it's not really feasible to ask all of the users on shared hosting to set that up. Although we could provide support for it, for larger sites. I suggest one or more of the following courses of action:

1. Add the HTTP header "content-disposition:attachment" to all flash files that are viewed as attachments. (i.e., you put a flash file in a "Files to download" block.) Currently, they're displayed as "content-disposition:inline", which makes them be viewed inside the browser.

2. For that matter, it would probably be better if all "files for download" had "content-disposition:attachment". This will make the browser download them rather than try to display them in the browser, and isn't that what a user expects from "files to download"?

3. Make sure that when we embed SWF files in the internalmedia block, we use "allowscriptaccess=never" and "allownetworking=never" in the embed params (and maybe check for other suitable limitations in )

4. Add support for user-uploaded files to be served from a different domain. This would be in the form of something like $cfg->uploadwwwroot, which would default to $cfg->wwwroot if it's not supplied. $cfg->uploadwwwroot should serve exactly the same content as $cfg->wwwroot, but its purpose would be to be used in place of $cfg->wwwroot whenever we want a URL for serving user-supplied files.

Aaron Wells (u-aaronw) on 2013-08-20
Changed in mahara:
milestone: 1.8.0rc1 → 1.7.3
Son Nguyen (ngson2000) on 2013-10-03
Changed in mahara:
milestone: 1.7.3 → none
Robert Lyon (robertl-9) wrote :

I agree about having the artefact/file/download.php file have forcedownload on by default (and not overridable) - it would be a matter of checking if that causes problems with things that are using that url but should not be.

I notice there is this page talking about how to get around the 'allowscriptaccess' variable: so for embedding files it might not be as simple as setting the embed html param allowscriptaccess=never.

Robert Lyon (robertl-9) on 2014-11-10
Changed in mahara:
assignee: Aaron Wells (u-aaronw) → Robert Lyon (robertl-9)
milestone: none → 15.04.0
Hugh Davenport (hugh-davenport) wrote :

wrong bug

Robert Lyon (robertl-9) wrote :

I've put in a patch and from my initial tests it seems to work as expected.

For full testing one will need to test against all the different types of internalmedia one can embed as well as making sure other artefacts one can embed/download also still work as expected.

Aaron Wells (u-aaronw) wrote :

The patch 4292 looks good. Ready to include in the next release.

Aaron Wells (u-aaronw) wrote :

Reviewed patch 4292 again (after updates). Ready to merge.

Robert Lyon (robertl-9) on 2015-04-16
information type: Private Security → Public Security
Robert Lyon (robertl-9) on 2015-04-17
Changed in mahara:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers