<?xml version="1.0" encoding="iso-8859-1"?><rss version="2.0">
<channel><title><![CDATA[ActionScript.org Flash, Flex and ActionScript Resources - Comments for article: JavaScript and VBScript Injection in ActionScript 3]]></title><link>http://www.actionscript.org/resources</link><description /><language>en-us</language><copyright><![CDATA[http://www.actionscript.org/resources]]></copyright><generator>N/A</generator><webMaster>general.redirect@gmail.com</webMaster><lastBuildDate>Mon, 23 Nov 2009 03:25:01 CST</lastBuildDate><ttl>20</ttl><item><title><![CDATA[Comment #1]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11821</link><description><![CDATA[Adobe closed most of these vulnerabilities in April with player 9.0.124.0.

I struggle to understand why a 'legitimate' developer would want to engage in practices like these? Any Flash dev reaching for cross-site script injections to achieve their goal really needs to ask themselves if they understand the web at all.<br/><br/>
(Comment posted by Flexy at 7:14 am, Thu 14th Aug 2008)]]></description><author>no@spam.com (Flexy)</author><pubDate><![CDATA[Thu, 14 Aug 2008 07:14:51 CDT]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11821</guid></item><item><title><![CDATA[Comment #2 (Reply to Comment #1)]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12456</link><description><![CDATA[Some things can't be done with AS3 
EX. I have an AESEncrypted data service for all my flex applications but there is no AS3 encryption that matches up with PHPs Mycrypt functions (yes AS3Crypto is a complete joke as it cant be read by any other encryptor/decrypted know to man). So I found a set of Javascript functions that had be designed to work with PHP and now all of my XML data that I pass back and forth is secure<br/><br/>
(Comment posted by Corbin at 8:47 am, Tue 30th Dec 2008)]]></description><author>no@spam.com (Corbin)</author><pubDate><![CDATA[Tue, 30 Dec 2008 08:47:00 CST]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12456</guid></item><item><title><![CDATA[Comment #3]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11834</link><description><![CDATA[A few people have raised concerns about script injection, stating that they see no legitimate uses for it, and that a well-designed web application has no need for it.

I counter by saying there are dozens of uses, and that understanding one person's interpretation of "the web" isn't nearly as important as understanding and being able to adapt to the practicalities of real-world situations. In a perfect world, script injection would not be needed. This is not a perfect world.

As I said, there are ***dozens*** of legitimate uses depending on your situation, need, and environment. I work for an online security and digital rights company and we use this technique all the time to solve numerous problems with deployment, implementation and integration.

I'll admit it: in general, script injection is a pointless exercise for small-scale development teams as they generally deal with smaller projects and have better control over all aspects of a project - particularly integration. The real benefits kick in on large projects, particularly where multiple teams and/or environments (often from differing companies) are involved. Examples:

1) Hosting: Sometimes it's not practical to install JavaScript files on the host server(s), either due to the number of install sites (such as in advertising, games, or video players used in multiple locations) or when the hosting site is largely maintained by a third party, making updates to external files other than a specific Flash-only directory impractical or impossible (CDNs and mega-corporations being classic examples). Many ISPs, for instance, will allow you to have Flash content on your personal sites, but don't allow external JavaScript files and almost certainly won't allow VB scripts. 

2) Compression: Big Scripts? One I'm working on now is 17,000 lines long, and unless I'm supporting gzip, that's a lot to download. By way of example, the Dojo framework is over 200k, even in compressed mode, but if injected via Flash it's only 70k.

3) Collisions Avoidance: Flash provides a collision-proof namespace since scripts are attached to the Flash Player, not the global scope. Thus they will work in many more situations than traditional scripting methods, and you don't need to worry about some other team stepping on your code. Good JavaScripters often think they will not need to worry about this... but not everyone you are working with is going to be a good JavaScripter. 

4) Site/Role Blur: It gives the Flash developer more control over the JS-AS bridge. The Flash developer can give the JavaScript developer a simple API, enabling the JS guys to begin work. Meanwhile, our Flash developer can tweak and hone his interface directly from Flash, which is useful.

