flashVars are not escaped (urlencoded) properly

[GoogleCodeExporter]

SWFObject (v2.0) doesn't encode the flashVars values properly when writing
them to the DOM, so so values containing "&" chars etc. won't work.

You should add encodeURIComponent():

if (typeof par.flashvars != UNDEF) {
    par.flashvars += "&" + i + "=" + encodeURIComponent(flashvarsObj[i]);
}
else {
    par.flashvars = i + "=" + encodeURIComponent(flashvarsObj[i]);
}

Original issue reported on code.google.com by m...@thomasbachem.com on 8 Apr 2008 at 3:14

[GoogleCodeExporter]

This is not a bug. The flashvars Object is a shorthand notation that is there,
because many web authors find it easy to use. 

You can still specify your flashvars the old fashioned way via the params object
[quoting from the documentation]:

"The flashvars Object is a shorthand notation that is there for your ease of 
use. You
could potentially ignore it and specify your flashvars via the params Object:"

<script type="text/javascript">

var flashvars = false;
var params = {
  menu: "false",
  flashvars: "name1=hello&name2=world&name3=foobar"
};
var attributes = {
  id: "myDynamicContent",
  name: "myDynamicContent"
};

swfobject.embedSWF("myContent.swf", "myContent", "300", "120",
"9.0.0","expressInstall.swf", flashvars, params, attributes);

</script>

Original comment by bobbyvandersluis on 9 Apr 2008 at 9:04

• Changed state: Invalid

[GoogleCodeExporter]

Thanks for your anwers, Bobby :). But if you already offer it, why don't you 
want to
fix this shortcoming? Isn't this irritating and misleading without proper URL 
encoding? 

The current implementation makes the feature very dangerous for people like us 
that
fill in the flashVars values via an automatic script rather than manually.

Sure, we could urlencode them beforehands, but that's not the sense of 
implementation
detail hiding, right? Why should I have to know that flashVars have to be 
urlencoded
if an intelligent Flash handling layer like SWFObject could solve this for me?

Greetings from Germany,
- Tom

Original comment by m...@thomasbachem.com on 9 Apr 2008 at 1:09

[GoogleCodeExporter]

I see your point. I will put in on the feature request list.

Original comment by bobbyvandersluis on 9 Apr 2008 at 1:29

• Changed state: Onhold
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Original comment by bobbyvandersluis on 9 Apr 2008 at 1:31

• Changed state: OnHold

[GoogleCodeExporter]

Great, keep up the good work!

Original comment by m...@thomasbachem.com on 9 Apr 2008 at 1:42

[GoogleCodeExporter]

I too have fallen foul to this bug; this is a bug and not an enhancement.

A bug is where something breaks by following the documentation.

Example JavaScript as used within external JS file:
var flashvars = {
    sampleParam: "sampleValue",
    clickRedirect: "http://www.example.com/?param1=value1¶m2=value2"
};
swfobject.embedSWF("sample.swf", "someElement", "320", "240", "8.0.0", false,
flashvars, {});

The above sample outputs the following incorrect HTML code:
<param name="flashvars"
value="sampleParam=sampleValue&clickRedirect=http://www.example.com/?param1=valu
e1&param2=value2"/>

So the actual value passed to the SWF has "clickRedirect" is:
http://www.example.com/?param1=value1

When "clickRedirect" is expected to be:
http://www.example.com/?param1=value1¶m2=value2

Regards,
Dean.
Again thanks to all the people who have made SWFObject what it is today.

Original comment by DeanMark...@gmail.com on 15 Apr 2008 at 11:33

[GoogleCodeExporter]

Original comment by bobbyvandersluis on 16 Apr 2008 at 8:58

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by bobbyvandersluis on 16 Apr 2008 at 8:58

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

I thoroughly looked into the topic yesterday and had to conclude that this is 
neither
a bug nor an enhancement.

Why it is not a bug:

The flashvars mechanism of SWFObject 2.0 dynamic publishing doesn't work any
different than using flashvars with regular markup. Here you also need to 
encode a
URI when you want to use it as a value in a flashvars name:value pair.

