Checking the URL to ensure the file is being viewed from my page

[senocular]

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

[ajoo]

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.

@senocular

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)

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

[senocular]

@ajoo

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 ?

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.

[ajoo]

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 !

[senocular]

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

[ajoo]

@senocular

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.

@senocular

There’s also cases where a hacker can actually load your website into an iframe in their website

This can be thwarted using X-Frame-Options Security Header as mentioned here, to what extent I am still not sure

@senocular

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.

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.

[senocular]

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

[ajoo]

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.