5) Modularity and Integration. AKA "Badges" or "One file, one solution". Traditional programmers tend to want hard paths, directories, and multiple dependent structures, leading to great organization and order *for them*, but also creating dependency, rigidity, and making deployment complex, particularly where code is reused often. A new trend in programming is to reduce the number of objects, classes and files, and just make one ***single*** widget that works everywhere. Move the widget, rename it, use it in a new way, and it should still work. Script Injection via Flash facilitates this to a degree not otherwise possible. 

6) Context. Script Injection allows the Flash Developer a really easy way to "scope out" the context his movie happen to be playing in. I can, for instance, detect the CSS that wraps my movie - are we using Helvetica or Courier? If the mouse moves outside the Flash window, where Flash cannot see it moving, where is it? The point is that I don't need to tell anyone on the other teams that this is happening, so the proper pointers can be updated, etc. This is simply not practical using traditional file-based JavaScript.

7) Flexibility. Where do I begin? Imagine a page full of widgets, that the USER (not the designer) has dragged out in a web-portal-type page. Traditional javascript approaches would require a fairly complex framework to support this. In script injection, each widget becomes responsible for it's own context, and the "framework" suddenly downgrades to just an "interface".

On one site I wrote, for example, there can be up to **90** Flash movies playing at any given point in time. Some play video, some display graphics or text data in multiple ways, some run ads, some play games. The catch is that they are all the ***exact same*** 100k swf, loaded only once and then cached, so the page loads almost instantly. 

Script Injection is then used to analyze the context that each instance of the swf appears in... reading local-node CSS, position on the page, load order, etc.....  Once it knows its context on the page, it knows what it needs to do, with no dependencies on third parties to maintain it. This would be a nightmare to implement traditionally, particularly if a designer, for instance, moved or renamed one of the DIVs.

Like I said in the article, Script Injection only sounds sinister because it sounds similar to an unrelated hacker URL exploit. I didn't come up with the name, and prefer to call it "Script Packing", but one runs with what's been accepted by the community, which is why VHS won over Betamax, and BlueRay won over HD-DVD, right?

Enjoy!<br/><br/>
(Comment posted by Pete McBride at 6:01 pm, Sun 17th Aug 2008)]]></description><author>no@spam.com (Pete McBride)</author><pubDate><![CDATA[Sun, 17 Aug 2008 18:01:39 CDT]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11834</guid></item><item><title><![CDATA[Comment #4]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11839</link><description><![CDATA[The injection you’ve kindly taken the time to qualify was exactly how I originally interpreted your article:

1) Hosting: Having a poor hosting solution is the problem here. Whilst this solution may get things working, you'd be creating an architectural time-bomb. Architects inside 'mega-corporations' would be unlikely to permit such practices. The reasons why cheap/free hosting companies don’t permit VBScript are blindingly obvious.

2) Compression: Minify code compression? G-Zip file compression is supported by most browsers these days. 

3) Collisions Avoidance: This comes down to communication. If development teams aren't going to talk to each other, you're always going to end up with problems. "...but not everyone you are working with is going to be a good JavaScripter" ...And likewise I suspect the JavaScripter is likely to think the same about the ActionScript developer trying to script his DOM. 

4) Site/Role Blur: I'm all for people being able to maintain multiple skill sets, but we need to have the right people doing the right job. The developer responsible for the web page - working in conjunction with rest of the dev team - will script the page in a specific way; understanding all of the use-cases involved. Is it right that a lone-ranger on the other side of the office, who doesn’t want to talk to anyone, starts executing scripts that alter this? No. There’s no reason why the ActionScript developer can’t work with the rest of the development team to integrate their JavaScript code with the website script libraries.

5) Modularity and Integration: Granted this allows independence from the environment, allowing the app to exist in other environments by moving only the SWF. We must not forget the bigger picture though; we’re making assumptions that the environment will not be negatively affected by the script injection. The SWF may work on Site A, then be moved to Site B and work fine too; but it doesn’t mean for one minute that Site B is unaffected by this injection. There may also be dependencies coded into the SWF that require the host DOM to contain certain element Ids.

6) Context: Here we’re talking about dependencies that should be passed to the object, which is essentially a child object of the DOM. A good application doesn’t call its parent for its dependencies, so why should a Flash app do this? Doesn’t doing so also create tight-coupling between the SWF and the page, breaking point (5)? “...The point is that I don't need to tell anyone on the other teams that this is happening”. Urm, there’s the lone-ranger again...

