It warms my heart to hear any discussion of ActionScript. A couple years ago I felt like I was the only one in the world not saying Flash is dead. Anyway, @senocular, brilliant as always. I appreciate your taking the time to respond.
I just looked at the article now, and that’s basically a more indepth version of what I’m saying now plus more approaches to take. The key takeaway is:
you can try but it is unlikely to cover 100% of the cases and it will take a lot of efforts.
It’s not impossible but it will really take a lot of hard work and unlikely to block 100% of all the “vilains”.
1 Like
I don’t think you can be too appreciative. I seemed to have missed this question the first time around 
Hi Senocular, e_v,
Thanks for the reply Senocular and for e_v thanks for the original question.
The thing is that I am going to try and implement that tutorial in actual code and I will post my progress here.
With your support ( especially Senocular’s support as he is the true expert ) and guidance we can try and approach a system as secure as is possible, maybe.
Any ideas are welcome from one and all !
Thanks !
Hi, I have a question. Would your above statement hole true if the flash player setting is as below: allowScriptAccess = 'sameDomain'
and the domain uses HTTPS as against HTTP.
If the answer is still yes, then what should be done aditionally to prevent cross-domain linking.
Thank you.
Again, if you’re talking about linking, then yes, it mitigates that. But that doesn’t prevent me from downloading your swf and hosting it on my own site. If I were to to that, then it would work because both the page and the swf are on the same domain.
… then again allowScriptAccess is defined by the HTML page, so yeah, I’d be controlling that anyway 
When I was in college I built something to do roughly what you’re trying to prevent: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.214.9092&rep=rep1&type=pdf
The goal was to make websites more accessible to screen readers, but part of the mechanism was to provide tools for convincing SWF files that they were running on an arbitrary domain of a proxy.
1 Like
Hi Senocular and krilnon,
Thanks for the replies.
Great !! I see that as a step forward unless Krilnon has some technique that can by pass this little protection.
The point is that if my website allows cross domain linking, then that would be an ideal choice for someone who wants to use the swf in another or their own domain. However if cross domain linking is not permitted by the domain/website, then the only option for a hacker would be to actually download and swf and then use it elsewhere exactly as pointed out by you.
So if this allowScriptAccess = 'sameDomain' effectively prevents cross domain linking we can focus on what should be done to make it as difficult for a anyone to get the working swf as possible.
@krilnon : Thanks for that input. I will go through your article in detail and revert soon with my queries if any.
Ok, I have read your article - pretty heavy i would think, and so i am not very clear. Therefore I ask you that if this would defeat the cross linking protection offered by flash player by setting value of allowScriptAccess. If so, then what additional step can be taken, if any, like maybe setting some additional properties of the Flash Player, or maybe via some server scripts, to foil the proxy servers attempt to hijack the swf and its data.
Thanks loads !
I’m not sure if you understand or not, but allowScriptAccess doesn’t help you. It helps other people linking to your swf from their site. Its used to protect them against any unwanted scripting coming from your swf, like your swf trying to steal cookies from the site embedding it. It doesn’t help you stop people from using your swf because it’s not something you control.
Oh great yet again ! I actually thought on both aspects and it did occur to me that this might be protecting the other party against our swf. That’s why I mentioned allowScriptAccess specifically and asked if it protects the domain cross-linking. Of-course I meant that if that setting somehow does not allow the swf on our domain to not run on an outside domain.
That means that we are back on the first point. How can we prevent our swf from running on another outside domain?
Thank you.
Thats where that link you posted comes in. It explains what you can do.
Hi Senocular,
Yes I was just reading that again. So there it says that it’s all about using HTTPS and ensuring that the the headers do not cache etc.
Also I do not understand this
But cURL has a little weakness, it does not interpret JavaScript in the HTML page,
so we gonna use JS to filter out any cURL, wget and other robots crawler.
How would this be implemented? any idea?
AND
Is this like enough to prevent the the swf from not playing in another domain ?
Thanks.
But cURL has a little weakness, it does not interpret JavaScript in the HTML page, so we gonna use JS to filter out any cURL, wget and other robots crawler.
I think that means if you inject your swf with JavaScript crawlers scraping the HTML won’t be able to pick it up. But that’s moot since pretty much all swfs are embedded with JavaScript now. Also in the previous code sample they were already using a direct swf link at which point HTML/JS doesn’t apply, but it is similar to another approach he mentioned, such as loading a child swf (cURL doesn’t load child swfs since it doesn’t run the swf it loaded).
But I’m going to throw this out there again:
you can try but it is unlikely to cover 100% of the cases and it will take a lot of efforts.
It’s not impossible but it will really take a lot of hard work and unlikely to block 100% of all the “vilains”.
So to answer your question, no. It will not completely prevent your swf from playing on another domain. Anything you do only makes it harder. The question is how much work do you want to put into it and how hard do you want to make it?
Approach: Prevent caching
Counter: (easy) People can download the swf directly through the url
Approach: Use htaccess you can prevent people from hotlinking to the swf your domain is hosting
Counter: (easy) People can download the swf and host it themselves (at least they’re not using your bandwidth)
Counter: (medium) Spoof the referrer to make the request appear to come from the original domain
Approach: ExternalInterface checking window location
Counter: (medium) JavaScript spoofing to fake the current domain
Counter: (medium) Use a tool to inspect and replace strings, such as domain paths, in the swf (requires resaving and hosting edited copy of the swf)
Approach: Use a parent swf to load your swf as a child
Counter: (easy-medium) People can download both once they realize a child swf is being used
Approach: Use a parent swf to load an encrypted child swf
Counter: (medium-hard) Depending on how its implemented, the key can be captured and reused with the same encrypted child
Approach: Write your swf only as a view for logic encapsulated on the server
Counter: (hard) Spoof requests to your server making it think its originating from your domain
Counter: (very hard) Reverse engineer your server interactions
Thanks for that detailed reply. I will take time to read in detail and research a bit on a few things that I am not sure about before I revert.
While my question is not directly in the context of the quote above, I am using that since you mentioned using JS to fake the current domain .
Would most of these methods that you mentioned use JS somewhere or the other ?
If so then I would like to ask that if a domain uses CSP ( content security policy) which does not allow inline javascript to run basically sandboxing js, how difficult would it make these counters that you have mentioned ?
Will revert after some research and thought on your reply.
Thank
Only the ExternalInterface one, and it does not apply to CSP which relates to cross-site scripting.
The ones I listed are about in order of easiest to hardest, depending on where your comfort is. The first two are server settings while the 3rd, with ExternalInterface, is in the swf, and probably gives you the most bang for your buck.
I think there’s value in using child swfs too, but I think anyone who’s in the business of stealing swfs would know how to get around that easily enough unless you did something a little extra that made that less trivial.
Hi Senocular & all !
@Senocular: Thanks for the detailed reply. I am still a bit confused on a few points which I would like to clarify. Please bear with me.
Lets assume that the flash file has been downloaded and de-compiled by a hacker. Now he can upload that into another domain (hacker domain) and serve it from there. The question is
a) what about the data that the movie requires to be run. This data is placed on the original server. Can hacker domain somehow get the data from original server in real time and server it to users from hacker domain to whomsoever? if so how and how difficult it would be.
b) if the original server uses secured sessions and user verification (via a login panel of-course) before serving the files , would the above (a) still be possible if at all ?
c) What if the hacker is also a legitimate user and is able to log in into the original server as a user? Or is that not a big deal ?
Thanks loads !
The more you do on the server the better. But you still have the problem of verifying that requests are coming from your client on your domain and not your client (or hacked version of your client) on someone else’s domain. Like you said, the hacker could make an account (if they’re easy to make) and bake those credentials into their version of your app and have it log in automatically with those when people go to the hacker’s site. There’s also cases where a hacker can actually load your website into an iframe in their website exposing only what they want to, making it look like your app (or a part of it) is running on their site. The link you posted has protections for this as well, but it’s another thing to consider.
But I really don’t know much about what you can do about that particular kind of situation (logins). I’ve never had to deal with it myself, and anything else I could add would just be me googling it 
I have been doing just that on the net myself !!
But your replies have been a great great help.
This can be thwarted using X-Frame-Options Security Header as mentioned here, to what extent I am still not sure 
Yes, so what is the way, if any, to accomplish this?
Trying to get the swf to identify that it is in fact running from the original domain / page can be spoofed, so is there a way to check the source of origin of the originating request using HTTP. Something that’s built into it and cannot be spoofed?
Thank you.
Saw this pop up today. Seems related:
https://www.twilio.com/blog/2018/01/protect-your-node-js-app-from-cross-site-request-forgery.html
Hi Senocular and all !
thanks for that link. I have used the tokens to prevent or mitigate cross site request forgery myself but that’s in php forms with submit buttons. I cannot figure out how that can be used in the case of flash. The data is transferred asynchronously on the completion of a task. I have no idea how it’s possible to use tokens in this case.
What is the security risk involved in sending and receiving data using the sendAndLoad() functions? I have found that the more I read about the security risks in swf, the more confusing it gets !! Besides that there are a whole lot of articles that talk about the various vulnerability issues in using flash, surprisingly there are but a few that try to address the problems and provide some solution! !
Thanks.