Why it is not an enhancement:
It may seem an enhancement from "your specific" point-of-view, however looking 
at the
topic from a "generic flash embed solution" point-of-view things look way 
different.

Simply said it all depends on which flashvar value you use and, in case of 
using a
URI as a value it also depends on what you expect to receive within your Flash
environment. Now, this is a key point.

Simply using encodeURIComponent(flashvarsObj[i]) doesn't work, beacuse this 
would
break any flashvars that are already encoded by a user himself.

Trying to come up with a generic solution will give you even more headaches, 
e.g. by
using encodeURIComponent(decodeURIComponent(flashvarsObj[i])) would be the most
foolproof solution, however what if for example a media player would expect a 
value
to be encoded already (like in your case), in this case it will break too.

Furthermore we have to be careful using encodeURIComponent() and 
decodeURIComponent()
for generic means, because they are not supported by older browsers, e.g. in IE 
they
are only supported by version 5.5+, so this would impact the desired 
cross-browser
support of the library, which currently also supports IE 5.0+ on Win XP+. Of 
course
we can revert to using escape/unescape, however this again has shortcomings 
that can
be avoided by the newer methods, like encodeURIComponent.

Summarized:
- SWFObject 2.0 behaves just as regular markup
- A single generic abstraction is probably impossible to create
- SWFObject 2.0 offers the flexibility for a user to customize and use it for 
their means

I will create either an FAQ item or add a note to the documentation on how to 
encode
 URIs when used with flashvars.

Original comment by bobbyvandersluis on 17 Apr 2008 at 9:09

• Changed state: WontFix

[GoogleCodeExporter]

> Simply said it all depends on which flashvar value you use and, in case of 
using a
> URI as a value it also depends on what you expect to receive within your Flash
> environment. Now, this is a key point.
Actually, the entire issue of encoding things is completely independent of the 
values
to be encoded. The fact that we have to use URI encoding here is not because we 
want
to put a URI into a flashvar, but it is because the flashvars param uses 
URI-like
encoding to keep the parameters apart (e.g., using &, = and % as special 
characters).

It is true that using a URI in a flashvar will increase the likelyhood of 
having &
characters, but there are unlimited other examples (the string "Ben & Jerry's" 
for
example). If a flash variable contains user input, escaping is particularly 
needed
(and not escaping might even pose a security threat!). Also note that when no 
such
special characters are present in a value, encoding is not needed, but does not 
hurt
either. So, always encoding each flashvar is a good idea.

> The flashvars mechanism of SWFObject 2.0 dynamic publishing doesn't work any
> different than using flashvars with regular markup. Here you also need to 
encode a
> URI when you want to use it as a value in a flashvars name:value pair.

That is true, but there is one important difference. When passing in the 
flashvars as
an array, the actual means of encoding them is abstracted by SWFObject. 
SWFObject is
the one to encode the separate flashvars into a single string, so it should 
handle
the encoding of the components as well. This means that the array with 
flashvars can
contain any string, and does not require the user of SWFObject to escape each
variable separately. Not only is this manual escaping tedious, but it is also 
likely
that variables will be forgotten, introducing bugs. By letting SWFObject
automatically escape all values, its interface becomes a lot more powerful.

Considering the above, I would say this is indeed a bug (or at least a 
documentation
bug, since the documentation never states that all flashvars must be URI 
encoded) or
valid feature request, since the SWFObject interface doesn't make sense as it 
is now
(abstracting away the creating of the flashvars string, but not the encoding of 
the
components).

Having said that, the arguments about breaking compatibility are indeed valid. I
think this behaviour should be changed, but there should probably be some 
migration
path. Just changing the behaviour and hoping people will read the release notes 
is
not sufficient.

I would propose the following:

 1. Implement the new behaviour, but make it optional. Users can enable this by
setting swfobject.encode_flashvars = true before calling embedSWF. All 
tutorials and
documentation should suggest setting this, so new users will get the right 
behaviour
from the start. Release notes should strongly suggest users to check their code 
and
set this variable to make it more reliably.
 2. In a further release, add an alert (or something) when a user has not set
