The caching of the file comes into play because the actual data that Mr. Evil will be able to see and change is the source code of our HTML files and any cached flash files.
(I’ll expand on this below)

However the actual data he will see is the “loader” file and not the “real” file. Eg. the movie name parameter in the object tag we use is the name of the “loader” swf.
If Mr. Evil puts another value in that parameter to load his file, our “real” file will never get loaded. And his file would have to be an exact representation of our “real” file in order to fool our server and our users, this is nearly impossible because Mr. Evil does not even know the name of our “real” file let alone the code within it. (refer to my previous comment)

Now, the code within our “real” file, therefore, must be married to our HTML page.
So that if the code in the HTML is not what it is supposed to be or if the “loader” was never called
the user will see no flash data or be alerted of the change.

This is the most complex step three, which I must add does not work on every system.
Step three is simple to implement if all Mr.Evil tries to do is swap out the file he can see with one of his own.

Before I explain the third step let me talk about how Mr Evil can actually see our data.
(I’m not well versed on how its actually changed)
(but now I will expand on what I said earlier)
In a packet sniffer when a flash file is called upon and given to the browser from the server the data is truncated and hard to understand but the active-x headers go with it and this is how Mr. Evil can know a flash is being transmitted.
When using the non-cache methods (in my previous comment) the transfer of such a flash is even more truncated and in fact it does not resemble a standard cached flash passing threw at all.
So Mr. Evil would have to be one of the craftiest and smartest hackers in the world in order to see everything clearly from just looking at the packets…but lets assume he is that smart.

Now, if Mr. Evil passes his malicious swf where our “real” swf is being transmitted the marriage between the HTML and the flash will be broken because the code inside our ‘real’ swf will no longer go out to the HTML page.
If he only changes out the “loader” swf
the HTML page can realize this.
(this is assuming Mr. Evil is not doing any real-time attacks although using xml sockets one can have a real-time relationship with the page)

If Mr. Evil changes the actual HTML source code.
He has complete control of our site anyway and there is no real defense against this except to stay away from simple looking flash files that are easy to recreate, and to use HTTPS.
Also against this one must rely on flashes that call upon other flashes,(my other comment)
if Mr. Evil changes the whole HTML code and loads his own swf, that ‘evil’
swf will not be able to load subsequent files, because Mr. Evil does know the names of those files. He would have to create his own flash file system in order to fool our users. But he would not have our images or swfs to use in order to do this. (he would have to rely on screen captures or something else which is normally of far less quality than the originals)

Alright let me just explain step three from easiest to hardest, theres no better way than just to explain the steps and I feel I’m rambling on.

easy step three:
(doesn’t guard against all possibilities eg. full HTML code takeover)
basic javascript flash swap guard:
(steps one and two are generally outlined in my previous comment)
now our “loader” file is the actual file
in our source HTML, in the object tag,
so its url is for example myflash.swf,
however when it replaces itself with the “real”
swf the new url of the flashes root accessible by the DOM object will be the url used to load the “real” swf for example loader.php?other
(this url should not include the letters swf)
so with javascript we can setup a function to look for the root url of the flash which should not be
myflash.swf after the “real” flash has been loaded. (this function will need to be on a timeout to give the real swf a chance to load)

If Mr. Evil swaps out the “loader” swf for one of his own and that evil swf does not load our “real” swf,
(the call to loader?other can be seen and Mr. Evil can put this call in his evil swf, but by doing so
it will replace his evil swf with our “real” one
making the attack useless)
the url of the root will be wrong and js can alert the user that the file seen is not the correct one.

To actually do this requires some crafty try catch statements in relation to the way each browser sees the flash object. And one must also use the most modern way to embed flash, which does not use the embed tag at all but rather includes the data parameter for non MSIE browsers.

The JS method used for this is TGetProperty(“/”, ’15′)
(you must use a var that stands for 15)
this method has been around since flash 4.
More info can be found on Adobe.com, although the info is old and hard to find. Try searching for the old Macromedia notes “flash calling methods from javascript.”

As you can see “easy” step three is somewhat involved. To make the system more secure your “real” flash needs to also have a marriage with your server side code. I will not get into it now as i have typed alot already and I’m refraining from writing any actual code here, but the tactics are similar to the js method.

All in all those reading this blog should come away with the fact that true security on the web means a constant HTTPS connection(period)

However using flash correctly can add some security in case you can’t afford HTTPS (like most of us)

I hope I’ve helped a bit.
Please note that some of these methods are brand new 2009 stuff.
What I’ve coined as strict flash 0.0
and the pigindyserf method will be published on the web soon for all to learn in detail.

