_filter_xss_attributes should ignore attribute values for "value" and "flashvars"

Really 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.

(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.:

<embed type="application/x-shockwave-flash" src="http://d1.example.com/player.swf" flashvars="file=http://d2.example.com/video.avi" />

_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..."?

timtrinidad, yes other attributes (eg formaction, background) also need their attribute value filtered for dangerous schemes.

Related, 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

Further to this issue, it will break embedded flash video for IE

Consider the following embed code:

<object id="flashObj" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,47,0" height="390" width="595">
<param name="movie" value="http://c.brightcove.com/services/viewer/federated_f9?isVid=1"><param name="bgcolor" value="#FFFFFF">
<param name="flashVars" value="@videoPlayer=1263453612001&amp;playerID=1180743010001&amp;playerKey=AQ~~,AAABDH-R__E~,dB4S9tmhdOrgQJ-vz7N_KM-Fn5lQ8FIH&amp;domain=embed&amp;dynamicStreaming=true">
<param name="base" value="http://admin.brightcove.com">
<param name="seamlesstabbing" value="false">
<param name="allowFullScreen" value="true">
<param name="swLiveConnect" value="true">
<param name="allowScriptAccess" value="always"> 
<embed type="application/x-shockwave-flash" src="http://c.brightcove.com/services/viewer/federated_f9?isVid=1" bgcolor="#FFFFFF" flashvars="@videoPlayer=1263453612001&amp;playerID=1180743010001&amp;playerKey=AQ~~,AAABDH-R__E~,dB4S9tmhdOrgQJ-vz7N_KM-Fn5lQ8FIH&amp;domain=embed&amp;dynamicStreaming=true" base="http://admin.brightcove.com" name="flashObj" seamlesstabbing="false" allowfullscreen="true" swliveconnect="true" allowscriptaccess="always" pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" height="390" width="595">
</object>

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)

values 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.

I don't see much of an usecase in supporting flash anymore. It seems like a really dead and proprietary technology stack anyway.

Marking duplicate of #2544110: XSS attribute filtering is inconsistent and strips valid attributes (also see related issues).