encode_flashvars. By making the default "undefined" (instead of false), users 
can
explicitely disable it, and not get the message. This forces users to choose 
either
behaviour.
 3. In another release, make the default true instead of undefined. This allows users
to remove the variable setting and we don't have to bother new users with it 
anymore.
It can be removed from the tutorials. The setting remains for users who really 
want
the old behaviour.
4. (Optional) Remove the setting alltogether and always have the new behaviour. 
This
might be annoying for users that rely on the old behaviour, but considering that
updating to the new behaviour should be fairly easy (and anyone who is updating
SWFObject can be expected to do at least some work to keep things working), I 
think
this is a good idea.
5. (Optional) Add an alert for anyone who still sets a value to this setting. 
This
reminds people to clean up their code.

Some of these steps could be done together, for example 1 and 2, and 3, 4 and 5 
could
be merged. The announcements / alerts in steps 1 and 2 should depend on wether 
you're
planning to do step 4 as well, of course.

As for the IE5.0 support, this could be solved by falling back to escape (or 
perhaps
a custom function that just escapes &, = and %). However, perhaps IE5 support 
isn't
so much of an issue anymore by now? W3schools stopped monitoring IE5 usage over 
a
year ago, when it was used for 0.5% of the total requests [1].

So, I hope that, given the above, you'll reconsider implementing the requested 
behaviour.

If you do, note that the initial reporter proposes to escape the flash var 
values,
which is a good step, but don't forget to escape the keys as well! It's a lot 
less
likely that special characters appear there, but if they do, they'll break the
flashvars in exactly the same way.

[1]: http://www.w3schools.com/browsers/browsers_stats.asp

Original comment by matthijskooijman@gmail.com on 8 Oct 2009 at 11:53

[GoogleCodeExporter]

Issue 402 has been merged into this issue.

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

[GoogleCodeExporter]

Issue 427 has been merged into this issue.

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

[GoogleCodeExporter]

I believe this issue needs to be addressed. Changing status to accepted and 
type to
defect due to security exploit described in issue #402 and #427.

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

• Changed state: Accepted
• Added labels: Priority-High, Type-Defect
• Removed labels: Priority-Medium, Type-Enhancement

[GoogleCodeExporter]

Issue 217 has been merged into this issue.

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

[GoogleCodeExporter]

Issue 194 has been merged into this issue.

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

[GoogleCodeExporter]

Issue 216 has been merged into this issue.

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

[GoogleCodeExporter]

Issue 227 has been merged into this issue.

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

[GoogleCodeExporter]

Sorry for being so stubborn but I must insist that this is not the same issue 
as the
one referred in #402 and #427.

There are actually two stages where the strings needs escaping and the escaping
required is different:

First, the flashvars attributes need to be uriencoded so that the flash player 
parses
them properly. Failing to encode the flashvars this way may only result in the 
flash
player getting the attributes wrong.

Second, all the flashvars must be encoded into html entities so that they can be
included in the value attribute of a param tag. This is what is failing in IE
browsers. Moreover, this failure presents a security breach explained in #427.