I’m not sure I follow your comments completely, but I think that what you’re describing won’t protect from the kind of Man-In-The-Middle attack I’m describing.

First off, the attack has nothing to do with the cacheability of the Flash file. It has to do with the fact that Mr. Evil controls a router that is in between your browser and the server with the HTML page that is serving the Adgregate ad.

If that HTML page is served over HTTP, Mr. Evil’s router can change the page’s code completely *before it gets to your browser* and have the page load whatever Flash file Mr. Evil wants you to load. That Flash file could be from adgregate.com, but it could just as easily be from http://www.evil.com or anywhere else, and the user will be none the wiser.

I can’t really see how changing Flash cacheability or keeping the Flash file name hidden would mitigate this sort of attack. Can you help me out?

“If the host page is HTTP, then Mr. Evil can swap out Adgregate’s Flash ad for an ad that looks exactly like it but sends all of the info to Mr. Evil’s server, not to Adgregate. Users will be none the wiser until a laser death ray shows up on their MasterCard statement.”

Now, the above quote is true because Adgregate’s flash is cached, that is how Mr. Evil can get it and swap it out.

It is possible however, to hinder the cacheing of your flash files.
This is done by calling that flash file via your favorite server code, and first giving no cache headers before printing out the binary flash data.

It is not possible to put a flash on an html page via any server code directly (although php as whats called ming that is heavily outdated) so you must use a “loader” or “dummy” flash to call out to the server via the loadvars class or loadclip class.
The “loader” flash replacing itself with the called flash file.
In this way the only file that gets cached is “loader” flash.
Now, its not good enough to have the file not be cached. The files name must also be effectively hidden from Mr. Evil.

To accomplish this the call to the server code that will print the “real” flash needs to be coded or encrypted. You can simply make the call to the server be like: loader.php?myfile.swf,
but inside loader.php myfile.swf really stands for
realfile.swf…of course there are code security issues one must deal with in regards to whatever server side code you use. And it would be wise to use some sort of encryption on both the fake and real filenames making it even harder for Mr. Evil.

My explanations are brief and do not cover every detail but I hope that you can draw a general idea of the methodology.

So using these two methods one can 1. Make a flash not cached by the browser (and therefore not decompiled by decompilers) 2. Keep the real name of the file hidden completely (from the browser and any sniffers)

A Flash form based on this system is far superior to the standard HTML based form.

To see an example of the no-cache methods being used to not cache images loaded by a swf you can visit http://www.achronicleofike.com

I totally agree. Many sites, like Amazon, allow access to parts of the account that they don’t consider to be confidential (i.e. browsing history and “you may be also interested in product X” recommendations) over HTTP, while reserving HTTPS for all important information (usernames, passwords, CC#s, addresses, etc.). I think this is a reasonable compromise.

Websites that use HTTPS exclusively for login and then HTTP for the rest of the site will still have the cookie being sent in the clear. A MITM monitoring the network will simply wait for the user to login and then grab the session cookie. Once the attacker has the cookie, they can use that within their own browser to interact with the site as the user. The attacker will not have access to the username and password but will have complete access to the site as the victim user for the lifetime of the cookie. Banking sites and other sites that value security are hosted entirely over HTTPS and mitigate this problem by setting the “Secure” flag on any cookie that is sent. This flag causes the browser to only send the cookie over HTTPS and never in the clear.

Active MITM attackers can also modify the HTTP page directly and insert malicious Javascript that would execute in the context of the site. This Javascript enables the attacker to interact with the site as if they were the user. See BEEF for an example of how sophisticated this form of Javascript attack can be.

HTTP should never be used for any site that wants some form of provable security. HTTP provides no integrity or confidentiality guarantees and it is impossible for the browser to distinguish between interactions with an attacker and with the legitimate site.

For more information on proper session management and some of the pitfalls, read Chris Palmer’s excellent whitepaper: http://www.isecpartners.com/files/web-session-management.pdf

I think I successfully illustrated the point that these vectors are non-intuitive for your average web dev.

While it’s true that the Flash could be served up over HTTPS, that doesn’t matter because Mr. Evil can change the HTTP page that includes the Flash to pull the Flash from anywhere he wants, including Mr. Evil’s website.

The problem is still not solved because the Flash control’s *hosting page* is not secure.

Cheers,
Sasha.

In theory, since flash is sandboxed, it doesn’t matter what’s going on in the surrounding page. I wonder if the same principle holds for iframes.