I have couple of .swf games files uploaded to my server. I want to run some test, but I dont want to expose or let public/others people to see our swf files. Currently, if I type:
www.domain.com/games/game1.swf
It will play the swf file.
I tried to visit some other flash game based websites. When I visit one of the swf files (e.g www.xxx.com/folder/flash.swf), it would redirect me to the homepage (www.xxx.com)
Is this the correct way to prevent public people to view my swf files?
There are a lot of swf-to-fla decompiler third party software, will my swf files secured?
Will my swf files being hacked/stolen (code and graphics)?
Once your swf files being hacked, will my website safe from web attacks?
How to secure swf files?
Please help
You have a lot of questions here.
When I visit one of the swf files ... it would redirect me to the homepage ...
I would suspect this is implemented by checking the 'HTTP_REFER', when loading the .SWF page. You could do this if you like.
Is this the correct way to prevent public people to view my swf files?
No. Depending on what server you're running, you should put some authentication on the folder '/TestSwfs', and then upload all your swfs to there, and you will need to log in first. Fairly simple to do this in both IIS and Apache, but let us know which one you are running.
There are a lot of swf-to-fla decompiler third party software, will my swf files secured?
I suspect not. There are probably SWF Obfuscators though, but they can still be reversed.
Once your swf files being hacked, will my website safe from web attacks?
It shouldn't matter. You should not be inlcuding secrets/passwords in your SWFs that you don't want to be public. You may be writing high-scores, and you can step up the complexity required by doing some crypto, or other such things, but really, for just high scores, it's probably not important.
Design your SWF code so that even if it was public, your server would be safe.
One additional point to Silky's answer.
You should implement REST Api correctly in your SWF, that will assume that even if someone can hack your swf (which is very easy), the can not login to your server and manipulate any data or bring it down.
You should never directly alter database by using direct apis, you should always use webservices instead of database connectivity tools.
Related
everyone.
I need to lock website for downloading via some windows tools and wget.
The site consists of js, html and php files.
I googled about security resource sharing, but it did not helpful for me.
Thank you.
As long as at the same time you need to have your website online available for everybody, this is not possible. If someone visits your site, the browser needs to access all files, in other words download them. You might be able to apply a few hacks to make it more difficult, but you can not prevent it completely.
If you want to restrict it to a defined audience, you can implement a login using for example HTTP Auth. How this can be achieved depends on your hosting. It might be doable using an .htaccess file in your web root or maybe through the admin interface of your hoster.
Your PHP file should be safe by the way, the above said applies to the public parts of your site (HTML/CSS/JavaScript/Images/...).
I need to design a mini website to give to clients. The site includes mp3s and videos which must be played within the site itself and not use any 3rd party media players. Is Flash the only / best solution?
I also need to protect these files. Is there a way that I can stop users 'exploring' the CD and not get access to the content?
Flash is a 3rd party component.
You might want to try experimenting with HTML 5 see the link below:
http://www.w3schools.com/html5/html5_audio.asp
This would make your websites functionality dependent on the browser the client is using.
It is unlikely you would be able to prevent users accessing the music files on the CD. Possibly you could store the data on the CD in an encrypted format and make your own custom active x control that decrypts the data on the fly. This would be difficult to do though. Do you mind if I ask why you want to distribute your site on CD? Why don't you just make a website and have user access control on it?
We have our application stored on our server, it is an .exe file. The download page is only accessible from our site - using cookie authentication in PHP. I know there are better methods but there is a long story behind this...so I'm moving on. The issue is that the actual url of the .exe has been leaked and is appearing on other websites. What is the best method to protect a link to a file, not the page itself. That is where I'm having issues. I can make it difficult to get to the download page (with the link) but don't know where to begin to make sure the link is only accessible from our site... Is .htaccess (preventing hotlinking) the best way to go?
Yes, .htaccess is probably best. Find any online post about protecting images from hotlinking, the first in my google search looks like a nice and easy auto-generator you can use. Just change the image extensions to exe, or keep them if you want them protected too.
I want to let users (i.e. anyone who signs up for an account) upload and download video and text documents. I have been researching the security issues regarding letting users upload files, but everything I can find on the subject assumes that users will only upload images.
Are there any security issues specific to letting users upload videos and text documents? Is security a lot more difficult when users can upload files at video size? Are there any particular file extensions I should look out for?
The problem is this: If you let users upload videos, images and text files, some of them will try to upload viruses, server-side scripts and other malicious code. Such code will then expose your site's users to what ever 'bad things' those users uploaded, within the context of your own site.
If you allow such uploads, you must be very careful that you are only saving files of the actual types you planned on - and not by looking at the file extension, either. You also must make sure those files are placed in locations where execute/script permissions are disabled.
Virus checking is a must - but it is not at all enough. A PHP script may not set off virus warnings at all, but that same script could reveal vital information for your site, or cause other bad things to happen if executed.
You must examine the content of the files - never rely on the extension or MIME type reported by the client. Those can easily be faked.
Serve your downloads from a location for which you have disabled the execution of server side code. This is all you need to do to protect yourself from server side exploits. Relying on file extensions or other such things are all hacks.
If you want to fully protect your users (and indirectly your website) as well, you'll need to run the files through a suitable virus scanner. It is possible, and there are real-life examples of doing so, to exploit video decoders and such software to run arbitrary code. But if you start walking down that line, you could also argue that certain text strings might set off weird behavior in certain software, and that starts getting silly. Luckily, the people who write virus scanners will have done most of the work for you. So:
Never execute that what is uploaded
If you feel it's needed, virus scan them as well.
You can virus check each file that is uploaded. If you look at most web based email clients you will see when you upload a file they are checked by McWhoever. In generally you shouldn't let them upload exe files but checking the extension is a very basic (unreliable) method.
It's quite hard to make an upload REALLY secure.
There are quite a lot of things to check - the file extension is just one part of it. Here are few things which have to be at least checked:
file extension (as you've already mentioned)
mimetype
filesize
depending on the users: maybe check the uploads with ClamAV ...
To answer your question here is a meta attack:
bad guy uploads a binary to your
server, perhaps tricking your
filters by compressing file and
changing extension to .avi
exploit bug in a CGI script to
decompress avi from #1
exploit bug in another CGI to
execute file from #2 -> backdoor
installed
backdoor accessed and rootkit
installed to hide all evidence of steps
1,2,3
Some variation on the above is what typically happens when servers are compromised.
I want to allow my users to embed their own Flash animations in their posts. Usually the actual file is hosted on some free image hosting site. I wouldn't actually load the flash unless the user clicked a button to play (so that nothing auto-plays on page load). I know people can make some really annoying crap in flash, but I can't find any information about potential serious damage a flash app could cause to the viewer.
Is it unsafe to embed just any flash file from the internets? If so, how can I let users embed innocent animations but still keep out the harmful apps?
edit:
From what I can gather, the most obvious threat is for actionscript to redirect you to a malicious site.
Adobe says you can set allowScriptAccess=never and allowNetworking=none and the swf should have no access to anything outside of itself. Will this solve all my problems?
Flash has some neat security measures in place. Allowing users to upload swf's to your site and embedding them is unsafe, you're basically setting yourself up for an XSS attack.
However, allowing them to hotlink should not be a problem. The swf will be locked to the domain that is hosting it and is not allowed calling url's outside of that space.
It will still be open to "evil links" (i'm sure theres a proper word for them), and by that I mean having regular links to yoursite.com/admin/deleteallpages.php which it tries to load "as" you. It will not however be able to use this data in any way, it'll basically be the same as a normal link, and I'd guess modern cms' are protected from that type of attacks.
You could get the same protection by hosting your flashes on a different subdomain, since flash considers this the same as a completely different domain.
When embedding SWFs from unknown sources, it is also best practice to throw a mask on the Loader so that the loaded SWF can't take over more screen real estate than expected.
Pseudo-code to do so:
var maskSpr : Sprite = new Sprite();
maskSpr.graphics.beginFill();
maskSpr.graphics.drawRect(0,0,safeWidth,safeHeight);
maskSpr.graphics.endFill();
myLdr.mask = maskSpr;
There is actually more than one option.
To be totally safe, set allowScriptAccess=never and allowNetworking=none and the swf will have no access to anything outside of itself.
NOTE: allowNetworking is only in Flash Player 9 (it was created in response to various myspace worms), so you'll need to use SWF Object to insure that only users with the right flash player version or better have the flash loaded.
If you want to enable things like youtube videos, though, you can't set allowNetworking to "none". Fortunately, there is an intermediate level of security for this field - "internal" which lets the SWF talk to its hosted domain.
Also note that you better not have a crossdomain.xml file on your site - read more about those dangers here and other places.
Here are some other sites that are mentioned by other answers that go into more detail:
http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps_04.html
http://blogs.adobe.com/stateofsecurity/2007/07/how_to_restrict_swf_content_fr_1.html
As an example Drupal has a scenario of how allowing flash content from users could be a security concern.
Adobe says you can set allowScriptAccess=never and allowNetworking=none and the swf should have no access to anything outside of itself. Although allowNetworking is only in Flash Player 9, so users with earlier versions of Flash would still be susceptible to some exploits.
Creating more secure SWF web applications : Security Controls Within the HTML Code
How to restrict SWF content from HTML
Yes, it's unsafe.
There's no easy way of allowing it. You could have a domain whitelist that allowed YouTube, Hulu, etc. through, but whitelisting is inherently painstaking - you'd be constantly updating.