The second issue needs to be solved. The first issue doesn't, what's more, it
shouldn't. If you start uriencoding the flashvars you'll break BC and most 
surely
break a lot of people sites (wherever someone is already uriencoding their 
flashvars,
they'll get their vars doubly uriencoded).

Original comment by malterisio777 on 15 Jan 2010 at 12:33

[GoogleCodeExporter]

The attachment is a patch against the trunk for #427.

Actually, all variables from the object holding the parameters are encoded with 
this
patch, mirroring what happens when the DOM is used to generate the HTML. 
Variables
from the object holding the attributes should also be escaped but it's not 
included
in the patch (although is quite trivial to also do that).

The escaping is done only for the " character, which is converted to ". This is
enough to stop the HTML injection in IE.

Original comment by malterisio777 on 15 Jan 2010 at 1:23

Attachments:

• swfobject-fix427.patch

[GoogleCodeExporter]

Issue 377 has been merged into this issue.

Original comment by platelu...@gmail.com on 15 Jan 2010 at 2:39

[GoogleCodeExporter]

My intention is to get all the flashvars 'escape'-type discussions in one 
place, as
there are many of them scattered around. While you may be correct that the 
issues
you've mentioned require two different solutions, I believe they belong in the 
same
discussion in terms of if/how to deal with values passed into flashvars.

Your clarifications are welcome.

Original comment by platelu...@gmail.com on 15 Jan 2010 at 2:50

[GoogleCodeExporter]

Upon further investigation, the scope of issue #427 isn't just limited to the
flashvars, all the parameters are unsafe:

swfobject.embedSWF('"></object>...more html...', "myContent", "300", "140", 
"9.0.0",
"expressInstall.swf");

swfobject.embedSWF("test.swf", "myContent", '"></object>...more html...', "140",
"9.0.0", "expressInstall.swf");

This all will result in the player failing to load and html being injected when 
using
an IE browser.

---

Also, Issue #66 can be solved from the user side (doing the uriencode), but 
issue
#427 can only be solved transparently from inside swfobject, that's why I think 
they
should be treated as different issues.

Original comment by malterisio777 on 15 Jan 2010 at 2:05

[GoogleCodeExporter]

I also agree that these are completely separate issues and that this merging 
will
only clutter the discussion. #427/#402 should be solved ASAP and does not have 
any
"legacy" code that might break with a solution. #66 should be fixed as well 
IMHO, but
just fixing the issue means an API change, so it should be done very carefully. 
Any
chance someone can comment on the proposal I outlined in comment 10?

Original comment by matthijskooijman@gmail.com on 21 Jan 2010 at 4:50

[GoogleCodeExporter]

Sorry if I seem dense, but I'd like a clear explanation why 402 and 66 are 
different
issues.

Issue 66 began with a request to use encodeURIComponent on values passed to 
flashvars:

   par.flashvars += "&" + i + "=" + encodeURIComponent(flashvarsObj[i]);

The solution proposed in 402 is to use encodeURIComponent on flashvars values.

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

The only difference I see is *when* encodeURIComponent is used.

Please explain (again) why 66 and 402 are separate issues. (I'm not trying to be
difficult, I'm honestly trying to understand what you propose)

malterisio777 said

   "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 understand this, but wouldn't using encodeURIComponent as proposed in issue 66
solve the problem?

And RE: the security issue, wouldn't the flashvars name also need to be escaped 
to
prevent HTML injection?

   par.flashvars += "&" + encodeURIComponent(i) + "=" +
encodeURIComponent(flashvarsObj[i]);

Original comment by platelu...@gmail.com on 22 Jan 2010 at 3:12

[GoogleCodeExporter]

Even though these two issues are similar (they are both issues of
encoding something), the encoding (or lack thereof) occurs in two
seperate locations. Also, due to backwards compatibility, the solution
to #66 is more complicated than the one for #402 / #427 (which are the
same issue, AFAICS).

#66 deals with the encoding issues resulting from putting all the
flashvars inside a single url-like string. You're building a single
string of the form var1=val&var2=val2. In this string, there are three
special characters, namely &, = and %. Each of occurence of these
characters in the components needs to be escaped. As you suggested, this
should include not only the values, but also the variables. Note that
any other character is allowed to be encoded using urlencoding, but it
is not required to remove ambiguity. However, encodeURIComponent encodes
most characters.

#402 and #427 deal with the encoding issues resulting from putting
values inside a HTML attribute. You're building a string of the form
<object data="foo.swf" width="10" etc. In this string, there are at
least four special characters: <, >, " and &. Each occurence of these
characters in the attribute values needs to be escaped using HTML
entities (e.g., use " and & etc.). Again, any other character
is allowed to be encoded, but it is not required.

In general, you need to perform escaping whenever you embed arbitrary
strings into some format (like the flashvars url-like format and the
HTML format here). The best way to ensure escaping is done, is to do the
escaping in exactly the same place where the embedding is done. Moving
the responsibility for escaping further "up" by doing the escaping
earlier (like in #66, where the caller of embedSWF is currently
responsible for passing urlencoded flashvar values) is easy to get
confusing and make people forget to do the escaping.

There is also a security side to this story: When the escaping is done
as late as possible, your functions will accept any string (e.g., not
only escaped strings) and work properly for them. The worst what could
happen is that a caller passes an escaped string instead of the plain
string, which would result in some string being displayed incorrectly or
other functionality breaking. On the other hand, if one moves the
escaping responsibility to the caller, your functions will accept
escaped strings and work properly only when their arguments are
escaped). The worst thing that can happen now, is that a caller passes a
plain (non-escaped) string containing user input, which can now escape
the format it is embedded in and, for example, add javascript code to
your HTML.

However, since these kinds of problems don't show up when the special
characters don't appear in the embedded strings, forgotten escaping
doesn't show up in most ad-hoc testing. In the case of flashvar names,
for example, it is unlikely that they will contain any of the special
characters, so most people will not even think about escaping them. But
unless you know exactly what variable names are possible and you can be
sure that each of them does not contain any special characters, not
escaping is still incorrect.

It's also easy to mask these problems. As suggested in #402, using
urlencoding on the flashvars indeed works around this problem. This is
because encodeURIComponent escapes almost all characters, including ".
This ensures that the string that will be embbedded into the HTML
attribute will never contain ", so this particular problem doesn't
surface. However, this is still a workaround. As noted above, for the
flashvars-url embedding, it would be sufficient to escape only &, = and
%. Escaping " is only necessary for the HTML embedding, where the proper
solution would be to replace it with ". So, using
encodeURIComponent on the flashvar names and values does prevent HTML
injection AFAICS, but it is not the complete solution for the HTML
embedding problem.

Also, this HTML embedding problem doesn't show up for just the
flashvars, but as malterisio777 pointed out in comment 22, all of the
properties (like url and width) should be escaped. For these, the user
could apply the HTML entity escaping before passing them to embedSWF,
but this would again be a workaround at the wrong level.

Finally, there is one more thing that the encodeURIComponent on the
flashvars does not fix. In HTML, the character & is special and may only
be used to start an entity. This means the following HTML, as generated
by swfobject (I think) is invalid:

    <param name="flashvars" value="foo=bar&baz=blerf" />

It uses & directly, so it should instead be:

    <param name="flashvars" value="foo=bar&baz=blerf" />

Now, most browsers won't error out on this, since even though the HTML
is incorrect per the specification, there is no ambiguity. However, if
would would have a flashvar name containing a semicolon, like "lt;baz",
we would get:

    <param name="flashvars" value="foo=bar<baz=blerf" />

Now, a browser will see the (unknown) entity " and pass
"foo=bar<baz=blerf" to the flash player, which is really not what we
intended. This example is a bit contrived, and will probably never occur
in practice, but it does show that using encodeURIComponent on the
flashvar values doesn't solve all of the HTML embedding problem.

I hope this makes my (our) point a bit more clear. It's hard to clearly
separate these issues because they do in fact look similar and influence
each other, but I hope you can see that they are in fact different.

Original comment by matthijskooijman@gmail.com on 22 Jan 2010 at 12:07

[GoogleCodeExporter]

So, what I'd like to do in order to keep at least some backwards compatibility 
is to 
only encode the flashvars if we have to (that is, only if there are special 
chars that 
need it). This will keep things from being double escaped so we'll maintain 
backwards compatibility.

I propose we add the &, =, and % symbols to the "urlEncodeIfNecessary" function 
and 
add that when we convert the flashvars object to a string.

I've also changed the "&" to "&" when we join the flashvars - this shouldn't 
affect 
any behavior and will simply make the outputted html valid as mentioned in the 
comment above.

A proposed patch is attached, have a look and let us know what you think.
 (note that it's not tested, still needs to be run through the test suite if anyone feels 
like doing that)

Original comment by TenSafeF...@gmail.com on 19 Feb 2010 at 7:21

Attachments:

• issue_66_escape.patch

[GoogleCodeExporter]

Hmm, actually this will double escape the % character - so if people already 
use 
swfobject and are escaping something, it will convert %26 to %2526, which I 
think may 
cause issues.

Anyone know if that will break the value passed in, or will the flash 
player/browser do 
the right thing here?

Original comment by TenSafeF...@gmail.com on 19 Feb 2010 at 7:29

[GoogleCodeExporter]

As you already noted, just escaping when it "looks like it is needed" is really 
not
the way to go. It will cause issues with already escaped % signs, and even when 
you
go nuts and actually check that all % signs are followed by two digits, you'll 
still
run into trouble with values like "In URLS, spaces are escaped as '%20'".

As for the replacing of & with &, please don't do that there. It is totally
ad-hoc and is very prone to miss other occurences. Instead, all of the HTML
attributes should be HTML escaped entirely when they are outputted, as 
discussed in
#402. Let's leave the HTML escaping out of this issue and focus just on the URI
encoding here.

In comment 10 I proposed a scheme for properly adding the escaping, without 
breaking
backwards compatibility directly. I don't think anyone has commented on that 
scheme,
could you look at it again?

Original comment by matthijskooijman@gmail.com on 19 Feb 2010 at 9:12

[GoogleCodeExporter]

> As for the replacing of & with &, please don't do that there. It is totally 
ad-
hoc and is very prone to miss other occurences.

I don't understand what the problem is here, can you be more specific?

We are only adding & characters in that one place, and the other flashvar 
values will 
be encoded using encodeURIComponent which would remove the need to escape 
anything in there.

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

[GoogleCodeExporter]

As noted in #402, there are other places where things need to be HTML escaped. 
In
general, the only proper place to do that HTML escaping is at the same place 
where
you put values into the HTML.

It is true that in the case of the flashvars value, other escaping is not 
necessary.
But when you pull apart the HTML escaping of the value and the embedding of the 
value
into HTML like this, it's harder to see that everything is in fact escaped 
properly
everywhere. Also, people might assume that HTML escaping is not necessary when 
they
view the HTML embedding code and (wrongly) apply that assumption to other 
values and
leave out the proper escaping.

Also, you only solve a part of the HTML escaping problem here, so it is probably
better to focus on the URI escaping problem here and leave the HTML escaping 
problem
in its entirety for issue #402.

Original comment by matthijskooijman@gmail.com on 19 Feb 2010 at 6:40

[GoogleCodeExporter]

There is not more detail in issue 402 - you keep referencing these two issues 
and it's making things very 
difficult to follow.

I fail to see an issue here, so in the hopes of clarifying things a bit, I'll 
repeat some assumptions here and 
you can please correct them here in this thread rather than referencing other 
threads.

1) Currently we don't escape params passed into swfobject. I think this is fair 
and not needed. 

