flashvars are not escaped correctly when embedding on Internet Explorer

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a test swf that outputs variables passed through flashvars
2. Embed the swf passing a flashvars variable that contains characters such
as ", <, >, &, =
3. Open it with Internet Explorer

What is the expected output? What do you see instead?

The output of the swf shows that the flashvars that reach the swf are not
the same that were passed to swfobject in the embed.

What version of the product are you using? On what operating system?

Internet Explorer 7/8
Swfobject 2.2

Please provide any additional information below.

I'm using encodeURIComponent() on my flashvars to work around this problem.

Firefox and Safari seems to be handling the malformed flashvars even though
the flashvars are not being escaped correctly, but I haven't tested those
cases throughly.

Original issue reported on code.google.com by malterisio777 on 13 Nov 2009 at 4:21

• Merged into: #66

[GoogleCodeExporter]

This has already been covered in previous reports.

At this stage, we are not looking at including any code modifications which 
encode or 
escape html entities. There are esay to use native js methods which already 
handle this 
(escape(), encodeURI(), and encodeURIComponent())

This is inline with other Flash embedding techniques which also have no 
encoding built 
in.

Original comment by aran.rhee@gmail.com on 16 Nov 2009 at 12:05

• Changed state: Invalid

[GoogleCodeExporter]

how fucking stupid are you. its not enough that hundreds of people say they 
want 
flashvars to be escaped!!!

Original comment by r...@gmx.ch on 14 Jan 2010 at 4:11

[GoogleCodeExporter]

language like that is not going to get you anywhere.

this topic has been covered in issue #66:
http://code.google.com/p/swfobject/issues/detail?id=66

(i'm changing type from defect to enhancement)

Original comment by platelu...@gmail.com on 14 Jan 2010 at 4:58

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I'm sorry, I forgot to provide feedback about this issue when it was marked as
Invalid. I'd like you to reconsider since it seems you misunderstood the issue. 
It
isn't about escaping each parameter passed through flashvars, it is about an 
issue
where the param tag that holds the flashvars ends up corrupted because some of 
the
flashvars parameters have html entities.

I'm guessing this happens with IE because you're writing directly to the html 
instead
of using DOM and the contents of the flashvars param tag are not properly 
escaped
(the contents as a whole, not each individual entry in flashvars). This could
possibly lead to HTML injection issues, but I'm not sure. As a precaution I 
encode
all the flashvars parameters, even with it's not ideally required.

Also, please disregard the troll comment #2

Original comment by malterisio777 on 14 Jan 2010 at 5:31

[GoogleCodeExporter]

I can confirm now that this is a security issue.

Original comment by malterisio777 on 14 Jan 2010 at 5:50

[GoogleCodeExporter]

Hi malterisio777

I definitely see your point and we will take this seriously. However, since we
already have an open issue with the same topic, I'm merging this issue with the
existing issue #66.

Original comment by platelu...@gmail.com on 14 Jan 2010 at 11:42

• Changed state: Duplicate

[GoogleCodeExporter]

What is the security issue here? If the user has access to write flashvars to 
the page then 
they don't need to pass some value through swfobject.

To me this is still a matter of opinion: Some people don't want to url encode 
their 
flashvars, and some don't mind it. Or is there something else going on here?

(if you don't want to post some flaw publicly then please email the team 
privately)

Original comment by tensafef...@google.com on 18 Feb 2010 at 7:35

[GoogleCodeExporter]

Please check the comments on issue 66 and issue 427 for further clarification. 
The
defect first reported here has a different nature that the issue discussed in 
issue 66.

The impact of the security issue is minimal: an html injection could happen if 
the
attributes are fetched from data provided by the user. For example, if you do
something like this:

flashvars = <?php echo json_encode($some_user_data); ?>;

and that user data hasn't been sanitized for characters with special meaning in 
html,
that data could be the source of an html injection attack.

Original comment by malterisio777 on 18 Feb 2010 at 10:32

[GoogleCodeExporter]

Well that's not a swfobject issue, that's a not-escaping-user-input issue. 
We've already 
made one change to SWFObject to sanitize user input via getQueryParamValue, but 
in 
this case the user would already need access to the html, which isn't our 
responsibility.

Original comment by tensafef...@google.com on 19 Feb 2010 at 5:28

[GoogleCodeExporter]

The team recently discussed this issue and we agreed that we're wary of causing 
more
problems by adding something like encodeURIComponent. The difficulties include:

* what if someone runs encodeURIComponent before SWFObject, then SWFObject runs 
it again?

* what about backwards compatibility with existing installations of SWFObject?

* who's responsibility is it to encode the vars?

* how many people actually need something like encodeURIComponent?

In the end, it sounds as if the logical decision for us is to keep SWFObject 
neutral
and let developers decide whether or not they need to encode their vars. It's a
simple enough modification for an experienced JavaScript developer, and isn't
something most of our users need.

malterisio777, thank you for your feedback, we do appreciate it.

Original comment by platelu...@gmail.com on 19 Feb 2010 at 7:16

[GoogleCodeExporter]

bah, that's what I get for skipping team meetings :)

You should update the main thread (issue 66)

Disregard my change, I suppose.

Original comment by tensafef...@google.com on 19 Feb 2010 at 8:24

[GoogleCodeExporter]

I'm sorry for being so insistent, but IT IS an swfobject issue, the fact that 
this
issue only causes problems in Internet Explorer is proof of that. When swfobject
generates the html "by hand" instead of using DOM, the html is created without
properly escaping tag attributes, and that's what this issue is about.

Original comment by malterisio777 on 19 Feb 2010 at 12:24