Question: I understand some websites don't allow themselves to be iframed. Question is, I own the website that I'm trying to iframe, so is there a setting where I can "allow iframing"? Would it be in wordpress? Godaddy? Here's the iframe of my site that I am trying to put somewhere else (doesn't work):
<!DOCTYPE html>
<html>
<body>
<iframe src="http://www.warlordmarketing.com/" height="2000" width="1000"></iframe>
</body>
</html>
Again, to clarify, I don;t mean my site allowing iframes to be placed on it. I mean allowing iframes of it to be placed elsewhere.
Sometimes iFrames are disabled as a mitigation against clickjacking attempts. It can be done in any number of ways. Here is a short list:
Content Security Policy (CSP) frame-ancestors directive
X-Frame-Options Response Headers
Legacy Browser Frame Breaking Script
In order for your site to be framed, all of the above mitigations would need to be disabled.
Also, if your site requires session cookies, the end user will have to ensure that third party cookies are enabled. Safari has them turned off by default.
Related
I am building an app which wraps some content in html. The users will be able to download this html file and view the content (which changes dynamically based on time and a few details fetched from our servers.
I would like to know if there is any settings on browsers that can block https:// requests from file:// urls?
It works by default, I am just concerned if there is any way users can do this. (browser settings, security zones or something like that)
I believe there is no code samples required for this.
There are windows group policy settings that can block browser downloads, but I'm not aware of browser specific settings. Here are a few links:
http://www.grouppolicy.biz/2010/03/group-policy-setting-of-the-week-18-allow-file-downlaod-internet-explorer/
https://serverfault.com/questions/362974/how-can-i-disable-download-from-all-browsers-using-group-policy-for-domain-users
https://superuser.com/questions/578276/can-i-block-all-file-downloads-in-chrome
I want to embed external content on a website in an iframe. I can only load internal websites and external are undefined.
How can I enable CORS in Intershop 7.7 and load an external URL in an iframe or data dialog?
There is nothing special in using iframes in Intershop compared to another platform. Simply put in your ISML:
<iframe src="https://example.com">
</iframe>
Of course this may not succeed to load as you noticed. Some servers include the X-Frame-Options header with value e.g. SAMEORIGIN which instructs the browser that they don't want to be framed on other sites. This may be used to prevent clickjacking attacks. You may use Firebug or any appropriate tool to monitor for such errors during the frame load. An iframe may also not load if you mix http/s traffic.
If you want to programatically access content from an iframe on a different domain, you may use the Web Messaging API (window.postMessage and the onmessage event) to communicate between the page and the included iframe.
In summary:
you can't simply frame any site (maybe your 'internal' site permits that);
this question is not relevant for the Intershop technology stack;
This should be possible with the content security policy support since version 7.6.
Please check the documentation of appserver.properties file. The keys intershop.response.content-security-policy. should help.
I've loaded Disquss on my Wordpress website, which is running on HTTPS. The problem is that while the comments are shown at the bottom of the webpage, they are white (and since the background of the page is also white, they are not visible).
If I open Inspector in Chrome, the following error is printed to the Console tab.
Refused to execute inline script because it violates the following
Content Security Policy directive: "script-src https://*.twitter.com:*
https://api.adsnative.com/v1/ad.json *.adsafeprotected.com *.google-analytics.com https://glitter-services.disqus.com
https://*.services.disqus.com:* disqus.com http://*.twitter.com:*
a.disquscdn.com api.taboola.com referrer.disqus.com *.scorecardresearch.com
*.moatads.com https://admin.appnext.com/offerWallApi.aspx 'unsafe-eval'
https://mobile.adnxs.com/mob *.services.disqus.com:*". Either the 'unsafe-
inline' keyword, a hash ('sha256-...'), or a nonce ('nonce-...') is required
to enable inline execution.
This happens because of the Popup Blocker Extension in Chrome, but I would like to enable it with content security policy: http://www.html5rocks.com/en/tutorials/security/content-security-policy/ . Basically, the error occurs in the chrome-extension://* scheme, so I need to add an appropriate entry to the Content-Security-Policy to allow chrome extensions.
How should I disable the security policy for chrome extensions?
This isn't something you can (or should) meaningfully solve. It's up to the extension vendor to properly implement themselves. The fact is the extension is attempting to inject inline code and it's being stopped by the Content Security Policy because the CSP is made to block it. As it should, since the extension is indistinguishable from malware from it's perspective.
You could (but should not) simply add rules to your site's Content Security Policy to allow the extension to run...but this is potentially dangerous, incredibly case-specific, and should basically only ever be done in an enterprise context in which everyone has a (poorly coded) browser extension that is required to work with your site. And even then re-coding the extension would generally be preferred.
How should I disable the security policy for chrome extensions?
Not. Additionally you can not.
I need to add an appropriate entry to the Content-Security-Policy to allow chrome extensions.
The CSP of extensions is part of the (local) extension.
while the comments are shown at the bottom of the webpage, they are white
Sounds like a matter of CSS to me ... what about color: black; for your text?
Or short: Websites are not able to mess with extensions. Which is good - I don't want facebook to disable my CSP and send my personal porn preferences (from PornLiner addon) to my profile.
I thought I have somehow found a solution to the very vexing problem with Firefox and CDN-hosted fonts access, but here comes IE9.
I recently found a very frustrating issue with IE9 caching problem, and chanced upon this blog post (IE9 Redirect Caching Nightmare) which enlightened me more about the actual issue.
I have to admit that I'm not sure whether the above mentioned is actually the issue, but it seems close enough.
Problem:
I have a website set up with 2 domains(base domain and subdomain) pointing to the same server, serving the exact same website which is using a same set of resources from a CDN hosted on Amazon S3, served by Cloudfront.
https://example.com
https://www.example.com
I get these kind of error messages in my IE9 developer tools console when loading fonts from my CSS file using #font-face:
CSS3117: #font-face failed cross-origin request. Resource access is restricted.
This happens when I loaded either of the URL first, then visiting the other second. IE9 is not running in Compatibility Mode. It running is in Document Mode: IE9 Standards.
From my limited understanding of the CORS and the need to set Access-Control-Allow-Origin HTTP header, I have dutifully set it up in S3 CORS policy, and it works perfectly fine with Firefox.
Requests from both domains, will get their respective header when requesting the CDN resource.
It seems that IE9 tried to do some optimization with caching, and cached the redirect too.
This causes a problem as the Access-Control-Allow-Origin header is cached as well. Without sending a request to the CDN server, the Access-Control-Allow-Origin header cannot change for different domains.
So I'm left with a situation where the request is from https://www.example.com and yet the Access-Control-Allow-Origin is https://example.com. This leads to the restricted resource problem with the error message above.
Further look: I did a check with Firefox 19, the above situation actually occurs, but it does not encounter the same strict restriction as IE9. Subdomain (https://www.example.com) requesting information will accept the access-control-allow-origin of the main domain(https://example.com). Chrome (Webkit) doesn't seem to care. I'm at a loss about which browser's behaviour implementation is correct.
With my current settings in the CDN, it seems like Chrome and Firefox, automatically reroutes allwww subdomain requests to the main domain. Only upon multiple attempts of inputing the www subdomain in the address bar, then will Chrome and Firefox obey. IE9 on the other hand, just goes to whichever address is typed in the address bar. IE9 seems to be the odd one out here, but I'm not sure which browser's behaviour is actually correct.
From a usability standpoint, Chrome and Firefox seems to be the "correct" behaviour.
Known Possible Solutions:
Set Access-Control-Allow-Origin header to allow all, i.e. *
Turn off caching in the browser
Redirect one domain to the other
Use query string to differentiate different domain calls for resource
Embed the font into the CSS as data-uri
For solution 1, let's just say I'm paranoid that I just want to set specific domains to allow.
For solution 2, is not optimal if I were to set it for all browsers, also my site has to run on mobile devices with usually less-than-desirable download speeds.
For solution 3, possible, but I'm still curious for solution to deal directly with the IE9 caching issue.
For solution 4, it is very hard to implement especially when the resource is called from #font-face. Does it mean that I'll have to dynamically re-generate the CSS for different domain calls for the different line just to load a font to bypass the issue? Seems to defeat the purpose of CSS itself, and caching resources for that matter.
edit: Stylesheet works, font-loading doesn't.
For Solution 5, it is tedious for maintenance and updating, especially when there are changes to the font files periodically.
Question: Are there any known ways to deal specifically with IE9's redirect caching behaviour in this particular case?
Answers and comments are very much appreciated. Thanks in advance!
Edit: More browser test information.
Solution 1:
Check this question.
Solution 4: rename your CSS file to style.php and use whatever code you need to call the appropriate resource.
Set the content type at the top of the page.
<?php
header("Content-type: text/css; charset: UTF-8");
?>
More info about style.php from Chris Coyier.
We discovered the same weird behavior also in IE10 and IE11.
Resetting the browser cache makes the fonts to be loaded without any problem. Also enabling and disabling compatibility mode.
But when switching to another subdomain, IE does not render the font because request header does not match the response header which is still the URL of the last request. And IE always shows the full URL for even if the definition on the bucket is *.ourdomain.com
So the general issue with allowing cross origin requests to assets like webfonts was solved by adding CORS permissions to the S3 Bucket - that made the webfonts work perfectly in Firefox.
But we still have no idea how to avoid * and tell IE not to cache the response headers.
We have a web page containing an iframe containing a page sharing an authentification cookie with it's parent page. For example the iframe page is on the domain foo.domain.com and the page containing the iframe is on foo2.domain.com. Both share a cookie from domain.com. Authentification works great, but the problem is with ASP.NET in IE7, we always get a javascript error:
Access is denied.
ScriptResource.axd
We are using ASP.NET 3.5, we use Ajax Control Toolkit also (latest version 3.0.30930.0). The problem doesn't occur for IE8. No problem in Firefox and Chrome also.
Anyone encountered this problem before?
If there's a DNS redirection IE7 can have issues, e.g. if http://site.domain.com is really http://www.domain.com/site, the transparent DNS redirect has issues in IE7, but not the other browsers you mention. IE7 treats this as a cross-domain script and blocks...you just get Access Denied.
Is this the case, or something similar with redirects or different domains? If you can test the main page as just domain.com/ do you get the error? IE7 treats a child differently than a sibling.
In JavaScript you might need to change the document domain. It's possible IE7 is looking at the domains all the way to the server level: foo.domain.com != foo2.domain.com. IE8, et al, are likely taking the document domain at face value of *.domain.com.
Here's a quick related blog article on it: http://jszen.blogspot.com/2005/03/cross-domain-security-woes.html.
To copy the code though, adding the following to both pages should get it rolling again.
<script type="text/javascript">
document.domain="example.com";
</script>