2) Currently we don't escape flashvars passed into swfobject. This is a debated 
issue and has a long history 
going all the way back to swfobject 1. I personally don't care if we add 
automatic escaping to the flashvars, 
but it does complicate things a bit.

3) There are no actual security issues here. User input through swfobject is 
sanitized. Other user input 
through a user's website should be sanitized by the website before being passed 
to SWFObject, so this is 
not our issue.

4) HTML entities need to be escaped in the SWFObject output. My patch addresses 
this by changing the & 
to an &. This is the only place that swfobject inserts & into the code, so 
should fix the issue. Other 
entities would need to be escaped by the user before passing them into 
SWFObject.

Anything else?

Original comment by tensafef...@google.com on 19 Feb 2010 at 7:01

[GoogleCodeExporter]

I personally find it annoying that I'd have to encode my flashvars when it 
works fine
in Firefox and safari but not in IE.  I also don't see why backwards 
compatibility is
an issue. So people need to update their scripts when they update swfobject, 
big deal.

It also bothers me that for two years people have been complaining about this 
and
'you' think you are smarter than us and just say no.  swfobject is supposed to 
make
embedding swfs simple and easy.  Having to encode things adds complexity to it. 
I
know it's not hard to do, I'm a developer and fairly smart, but that's not the 
point.
 The point is a lot of people that use swfobject are not developers.  At the very
