Trusted moddata downloads in database fields
Recentrly I've created a "multimedia file" database field out of "file" field which enables its users to upload multimedia files and display them via multimedia filter plugin (CONTRIB-1426). Everything worked OK before I tested the field on Flash Player 10: the flash file isn't loaded into field. After delving inside file.php from where files are loaded, I realized that database moddata files are set to "force_download". Probably, Flash Player 9 and older work with it OK, but FP10 does not.
A solution might be to create data_is_moddata_trusted function in /mod/data/lib.php which returns "true" and enables inline loading of database data files, but this would cause inline loading of files from "file" field too, which is not acceptable as I think.
A workaround for this is to make data_is_moddata_trusted function to check what field type corresponds to the file being loaded. This can be done by adding a field name into the path to the file: for example, /moodledata/3/moddata/data/1/multimedia/5/19/somefile.swf instead of /moodledata/3/moddata/data/1/5/19/somefile.swf. data_is_moddata_trusted should then parse file.php arguments looking for the file type, check for "xxx_field_moddata_trusted" function in /field/xxx/field.class.php and return its result (which will be true) if it exists, ot "false" if not. So multimedia field will be trusted to inline loading of files, and file field will be not.
I've made such changes on our server, but I'm not sure if it's a good solution. I'm looking forward to hear any comments and suggestions, as multimedia field is already in contrib CVS
A solution might be to create data_is_moddata_trusted function in /mod/data/lib.php which returns "true" and enables inline loading of database data files, but this would cause inline loading of files from "file" field too, which is not acceptable as I think.
A workaround for this is to make data_is_moddata_trusted function to check what field type corresponds to the file being loaded. This can be done by adding a field name into the path to the file: for example, /moodledata/3/moddata/data/1/multimedia/5/19/somefile.swf instead of /moodledata/3/moddata/data/1/5/19/somefile.swf. data_is_moddata_trusted should then parse file.php arguments looking for the file type, check for "xxx_field_moddata_trusted" function in /field/xxx/field.class.php and return its result (which will be true) if it exists, ot "false" if not. So multimedia field will be trusted to inline loading of files, and file field will be not.
I've made such changes on our server, but I'm not sure if it's a good solution. I'm looking forward to hear any comments and suggestions, as multimedia field is already in contrib CVS
Re: Trusted moddata downloads in database fields
Oh! The reason for forcing of downloads is protecting against XSS attacks, you must NOT allow serving of files uploaded by students without this protection!
I did not know FP10 finally started respecting http headers, if that is true it would be a great news Ggoing to test it today...
Petr
I did not know FP10 finally started respecting http headers, if that is true it would be a great news
Petr
Re: Trusted moddata downloads in database fields
Yes, I understand that allowing user-submitted flash content to be shown is a potential XSS risk, but what about other multimedia content types? And talking about multimedia filter plugin - it embeds SFW files with allowscriptaccess:"never" parameter which actually blocks any flash-to-browser interaction, including XSS attacks. This was discussed somewhere here before...
The main problem here is that Database activity module IS designed to serve user-uploaded content. Of course there is a difference between downloading and embedding, but considering the risks we should also expand functionality after all...
What I'm looking for is a way to put responsibility for disabling forced downloading on a Database plugin writer (such as me) rather than enabling it for all fields of module. If it would be a way I described before, no other fields except my own would be affected by this change - default behaviour would still be forcing downloads. And the plugin itself could just block uploading SWF files, for example, if activity creator would set it to behave like that.
The main problem here is that Database activity module IS designed to serve user-uploaded content. Of course there is a difference between downloading and embedding, but considering the risks we should also expand functionality after all...
What I'm looking for is a way to put responsibility for disabling forced downloading on a Database plugin writer (such as me) rather than enabling it for all fields of module. If it would be a way I described before, no other fields except my own would be affected by this change - default behaviour would still be forcing downloads. And the plugin itself could just block uploading SWF files, for example, if activity creator would set it to behave like that.
Re: Trusted moddata downloads in database fields
This is not just SWF issues, Internet Exlorer by default ignores extensions and mimetypes and tries to guess what is inside and executes it. If you remove the forced download just for SWF, anybody may upload a SWF file with html+javascript inside it.
In any case the flash runtime is very buggy and people are using horribly outdated runtimes. I would personally not trust any attributes such as the allowscriptaccess completely. Flash was not designed with security in mind
Petr
In any case the flash runtime is very buggy and people are using horribly outdated runtimes. I would personally not trust any attributes such as the allowscriptaccess completely. Flash was not designed with security in mind
Petr
Re: Trusted moddata downloads in database fields
After a bit of searching (http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_02.html) and actual testing I can confirm the execution of student uploaded flash files (secured with our forced download) is finally prevented - this is a great news because it actually makes Moodle much, much more secure!
Re: Trusted moddata downloads in database fields
Well, actually multimedia filter embeds SWF files using UFO, so browser does NOT actually know what's being loaded - be it common SWF or renamed HTML with a XSS. File is loaded only inside Flash Player - and definetely it won't try to show user a HTML file instead of SWF So IE has nothing to do with this issue and SWF. On the other hand, if it behaves like you've described above, then Picture field can not be trusted because images are loaded and rendered by browser itself! Seems like a bit of double standards problem ;)
I'd like to explain it once more to make it clear: I propose only a way for Database plugins (that is - individual fields) to make a choice for themself, whether to enable forced downloads from moddata directory (which is default), or not. Currently if there's any other field which depends on embedding user-uploaded files (not only multimedia ones!), they are all reduced to File field because of forced download. It breaks consistency of Database activity and deteriorates usability, as I think.
I'd like to explain it once more to make it clear: I propose only a way for Database plugins (that is - individual fields) to make a choice for themself, whether to enable forced downloads from moddata directory (which is default), or not. Currently if there's any other field which depends on embedding user-uploaded files (not only multimedia ones!), they are all reduced to File field because of forced download. It breaks consistency of Database activity and deteriorates usability, as I think.
Re: Trusted moddata downloads in database fields
Hi Vlas, I'm testing your great plugin in my site. Could I see the changes you made in your server to the data_is_moddata_trusted function? I really need a workaround for Flash Player 10.
thanks in advance
Mofi
thanks in advance
Mofi
Re: Trusted moddata downloads in database fields
Archive contain patch to mod/data/lib.php and latest version of multimedia field