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.
Related
I asked this question a little over a week ago on the Atom forums (link below), and didn't receive a response, so I am reposting it here in the hopes that someone may be able to provide insight on my problem.
Recently, I have taken up an open source project which uses Electron as it’s front-end. This project has two requirements: it must be cross-platform, and it must have an embedded web browser (which should be able to browse the web and render content like a typical browser). Considering the rather large footprint Electron has already netted my application, it seems like a bad idea to attempt to use another embedded web framework alongside it. So, in the interest of simplifying my project and retaining the UI built on top of Electron, I am looking into using Electron itself as the web browser. Here’s where I’ve come into a problem.
In a security page for Electron’s documentation, it is explicitly stated that,
it is important to understand … Electron is not a web browser
This quote comes within the context that Electron–or rather the code running on top of it–carries the unique ability to interact with the user’s operating system, unlike typical web applications. The page goes on to say,
displaying arbitrary content from untrusted sources poses a severe security risk that Electron is not intended to handle
At this point, I was tempted to give up on the idea of using Electron as an inbuilt browser, but further down on that same page, you can find another very interesting tidbit:
To display remote content, use the <webview> tag or BrowserView , [and] make sure to disable the nodeIntegration and enable contextIsolation
Link: https://electronjs.org/docs/tutorial/security#isolation-for-untrusted-content
First, in regard to using webviews, Electron’s own documentation recommends outright avoiding them:
Electron’s webview tag is based on Chromium’s webview , which is undergoing dramatic architectural changes. This impacts the stability of webviews , including rendering, navigation, and event routing. We currently recommend to not use the webview tag and to consider alternatives, like iframe , Electron’s BrowserView , or an architecture that avoids embedded content altogether.
Link: https://electronjs.org/docs/api/webview-tag
Seeing as though I cannot avoid embedded content, I opted to look into using a BrowserView, but what I found was not very motivating either. The advice, as it stands, is to do two things:
disable nodeIntegration
enable contextIsolation
After looking at the security and best-practices page, I will also append the following steps:
deny session permission requests from remote content (webcam, microphone, location, etc.)
catch webview elements in creation and strip default privileges
disable the creation of new windows
disable the remote module
That is a fair amount of steps to undergo in securing external content. Not to mention, there were several additional warnings scattered through the best practices page such as the following:
(On verifying webview options before creation)
Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
Link: https://electronjs.org/docs/tutorial/security#11-verify-webview-options-before-creation
(On disabling the remote module)
However, if your app can run untrusted content and even if you sandbox your renderer processes accordingly, the remote module makes it easy for malicious code to escape the sandbox and have access to system resources via the higher privileges of the main process.
Link: https://electronjs.org/docs/tutorial/security#15-disable-the-remote-module
Not to mention, upon navigation to the BrowserView page, the whole class is listed as experimental.
This all isn’t even to mention the added attack surface created by Electron, such as a vulnerability in the webview component just last year: CVE-2018-1000136
Now, taking into account all of the above, numerous developers have still opted to create web browsers that routinely consume external and uncontrolled content using Electron.
Browser’s using Electron (linked directly from Electron’s website):
https://electronjs.org/apps/wexond
https://electronjs.org/apps/dot
https://electronjs.org/apps/beaker-browser
To me, it seems irresponsible to submit users to the above security implications as a trade-off for convenience.
That being said, my question is: can you safely, to the point at which you could ensure the integrity of your users, implement web browsing capabilities for uncontrolled content using Electron?
Thank you for your time.
Link to the original post:
https://discuss.atom.io/t/security-implications-in-electron-as-a-web-browser/70653
Some ideas that don't fit into a comment box:
[the project] must have an embedded web browser
So I presume then that this project isn't just a web browser. There's other content there that may have access to Node, but you just want the embedded-web-browser portion of it to be sandboxed appropriately, right?
Regarding the comments about <webview>, yes, it is considered unstable and Electron recommends using a BrowserView instead. I don't think that the fact that it's marked as "experimental" should necessarily deter you from using it (especially considering that the Electron team is recommending it [though maybe as the best of two evils]).
Experimental doesn't imply it's unstable. It can just mean that the Electron team is experimenting with this approach, but this approach may change in the future (at which point I would expect Electron to provide a transition path forward). Though this is one possible interpretation and ultimately Electron would have to comment on this.
The advice... is to do two things:
disable nodeIntegration
enable contextIsolation
I would also make use of the sandbox option inherited from BrowserWindows. BrowserView's docs on the constructor options say:
webPreferences Object (optional) - See BrowserWindow.
which tells me that BrowserView accepts the same options as BrowserWindow.
You would set it up like so:
new BrowserView({ webPreferences: {
sandbox: true,
nodeIntegration: false,
contextIsolation: true,
preload: "./pathToPreloadScript.js"
}});
See more information about this approach here. The preload script is what would expose some Node IPC APIs to the sandboxed content you're loading. Note the Status section at the bottom, which says:
Please use the sandbox option with care, as it is still an experimental feature. We are still not aware of the security implications of exposing some Electron renderer APIs to the preload script
If the content you're loading in the BrowserView never needs to communicate back to the application, then you don't need a preload script at all and can just sandbox the BrowserView.
After looking at the security and best-practices page, I will also append the following steps:
deny session permission requests from remote content (webcam, microphone, location, etc.)
catch webview elements in creation and strip default privileges
disable the creation of new windows
disable the remote module
Sure, those sound reasonable. Note that if your embedded browser needs to be able to open new windows (via window.open or <a target="_blank" />) then you'd have to allow popups.
That is a fair amount of steps to undergo in securing external content.
Sure, but is your main concern with the security of the app, or with how much work it takes to make it secure? Browser developers need to consider similar things to ensure webpages can't get access to the OS. It's just part of the game.
Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
This is just saying that if all you're trying to do is display a website, then just use a browser since that's what they're there for.
If you need to do other things, well then you can't use a browser, so you'll have to make your own app, making sure it's reasonably secure.
I think that if you follow what's recommended in the Security document and keep up to date with new Electron releases, then you're doing the best you can do.
As for whether that's good enough, I can't say. It depends on what you're developing and what you're trying to protect against.
However, my thoughts can't substitute the more expert opinions of those on the Electron team. This question could certainly use some guidance from them.
I was wondering if it's possible to capture a screenshot and/or record my computer screen(s) via a website?
If it is possible, what languages would I need to learn/code? I already have intermediate knowledge of HTML, CSS, JavaScript, jQuery, and PHP.
In other words: I want to have the ability to capture/record my screen (not the website) via using a website (not an application).
Thanks!
This is not possible. Web sites are very deliberately given only restricted access to your computer for security reasons. Imagine the havoc that could result if a malicious web site were able to see and capture what was on your screen--banking information, your confidential e-mails, etc. Even if the user had to give permission for this level of access, it would still be way too easy to trick a user into giving that permission.
The closest I could find/think of was http://www.screencast-o-matic.com/screen_recorder, but even then you have to download a launch plugin. I agree with #DLH. This is for your protection.
My favorite screen recorder is ScreenPresso - it is always running in background, and repurposed the PrtScn button as its launch key.
I'm currently doing front-end development for an insurance companies client portal and one of their developers is concerned about using typekit for security reasons. Does anyone know if there is a legitimate risk in using typekit on secure sites? Also, if anyone has some documentation on this that I could send to this developer that would be really helpful, I (surprisingly) wasn't able to find anything on the typekit site that would put his mind at ease.
Thanks!
There are different ways of including Typekit fonts. When you host your own CSS with #font-face rules pointing at font files on Typekit servers that's generally fine.
In this case Typekit will receive the URL of the page the user is browsing as a referrer, but there should not in general be sensitive information in the URL so that should be OK. (That may not be true if you have something like a reset password link - if you do, take care to ensure such URLs can only be accessed once so the ID in the link is worthless afterwards.)
However there is a variant where you include a script tag pointing at them:
<script type="text/javascript" src="https://use.typekit.com/some_id.js"></script>
This is a bad idea if your site does anything sensitive, because it gives typekit complete control over everything a user does on your site. If they went evil (or were compromised), they could steal any passwords typed on your site, delete all the user's data on the site, redirect the user to browser exploits, and so on.
In general you should never include remote scripts or stylesheets from anyone you don't 100% trust with the security of your site.
Any time you embed content, whether it be JS, CSS, fonts or anything else, from an external source to a sensitive page, you're increasing your attack surface. This does not necessarily mean that there is, or will be, a specific attack, but it does create more potential ways in which your site could be compromised.
Indeed, there have been real-world attacks using web fonts even without JavaScript, both based on browser / OS bugs and simply based on interactions of deliberate browser features. The Firefox security extension NoScript blocks CSS #font-face by default for that reason.
If you want to use a custom font on your secure site, the safest way to do it is to host it yourself — either on the site itself, or, perhaps better yet, from a separate no-cookie domain which is under your control, but isolated from your main website content by browser same-origin policies.
I am using twilo client in one of my apps and it is showing following popup when I click on call button
But I want to show the following pop up which is lot simpler and seems less cumbersome
Is there a way to control which pop up comes on the screen? I have read some documentation of adobe but their configuration files live in users computer which ofcourse can not be changed by a website.
Any help will be really appreciated
Yeah, those dialogs are native Flash Player dialogs. The request domain is drawn from the domain that the swf is loaded in, and it must be for security reasons. The only way around this is to have the request come from a swf which is loaded from a "friendlier" domain.
Sounds like something that Twilio would need to address, not you. Perhaps you can bug them on their forum or such?
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.