least make it optional, some sort of global flag we can set, but make it 
default to
encode.  This isn't going to affect that many people adversely.  I'm guessing 
many
don't even use flashvars, and many that do don't have special characters to deal
with.  I've made hundreds of flash apps that were never affected by this "bug". 
 I've
made a few now that are but I didn't notice the problem until we got to UA 
testing,
since all the developers are on Mac OS X and don't really have easy access to 
IE. 
This "bug" could have caused a lot of extra work for us.  We patched swfobject 
as a
stopgap, but would rather swfobject be fixed.

It boils down to, who is the target market?  casual users, experienced 
programmers,
gurus, all of the above?  Unless you are excluding casual users it's foolish to 
not
fix this.  At the very least update the docs so that users are aware of this 
flaw and
potential security vulnerability.

Original comment by pdecour...@gmail.com on 30 Apr 2010 at 8:07

[GoogleCodeExporter]

A related issue:

Any Flash Var that contains a double quote will result in malformed HTML.  Many 
browsers seem to be able to deal with this, but IE does not (and it shouldn't 
be assumed anyway).

For example, if you pass a flashvars object like {whatever: 'double"quote'}, 
SWFObject will internally create HTML like the following:

<param name="whatever" value="double"quote" />

(This happens on line 432.)  The issue, obviously, is that the attribute is 
terminated early.

