Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The summary of my problem is I am using an input filter that has HTML Filter on it. I want to be able to embed flash, so I made sure that
are on my list of accepted markup. The problem came in when I started using flashvars. Flashvars are a url encoded list of variables in the format: key1=value1&key2=value2 Well some of my flash vars are URLs; however, filter_xss calls _filter_xss_split on each tag which calls _filter_xss_attributes. _filter_xss_attributes sends the value of EVERY parameter through filter_xss_bad_protocol, and filter_xss_bad_protocol starts butchering thing if the string has a colon (:) in it. Is it possible that _filter_xss_attributes can be a little more forgiving and only call filter_xss_bad_protocol on applicable properties (like src and href), or maybe filter_xss_bad_protocol can be more forgiving in checking if it starts with javascript (or other protocol) and if the value is formatted like a url. I'm not sure what the best answer is, but I think not every property has the same potential for xss attacks.
Comments
Comment #1
dddave CreditAttribution: dddave commentedReally 6.9?
The usage of flashvars is pretty common: http://drupal.org/search/apachesolr_search/using%20flashvars?filters=typ...
However for D6 there won't be any fiddling on the filter system, especially not when it concerns security.
Comment #2
timtrinidad CreditAttribution: timtrinidad commented(I reference functions in D6 below, but the behavior still seems to apply to 8.x).
It looks like this is still currently an issue that needs to be considered. The way filter_xss currently stands, if a site allows certain embed codes, no Drupal site that uses filter_xss on the user input will be able to use jwplayer (or similar flv players) to reference external files.
One example we've run into is users embedding their player and referencing a video on another one of their servers, e.g.:
_filter_xss_attributes and filter_xss_bad_protocol would match against the protocol "file=http:" and remove it.
Is there any harm in ignoring filter_xss_bad_protocol for the "value" and "flashvars" attributes? Is an XSS attack even possible with those attributes?
As a side question, is XSS possible with attributes besides "src", "href", and "on..."?
Comment #3
sunComment #4
Heine CreditAttribution: Heine commentedtimtrinidad, yes other attributes (eg formaction, background) also need their attribute value filtered for dangerous schemes.
Comment #5
Hanno CreditAttribution: Hanno commentedRelated, but focusing on the attribute itself and not the value is this issue: #1328768: attributes 'xml:lang' and 'xml:id' transform to 'lang' and 'id' in filter_xss
Comment #6
DeeLay CreditAttribution: DeeLay commentedFurther to this issue, it will break embedded flash video for IE
Consider the following embed code:
If you have that on a content type that runs through the HTML filter, the call to _filter_xss_attributes will turn the object attributes:
id="flashObj" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#vers..." height="390" width="595"
into:
id="flashObj" classid="D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#vers..." height="390" width="595"
which will obviously break the video on any browser that use the object tag instead of the embed tag.
In terms of solutions:
1. Hack core (think of the kittens)
2. Disable HTML filter (not recommended)
3. Add clsid to filter_allowed_protocols variable (not ideal)
4. Use something like inline API to have a tag in the content that gets swapped out (Involves a bit of work)
Comment #7
iStryker CreditAttribution: iStryker commentedvalues is mark as a Safe HTML attribute by https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Preventio... Rule #7. I think this should be whitelisted. I'm working on a whitelist for Drupal 8 here #952964: String stripped from title and alt attribute if contains a colon
For the other attributes, I believe you will need to create a custom module that for D8, extends the class.
Comment #8
dawehnerI don't see much of an usecase in supporting flash anymore. It seems like a really dead and proprietary technology stack anyway.
Comment #17
catchMarking duplicate of #2544110: XSS attribute filtering is inconsistent and strips valid attributes (also see related issues).