7) Flexibility: “...each widget becomes responsible for its own context, and the "framework" suddenly downgrades to just an "interface..." And I would expect a setup like this to fall apart within days of being launched! You don’t let your fingers and toes tell your brain what to do, and the same applies to a page with a myriad of Flash widgets operating in it. The framework that we so kindly demote to an interface was the only thing stopping every single widget asserting its own importance on the DOM.

As for the 90 Flash movies playing simultaneously, my concern wouldn’t have been for the file size but the impact on CPU and memory usage!<br/><br/>
(Comment posted by Flexy at 11:10 am, Tue 19th Aug 2008)]]></description><author>no@spam.com (Flexy)</author><pubDate><![CDATA[Tue, 19 Aug 2008 11:10:49 CDT]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11839</guid></item><item><title><![CDATA[Comment #5]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11840</link><description><![CDATA["Adobe closed most of these vulnerabilities in April with player 9.0.124.0."

Not true. This update specifically affects a vulnerability that allowed malicious swfs to execute corssdomain attacks by using javascript protocols in URLs not intended to interact with the browser. As I recall, the specific exploit involved appending JS code to urls such as those used by image loaders and flvplayer, which bypassed both the crossdomain policy and the AllowScriptAccess settings: that's a legitimate exploit which Adobe wisely plugged up.

This has nothing to do with that. ExternalInterface, getURL, etc. are specifically intended for browser interaction and are already covered by crossdomain and AllowScriptAccess policies, and therefore are not affected by the update. 

If you don't like it, just set AllowScriptAccess to "never".

Your other points, however, are generally valid. As I've stated several times, if this were a perfect world, script injection would not be necessary. It is merely a workaround to be used for unusual situations. You should be thankful you work in an environment where you have total control over all aspects of a project... few serious developers have this luxury.<br/><br/>
(Comment posted by Pete at 5:47 pm, Tue 19th Aug 2008)]]></description><author>no@spam.com (Pete)</author><pubDate><![CDATA[Tue, 19 Aug 2008 17:47:17 CDT]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11840</guid></item><item><title><![CDATA[Comment #6]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11929</link><description><![CDATA[Hi guys,
I wrote an integrated parser which reads in .js files, does automatic conversion to an XML format, and then writes the function blocks to the enclosing page.  This allows you to write all the .js externally, test it natively, before pipelining it through flash.  As long as the .js files are well formatted with equal numbers of { } it works perfectly.  This accomplishes 99% of what you really need javascript injection for.  I have it integrated into my AS3 app framework but if there's interest I could make the code available as a standalone piece.  It was a decent amount of work with some great results.<br/><br/>
(Comment posted by Michael at 2:20 pm, Mon 8th Sep 2008)]]></description><author>no@spam.com (Michael)</author><pubDate><![CDATA[Mon, 08 Sep 2008 14:20:52 CDT]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11929</guid></item><item><title><![CDATA[Comment #7]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11936</link><description><![CDATA[This is an excellent article and personally helped me out with a business need I recently ran into.  I post about it here: http://webdevarchitect.blogspot.com/2008/09/code-review-vol-6-injecting-javascript.html  and give you full credit for the methodology.  Thanks for this.<br/><br/>
(Comment posted by Tom Barker at 6:55 am, Tue 9th Sep 2008)]]></description><author>no@spam.com (Tom Barker)</author><pubDate><![CDATA[Tue, 09 Sep 2008 06:55:56 CDT]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment11936</guid></item><item><title><![CDATA[Comment #8]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12228</link><description><![CDATA[Good work..,<br/><br/>
(Comment posted by raja at 7:48 am, Tue 4th Nov 2008)]]></description><author>no@spam.com (raja)</author><pubDate><![CDATA[Tue, 04 Nov 2008 07:48:09 CST]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12228</guid></item><item><title><![CDATA[Comment #9]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12262</link><description><![CDATA[Great article! :)
How would I define the javascript in a Flex MXML app? I ask because I get errors on the end of the "var getProp_js :XML" section. It is because I have two CDATA closing tags. One to close the Script tag and the extra one that closes the XML block. The extra one is causing the error. 

I use: 
<code>
<mx:String id="getProp_js">
<![CDATA[
// CODE HERE
]]]]><![CDATA[>
</mx:String>
</code>

That works but if there is a way to write in AS it could be bindable.<br/><br/>
(Comment posted by judah at 4:51 pm, Wed 12th Nov 2008)]]></description><author>no@spam.com (judah)</author><pubDate><![CDATA[Wed, 12 Nov 2008 16:51:28 CST]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12262</guid></item><item><title><![CDATA[Comment #10]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12530</link><description><![CDATA[Excellent article that illustrates a pragmatic approach to dealing with some nonsense situations that exist these days. I want detailed information on the container around an SWF, track mouse wheel events correctly even on Macs and a lot more... I used to have to implement separate JS files for all such things even while the functionality imposed by these JS files ONLY affected the SWF and NOTHING else, in fact, NOTHING else could even benefit from it. 

In that situation, thinking I know everything by sticking to standards would just hold me back. JavaScript is JavaScript, but simply requesting information from the browser is not per se a JavaScript responsibility. For such encapsulated tasks that really only concern AND affect Flash <-> Browser, this solution is very adequate.<br/><br/>
(Comment posted by TFM at 4:13 am, Tue 20th Jan 2009)]]></description><author>no@spam.com (TFM)</author><pubDate><![CDATA[Tue, 20 Jan 2009 04:13:13 CST]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12530</guid></item><item><title><![CDATA[Comment #11]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12564</link><description><![CDATA[I've created what I think is a great argument for javascript injection. This article was indispensable.
As you may or may not know, YouTube's chromeless player is in as2 and cannot be controlled directly when loaded into as3. A work around is to utilize it's ability to respond to the youtube javascript api via ExternalInterface. While there's a decent .js/.as class combo available on code.google.com, I thought I'd make it a lot easier by having a single .as class handle everything making the round tripping through ExternalInterface completely transparent.

Check it out: http://code.google.com/p/as3-youtube-chromeless-api-proxy/

Btw, I actually interned with Peter way back in 1993. What a coincidence that he'd come to my aid this many years later.<br/><br/>
(Comment posted by Joel at 3:06 pm, Tue 27th Jan 2009)]]></description><author>no@spam.com (Joel)</author><pubDate><![CDATA[Tue, 27 Jan 2009 15:06:30 CST]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12564</guid></item><item><title><![CDATA[Comment #12]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12950</link><description><![CDATA[Great Article.  I spent days searching for a good read on the usage of ExternalInterface, and finally stumbled upon this.  Write some more!  Your article has a good flow, is easy to read for a noob like me, and explains every detail of what I needed to know!  Thanks again!<br/><br/>
(Comment posted by Josh at 1:36 am, Fri 1st May 2009)]]></description><author>no@spam.com (Josh)</author><pubDate><![CDATA[Fri, 01 May 2009 01:36:13 CDT]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12950</guid></item><item><title><![CDATA[Comment #13]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12959</link><description><![CDATA["If you don't like it, just set AllowScriptAccess to 'never'"

AllowScriptAccess is defaulted to "sameDomain" which can be exploited using ExternalInterface:

http://blog.guya.net/2008/09/14/encapsulating-csrf-attacks-inside-massively-distributed-flash-movies-real-world-example/<br/><br/>
(Comment posted by guya at 7:46 am, Mon 4th May 2009)]]></description><author>no@spam.com (guya)</author><pubDate><![CDATA[Mon, 04 May 2009 07:46:55 CDT]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12959</guid></item><item><title><![CDATA[Comment #14]]></title><link>http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12960</link><description><![CDATA["If you don't like it, just set AllowScriptAccess to 'never'"

AllowScriptAccess is defaulted to "sameDomain" which can be exploited using ExternalInterface:

http://blog.guya.net/2008/09/14/encapsulating-csrf-attacks-inside-massively-distributed-flash-movies-real-world-example/<br/><br/>
(Comment posted by guya at 8:14 am, Mon 4th May 2009)]]></description><author>no@spam.com (guya)</author><pubDate><![CDATA[Mon, 04 May 2009 08:14:28 CDT]]></pubDate><guid isPermaLink="true">http://www.actionscript.org/resources/articles/745/1/JavaScript-and-VBScript-Injection-in-ActionScript-3/Page1.html#Comment12960</guid></item></channel></rss>