Original comment by matthewt...@gmail.com on 23 Jun 2010 at 7:12

[GoogleCodeExporter]

flashvars is not passing the value in IE while embeding in thickbox using 
swfobject.embedSWF method there is any solution for this.

Original comment by yuganath...@gmail.com on 30 Jul 2010 at 1:52

[GoogleCodeExporter]

Concerning this issue, It should either be implemented or the documentation 
should be updated. Best case scenario, it's implemented.

The doc says :
flashvars (Object, optional) specifies your flashvars with name:value pairs 

but using name:value pairs is optional, it should be something like that :
flashvars (Object, optional) Pass the object's values to the flash object. 
Often defined with name:value pairs.

But it's not totally true since if you use any of those character (& = ") it 
would break. so it should read :
flashvars (Object, optional) Pass the object's values (pre-encode by the script 
user) to the flash object. Often defined with name:value pairs. 

This is it, right now, the values must always be pre-encoded by the script user 
or it will have predictable behaviors, mainly for those affecting variables to 
the objects.

The question is why is it the script user's job to know which encoding to use ?

flashvars Should transform an object of values into something readable for 
flash player. There is two step for that : 
1) transform the object into an url string.
2) put this string in a valid DOM argument inside the embedded player tag.

Both of those step are done in-properly :
1) it only put & and = between keys and values, this is not a proper ways to 
convert an object into a url string. keys and values needs to be escaped.
2) It only put the string between two double quote , this is not a proper ways 
to write a DOM argument. Repeating quote characters must be escaped.

The reason why i think the projects owners don't want to address this issue is :
Doing so will break scripts of all those who already encoded their values to 
bypass this issue. And maybe the implementation will take longer to make than 
at first look.

Those are difficulties, it do not means it's the right way to do.

Please at least tell in the documentation that the values must be URL-encoded.

Original comment by kev.gigu...@gmail.com on 7 Sep 2010 at 9:00

[GoogleCodeExporter]

It worked in prior versions of swfobject, from a regular users perspective this 
is messed up! =/

Original comment by flexzion...@gmail.com on 2 Dec 2010 at 9:34

[GoogleCodeExporter]

Diziler http://www.turkdizi.tv/ http://www.turkdizi.tv/kolej-gunlugu/ 
http://www.turkdizi.tv/duz-adam/ http://www.turkdizi.tv/yeniden-basla/ 
http://www.turkdizi.tv/karakol/ http://www.turkdizi.tv/basrolde-ask/

Original comment by xdag...@gmail.com on 21 Apr 2011 at 11:03

[GoogleCodeExporter]

Issue 554 has been merged into this issue.

Original comment by platelu...@gmail.com on 14 May 2011 at 8:21

[GoogleCodeExporter]

