My webmaster has an online store on a site with ssl that i would like to feature on my site. He says this could be done with an iframe. Are there any security risks in using an iframe for this shop, in example a middle man attack? Or is this safe for any customers using it because the origin is protected?
Although iFrames are, in theory, loaded securely in their own environment, there are several security issues with them including:
They can be used for ClickJacking attacks. For example a site loads another website in an iframe and then floats username and password text boxes on top of the iframe so people think they are typing these into the website in the iframe, when in fact they are not.
It's not easy to see the website the iframe is loading. For example you load a frame of badbank.com and make it look exactly like goodbank.com. The user has no idea which domain has loaded as there is no address bar nor green padlock.
In general it's suggested for websites to prevent framing using X-Frame-Options or Content Security Policy HTTP Headers to prevent framing.
For sites like you doing the framing (rather than being framed) you are therefore risking your users. So if your site is hacked then this might lead to above issues. Additionally I've worked on a couple of sites where framing suddenly broke when the framed site prevent it from being framed anymore using above headers. Which looks bad on your site.
Finally framing breaks some of the fundamental ways of using the web (e.g. Back button).
All in all I would caution against iFrames.
Related
My website doesn't have a search input but it has hyperlinks to other sites should I worry about XSS(cross site scripting) vulnerability.
XSS can be not only in search input field =). Any input, which your web application outputs and does not perform filtration leads to XSS. If you have outdated JS libraries (e.g. old version of jQuery) - it can also contain vulnerable code and lead to XSS.
You should only link to websites that are secure and trusted. An example of a trusted website is one that uses https or one which is ranked high in Google.
If you link to an untrusted website, then its possible that when your visitors click on the link to the untrusted website, they are taken to a malicious website that serves malware or steals user credentials.
I have been reading a lot regarding iframes and clickjacking, and was not able to find the information I am looking for. Can you help me out with below questions?
How does Iframe clickjacking spread? I have seen lot of articles which mentions editing of html code in the local machine and by the same they are able to hijack users click by adding an invisible button. But, this is a modified logic on a local machine of a user. I am interested in knowing is it possible to push this same code to the cloud and impact every user logging in or using that portal? If yes, how?
If I enable Iframe options on my website, it is a security risk because my page can be loaded as an Iframe in some one else's website and they can misuse it. And if there is any secured data, if end user is accidentally entering on that website, the data is hacked. This is a security concern so it is always recommended not to allow Iframe, is that correct? Are there any other security risk.
Please add if there are any other risks.
Clickjacking does not spread.
It is literally as it is stated - jacking clicks - nothing more. However, the consequences of those clicks could be severe.
Imagine you visit a site, evil.example.org. In another tab you are also logged into your bank, bank.example.com.
evil.example.org also loads bank.example.com in an IFrame. However, it uses CSS to make this IFrame invisible. And it does not load the home page, it loads the money transfer page, passing some parameters:
<iframe src="https://bank.example.com/loggedIn/transferMoney?toAccount=Bob&amount=100000"></iframe>
Now, this page does not transfer the money immediately. It asks the user to click to confirm the transfer to Bob.
However, evil.example.org draws a button right underneath the Confirm Transfer button saying Free iPad click here.
Because the IFrame is invisible, the user just sees Free iPad click here. But when they click, the browser registers the click against Confirm Transfer.
Because you are logged into the bank site in another tab, Bob has just nicked your money.
Note that the X-Frame-Options header fixes this vulnerability on your site, assuming it is set to SAMEORIGIN or DENY. You are vulnerable until you add the header. There's a new directive in CSP called frame ancestors - however, only the latest browsers support it, so you're best off adding both headers at the moment. This will give you protection on Internet Explorer 8 and later, plus Chrome, Firefox, Opera and Safari.
Preventing framing can also help thwart over attacks such as Cross Site History Manipulation.
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 have a Java web application in domain A (that we control). This application displays another website located in domain B (which we do not control) in an iframe. This external website was recently updated to require users to log on before they can see content. They provided us with a URL that will automatically log our users into their site. This URL works when we navigate directly to it in Internet Explorer (we get automatically logged in etc).
However, apparently there was an update to Internet Explorer so that cross domain communication is not allowed. So now when the login URL is displayed in the iframe, it does not successfully log on (I am guessing its being blocked from creating security cookies).
Also, if we browse to the URL directly and get the security in place, then any iframe elements of the site will not work (I am guessing it is being blocked from accessing security cookies).
Does anyone know of a work around for this? Changing the security level on Internet Explorer is not an option (it is controlled by our company's system administrator). Internet Explorer is also our company standard, so we cannot change that (even though it works fine in Firefox).
When you say "elements of the site will not work" what precisely does that mean?
"Cross-domain" interactions have always been restricted in all browsers. This is called "same-origin-policy" and it's the foundation of web security. The "update" to Internet Explorer you're referring to restricts IE such that a webpage on Domain A can no longer navigate a subframe that is inside a page from Domain B. That restriction has been present in IE for 7+ years and is in all browsers. This restriction is not causing your problem.
This most likely problem here is that the subframe fails to set a P3P header that would permit its cookies to be stored. There are perhaps 30 duplicates on that issue on StackOverflow.
To determine if this is what you're encountering, try this:
In IE, click Tools > Internet Options > Privacy tab.
Set the slider to Accept all
Clear your cookies
Restart the browser and retry the scenario.
If this change solves the problem, then the fix is easy: configure the page which is being framed to specify its cookie policy using a P3P response header.
If this doesn't solve the problem, please update the question with more information that would allow others to reproduce it (e.g. traffic logs, live site URL, etc).
It turns out that this was causes by the login site not being on the trusted sites list. Having security add it as a trusted site and pushing that to all company computers solved the issue.
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.