Is it reasonable to assume that if I check the URL via ExternalInterface.call("window.location.href.toString"), the first characters should match “http://mydomainname.com” if that is where I’m hosting my game? I’m trying to keep other sites from embedding it, but I don’t want to break it either, if, for instance, it’s possible for the URL to have other characters before “http” in certain circumstances (I don’t know what those might be–other countries?). I could just check to make sure the URL includes “mydomainname.com” but that doesn’t seem as secure (someone might be able to include that in a directory name). Any advice would be appreciated.
I have this very same question that I would like to ask. 
If you have found a solution to this elsewhere I would be grateful if you updated it here.
Thanks,
Checking window.location should give you some basic protections, but there are ways around it. Of course there are ways around just about anything. If you’re really concerned there is probably a more advanced approach, but you’d have to google for one (I can’t think of any particular approach offhand).
Hi Senocular !
Thanks for the response. Yes flash security is as always a concern. I have just returned to some functionality I developed and I was hoping for some new information on the subject but looking at the dwindling number of security questions in the forum, it seems that people have almost given up bothering about it.
Anyways I came across an interesting article on the subject of flash files security which seems really detailed and I am trying to implement as far as possible if only as an exercise.
What I have been hunting for and would currently like some help on is how to check the URL of a domain using AS2 ( since I have used AS2 in my little project ). For AS3 they have used classes and URLRequest function. I am looking for the AS2 equivalent.
Is using
ExternalInterface.call(“window.location.href.toString”)
the way to go about it. Is there no equivalent of URLRequest in AS2? Anything else that anyone may like to add to this, most welcome.
Could you elaborate a bit on this.
I have been searching the net and the linked article is the closest to a perfect answer ( I think but I may be wrong) I could find.
Thanks all !
URLRequest is something completely different from ExternalInterface so I’m not sure what you’re asking for there.
As for getting around things, anything that’s handled client-side is potentially at risk. This makes content protection (which is a little different than security) difficult to manage. People used to like blocking right-click on websites to prevent people from downloading images, but there are plenty of other ways to download images, so that only works up to a point. Same goes for the location check. I could put this on my website and get your SWF to work on my domain istealthings.com
String.prototype.toString = function () {
if (this == window.location.href) return 'http://mydomainname.com';
return this;
}
1 Like
You mean this code snippet that you have provided. Sorry, but the istealingthings.com, kinda confuses me. I googled for it but it says site not found so I guess you are referring to it as the site from which you will invoke the snippet.
Are there not ways to prevent cross-domain linking? If a site does not permit X-domain linking would this snippet still fool it to work on another site?
Thanks you.
Right, istealingthings.com is just an example domain that’s meant to not be your, also example domain, mydomainname.com. What I’m saying is that my code snippet in the web page of any domain that’s not yours will fool the ExternalInterface call and make the SWF work there.
I’m not saying there aren’t ways. There ARE ways, and ExternalInterface is one of them. But most, if not all, can be subverted.
If you’re just worried about cross-domain linking, that can be set up on the server through htaccess (or something similar). But most of the time, when people steal things, they’ll copy the SWF and host it themselves in case you take your copy down or change the URL. I have a Mii Editor out there I did in Flash that is all over the web now even though I had to take the original down due to a cease and desist from Nintendo. People had the copy and hosted it themselves.
1 Like
Please enlighten !!
As i see it there are two ways the content can be hijacked. One is the cross domain that you say can not be blocked using ExternalInterface or at least not in the way I think since your small snippet will blow it.
So how to best protect against cross-domian linking?
Second of course is that the copy of the code can be picked from the browser or host computer or the ram of the PC. For that code encryption and code obfuscation are suggested but those two can also be defeated and that too i guess with not much effort.
So what’s should be the best defence against that?
What do you think of the article that I linked to in my earlier post, if you had the time to peruse it.
I would definitely like to know what is the best working solution to this dilemma.
Thanks loads !
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.