Issue 554 is not quite the same as this one, but I think it belongs in the same 
conversation: whether/when/how to encode flashvars.  Issue 554 is focused on 
the application/xhtml+xml content type in IE9.

The suggested fix was to change
aa.outerHTML='<object 
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"'+ah+">"+af+"</object>";

To
aa.outerHTML='<object 
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"'+ah+">"+af.replace(/&/g,"&"
)+"</object>";

The poster wrote "IE9 is the first version of IE to support the 
application/xhtml+xml content type, and since SWFObject does not use 
appendChild to create the <param /> nodes, the JS errors out with invalid JS."

But a byproduct of this proposal is the potential for encoding an already 
encoded string: & would become &amp;

Original comment by platelu...@gmail.com on 14 May 2011 at 8:25

[GoogleCodeExporter]

Wouldn't that byproduct easily be fixed by doing

af.replace(/&/g, '&').replace(/&/g,"&")

Original comment by markus.h...@gmail.com on 14 May 2011 at 9:20

[GoogleCodeExporter]

I've proposed a couple of changes to SWFObject that improve FlashVars handling. 

As reported in Issue 536, the string building approach for creating the 
<object> element in Internet Explorer has been replaced by W3C setAttribute and 
createElement methods, bringing consistency to the handling of attributes and 
child nodes. This is important for FlashVars because FlashVars are specified 
via a <param> child node; in the previous codebase, the FlashVars <param> was 
created using string concatenation in IE and createElement in all other 
browsers. Now IE uses createElement as well.

The second change is the creation of a new option in SWFObject: the 
swfobject.enableUriEncoding() method. This method allows a developer to choose 
to enable encodeURIComponent for FlashVars. 

   swfobject.enableUriEncoding(); //turns on encodeURIComponent
   swfobject.enableUriEncoding(true); //turns on encodeURIComponent
   swfobject.enableUriEncoding(false); //turns off encodeURIComponent

encodeURIComponent is OFF by default, to ensure backwards compatibility.

Important: This new functionality only affects FlashVars passed via embedSWF's 
FlashVars object; if you pass FlashVars via the parameter object or via 
createSWF, the FlashVars will not be encoded.

   swfobject.enableUriEncoding();

   var flashvars = {
      sampleParam: "sampleValue",
      clickRedirect: "http://www.example.com/?param1=value1¶m2=value2",
      greeting: "hello, world!",
      quote: 'quote"mark'
   };

   var params = { flashvars: "existing value" };
   var attr = {};
   swfobject.embedSWF("test.swf", "myContent", "300", "120", "8.0.0", "expressInstall.swf", flashvars, params, attr);

Generates:

<param name="flashvars" value="existing 
value&sampleParam=sampleValue&clickRedirect=http%3A%2F%2Fwww.example.com%2F%3Fpa
ram1%3Dvalue1%26param2%3Dvalue2&greeting=hello%2C%20world!&quote=quote%22mark">

Note that the value passed as a param ("existing value") is not encoded.

This modification is a proposal, and is currently in my GitHub fork; it has not 
been officially added to SWFObject yet.
https://github.com/pipwerks/swfobject/commit/899ba664bd8b0b0d69876f1615315e314ed
6be15

Original comment by platelu...@gmail.com on 30 May 2011 at 5:10

• Changed state: Fixed

[GoogleCodeExporter]

This looks like the perfect fix for this problem, I'd be happy if it could be 
included in the official release. It handles backwards compatibility with its 
default setting and allows making swfobject handle the encoding like it should 
with a single function call.

Original comment by matthijskooijman@gmail.com on 30 May 2011 at 6:21

[GoogleCodeExporter]

Just use the encodeURIComponent() function like this:

var flashvars = {};
flashvars.xmlPath = encodeURIComponent("hello&how&are&you");

Original comment by joseph.w...@gmail.com on 4 Jun 2011 at 12:45

[GoogleCodeExporter]

Erm, I was wondering will it effect Unicode characters...?  I tried this and it 
UriEncoded EVERYTHING which is not the result I needed.

Original comment by wycoco...@gmail.com on 16 Aug 2011 at 7:31