I am developing a web page that needs to display, in an iframe, a report served by another company's SharePoint server. They are fine with this.
The page we're trying to render in the iframe is giving us X-Frame-Options: SAMEORIGIN which causes the browser (at least IE8) to refuse to render the content in a frame.
First, is this something they can control or is it something SharePoint just does by default? If I ask them to turn this off, could they even do it?
Second, can I do something to tell the browser to ignore this http header and just render the frame?
If the 2nd company is happy for you to access their content in an IFrame then they need to take the restriction off - they can do this fairly easily in the IIS config.
There's nothing you can do to circumvent it and anything that does work should get patched quickly in a security hotfix. You can't tell the browser to just render the frame if the source content header says not allowed in frames. That would make it easier for session hijacking.
If the content is GET only you don't post data back then you could get the page server side and proxy the content without the header, but then any post back should get invalidated.
UPDATE: 2019-12-30
It seem that this tool is no longer working! [Request for update!]
UPDATE 2019-01-06: You can bypass X-Frame-Options in an <iframe> using my X-Frame-Bypass Web Component. It extends the IFrame element by using multiple CORS proxies and it was tested in the latest Firefox and Chrome.
You can use it as follows:
(Optional) Include the Custom Elements with Built-in Extends polyfill for Safari:
<script src="https://unpkg.com/#ungap/custom-elements-builtin"></script>
Include the X-Frame-Bypass JS module:
<script type="module" src="x-frame-bypass.js"></script>
Insert the X-Frame-Bypass Custom Element:
<iframe is="x-frame-bypass" src="https://example.org/"></iframe>
The X-Frame-Options header is a security feature enforced at the browser level.
If you have control over your user base (IT dept for corp app), you could try something like a greasemonkey script (if you can a) deploy greasemonkey across everyone and b) deploy your script in a shared way)...
Alternatively, you can proxy their result. Create an endpoint on your server, and have that endpoint open a connection to the target endpoint, and simply funnel traffic backwards.
Yes Fiddler is an option for me:
Open Fiddler menu > Rules > Customize Rules (this effectively edits CustomRules.js).
Find the function OnBeforeResponse
Add the following lines:
oSession.oResponse.headers.Remove("X-Frame-Options");
oSession.oResponse.headers.Add("Access-Control-Allow-Origin", "*");
Remember to save the script!
As for second question - you can use Fiddler filters to set response X-Frame-Options header manually to something like ALLOW-FROM *. But, of course, this trick will work only for you - other users still won't be able to see iframe content(if they not do the same).
So my ISP (Smartfren; Indonesia) has decided to start injecting all non-SSL pages with an iframing script that allows them to insert ads into pages. Here's what's happening:
My browser sends a request to the server. ISP intercepts it and instead returns a javascript that loads the requested page inside an iframe.
Aside being annoying in principle, this injection also breaks any number of standard page functionality; and presents possible security hazards.
What I've tried to do so far:
Using a GreaseMonkey script to nix away the injected code and redirect to the original URL. Result: Breaks some legitimate iframes. Also, the ISP's code gets executed, because GreaseMonkey only kicks in after the page is loaded.
Using Privoxy for a local proxy and setting up a filter to clean up the injection and replace it with a plain javascript redirect to the original URL. Result: Breaks some legitimate iframes. ISP's code never gets to the browser.
You can view the GreaseMonkey and Privoxy fixes I've been working on at the following paste: http://pastebin.com/sKQTvgY2 ... along with a sample of the ISP's injection.
Ideally I could configure Privoxy to immediately resend the request when the alteration is detected, instead of filtering out the injected JS and replacing it with a JS redirection to the original URL. (The ISP-injection gets switched off when the same request is resent without delay.) I'm yet to figure out how to accomplish that. I believe it'd fix the iframe-breaking problem.
I know I could switch to a VPN or use the Tor browser. (Or change the ISP.) I'm hoping there's another way around. Any suggestions on how to eliminate this nuisance?
Actually now I have a solution:
The ISP proxy react on the Accept: header that the browser sends.
So this is the default for firefox:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Now we are going to change this default:
And set it to: Accept: */*
Here is how to setup header hacker for google chrome
Set the title to anything you like:NO IFRAME
Append/replace select replace with
String */*
And Match string to .* and then click add.
In the permanent header switches
Set domain to .* and select the rule you just created
PS: changing it in the firefox settings does not work 100% because some request like ajax seem to bypass it so a plugin is the only way as it literally intercepts every outgoing browser request
That's it no more iframes!!!
Hope this helps!
UPDATE: Use DNSCrypt is the best solution 😁
OLD ANSWER
Im using this method
Find resource that contain iframe code (use chrome dev tool)
Block the url with proxy or host file
I'm using linux, so i edited my hosts file on
/etc/hosts
Example :
127.0.0.1 ibnads.xl.co.id
I have a site that renders nearly everything through javascript (not my design), and this has caused a lot of issues in Internet Explorer, of course. The recurring issue is that when the user has security set to High, the necessary javascript files get blocked, I believe because they are from another domain. This has something to do with the Drupal setup, I'm not entirely sure, but the important thing to know is that the files are served from a different domain and there's nothing I can do about that.
What my client wants is for an alert to pop up whenever these scripts are getting blocked that tells their users how to change their security settings.
1) If I add a javascript file on the same domain, it shouldn't get blocked, right?
2) Is there a way I can detect what the user's security settings are, or detect if scripts are being blocked using javascript?
There is another way to detecting whether a js script was loaded or not; there could be so many things, it can be their network firewall, os level firewall, browser security settings, the list continues with possibilities.
You can have:
<script src="http://yourdomain.com/the_js_script.js"></script>
<script>if (typeof foo == "undefined") {alert ('error loading script');}</script>
Make sure in the_js_script.js, you'd have
var foo = 'Script loaded successfully';
You can do that for all the js scripts, and alert distinct messages so the user at least knows which scripts were blocked or if they came through.
Setting your IE security set to High, disables all scripts from running in the browser.
The only workaround available is to place a warning message using the noscript html tag.
<noscript>Your browser does not support JavaScript!</noscript>
I would have liked to comment on #unixmiah's answer, but I don't have enough reputation, and I believe this is an answer as well. Unixmiah's solution won't work to alert blocked clients, I think since the alert needs a script to be generated.However, I believe this would work (wouldn't it?):
jQuery(function($) {
$(document).ready(function() {
$("p#jstrap").hide();
});
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<p id="jstrap">You seem to have switched Javascript off.</p>
I've recently got an email from Google, saying that they are going to ban my AdSense account because I'm sending Personally Identifiable Information to them with my Google AdSense tag requests. It says that around 1% of requests from my website have a referrer of:
some_user#my_website.com/some/subpage
and they consider some_user#my_website.com to be PII (even though it can be completely made up abcd1234#my_website.com). More on this here: https://support.google.com/adsense/answer/6163366?hl=en .
I never link to this kind of URLs (the only form I use is my_website.com/some/subpage), but I guess my users sometimes enter it manually (since product-wise my website is providing an email service, it may seem reasonable by some logic).
I figured URI of some_user#my_website.com/some/subpage is legal since http basic auth allows for specifying user like this. When I entered it manually to Firefox, some_user# disappears from the location bar but in the Net panel of Firebug I can see all files are indeed requested from some_user#my_website.com/some/subpage and that's how Google sees it too.
I though that as a brute-force solution even something like:
if uri contains '#':
redirect to my_website.com
would do.
I'm using NGINX/UWSGI/Python Paste + JS. I've tried to implement the above condition both on server side and in JS, but my URI always says my_website.com/some/subpage even if I manually put some_user#my_website.com/some/subpage in the browser address bar.
I've also tried configuring basic_auth in NGINX to disallow providing any user but with no effect.
How do I get rid of these requests?
How do I get the FULL URI (with some_user#) in JS? I tried document.URI and window.location.href but they didn't contain the user part...
Apparently presence of user# part in the URI can be detected by examining window.location.href. I haven't noticed it before since window.location.href only contains user# in Webkit-based browsers (e.g. Chrome, Opera, Safari) but not in Firefox!
To resolve the problem I've added a check on that in JS + a JS redirect to an URL without user[:password]#.
Hopefully Google uses the same variable to figure out referrer for the ad requests, so it get PII only from Webkit browsers & fixing it for Webkit suffices. Will keep you posted.
I have the following element:
<script type="text/javascript" src="https://cdn.example.com/js_file.js"></script>
In this case the site is HTTPS, but the site may also be just HTTP. (The JS file is on another domain.) I'm wondering if it's valid to do the following for convenience sake:
<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>
I'm wondering if it's valid to remove the http: or https:?
It seems to work everywhere I have tested, but are there any cases where it doesn't work?
A relative URL without a scheme (http: or https:) is valid, per RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax", Section 4.2. If a client chokes on it, then it's the client's fault because they're not complying with the URI syntax specified in the RFC.
Your example is valid and should work. I've used that relative URL method myself on heavily trafficked sites and have had zero complaints. Also, we test our sites in Firefox, Safari, IE6, IE7 and Opera. These browsers all understand that URL format.
It is guaranteed to work in any mainstream browser (I'm not taking browsers with less than 0.05% market share into consideration). Heck, it works in Internet Explorer 3.0.
RFC 3986 defines a URI as composed of the following parts:
foo://example.com:8042/over/there?name=ferret#nose
\_/ \______________/\_________/ \_________/ \__/
| | | | |
scheme authority path query fragment
When defining relative URIs (Section 5.2), you can omit any of those sections, always starting from the left. In pseudo-code, it looks like this:
result = ""
if defined(scheme) then
append scheme to result;
append ":" to result;
endif;
if defined(authority) then
append "//" to result;
append authority to result;
endif;
append path to result;
if defined(query) then
append "?" to result;
append query to result;
endif;
if defined(fragment) then
append "#" to result;
append fragment to result;
endif;
return result;
The URI you are describing is a scheme-less relative URI.
are there any cases where it doesn't work?
If the parent page was loaded from file://, then it probably does not work (it will try to get file://cdn.example.com/js_file.js, which of course you could provide locally as well).
Many people call this a Protocol Relative URL.
It causes a double-download of CSS files in IE 7 & 8.
Here I duplicate the answer in Hidden features of HTML:
Using a protocol-independent absolute
path:
<img src="//domain.com/img/logo.png"/>
If the browser is viewing an page in
SSL through HTTPS, then it'll request
that asset with the https protocol,
otherwise it'll request it with HTTP.
This prevents that awful "This Page
Contains Both Secure and Non-Secure
Items" error message in IE, keeping
all your asset requests within the
same protocol.
Caveat: When used on a <link> or
#import for a stylesheet, IE7 and IE8
download the file twice. All other
uses, however, are just fine.
It is perfectly valid to leave off the protocol. The URL spec has been very clear about this for years, and I've yet to find a browser that doesn't understand it. I don't know why this technique isn't better known; it's the perfect solution to the thorny problem of crossing HTTP/HTTPS boundaries. More here: Http-https transitions and relative URLs
are there any cases where it doesn't work?
Just to throw this in the mix, if you are developing on a local server, it might not work. You need to specify a scheme, otherwise the browser may assume that src="//cdn.example.com/js_file.js" is src="file://cdn.example.com/js_file.js", which will break since you're not hosting this resource locally.
Microsoft Internet Explorer seem to be particularly sensitive to this, see this question: Not able to load jQuery in Internet Explorer on localhost (WAMP)
You would probably always try to find a solution that works on all your environments with the least amount of modifications needed.
The solution used by HTML5Boilerplate is to have a fallback when the resource is not loaded correctly, but that only works if you incorporate a check:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>
UPDATE: HTML5Boilerplate now uses <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js after deciding to deprecate protocol relative URLs, see [here][3].
1. Summary
Answer for 2019: you can still use protocol-relative URLs, but this technique an anti-pattern.
Also:
You may have problems in developing.
Some third-party tools may not support them.
Migrating from protocol-relative URLs to https:// it would be nice.
2. Relevance
This answer is relevant for January 2019. In the future, the data of this answer may be obsolete.
3. Anti-pattern
3.1. Argumentation
Paul Irish — front-end engineer and a developer advocate for the Google Chrome — write in 2014, December:
Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the https:// asset.
Allowing the snippet to request over HTTP opens the door for attacks like the recent GitHub Man-on-the-side attack. It’s always safe to request HTTPS assets even if your site is on HTTP, however the reverse is not true.
3.2. Another links
Loads page resources using protocol relative URIs
Stop using protocol-relative URLs
3.3. Examples
In 2017 Stack Overflow switched from protocol-relative URLs to https
In 2018 Chrome will flag all unencrypted websites as “not secure”
4. Developing process
For example, I try to use clean-console.
Example file KiraCleanConsole__cdn_links_demo.html:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>clean-console without protocol demonstration</title>
<!-- Really dead link -->
<script src="https://unpkg.com/bowser#latest/bowser.min.js"></script>
<!-- Package exists; link without “https:” -->
<script src="//cdn.jsdelivr.net/npm/jquery#3.3.1/dist/jquery.min.js"></script>
<!-- Package exists: link with “https:” -->
<script src="https://cdn.jsdelivr.net/npm/gemini-scrollbar/index.js"></script>
</head>
<body>
Kira Goddess!
</body>
</html>
output:
D:\SashaDebugging>clean-console -i KiraCleanConsole__cdn_links_demo.html
checking KiraCleanConsole__cdn_links_demo.html
phantomjs: opening page KiraCleanConsole__cdn_links_demo.html
phantomjs: Unable to load resource (#3URL:file://cdn.jsdelivr.net/npm/jquery#3.3.1/dist/jquery.min.js)
phantomjs: phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error opening //cdn.jsdelivr.net/npm/jquery#3.3.1/dist/jquery.min.js: The network path was not found.
phantomjs://code/runner.js:31 in onResourceError
phantomjs: Unable to load resource (#5URL:https://unpkg.com/bowser#2.1.0/bowser.min.js)
phantomjs: phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error downloading https://unpkg.com/bowser#2.1.0/bowser.min.js - server replied: Not Found
phantomjs://code/runner.js:31 in onResourceError
phantomjs: Checking errors after sleeping for 1000ms
2 error(s) on KiraCleanConsole__cdn_links_demo.html
phantomjs process exited with code 2
Link //cdn.jsdelivr.net/npm/jquery#3.3.1/dist/jquery.min.js is valid, but I getting an error.
Pay attention to file://cdn.jsdelivr.net/npm/jquery#3.3.1/dist/jquery.min.js and read Thilo and bg17aw answers about file://.
I didn't know about this behavior and couldn't understand why I have problems like this for pageres.
5. Third-party tools
I use Clickable URLs Sublime Text package. Use it, I can simply open links from my text editor in browser.
Both links in example are valid. But first link I can successfully open in browser use Clickable URLs, second link — no. This may not be very convenient.
6. Conclusion
Yes:
If you have problems as in Developing process item, you can set your development workflow.
Else you have problems as in Third-party tools item, you can contribute tools.
But you don't need this additional problems. Read information by links in Anti-pattern item: protocol-relative URLs is obsolete.
Following the gnud's reference, the RFC 3986 section 5.2 says:
If the scheme component is defined, indicating that the reference
starts with a scheme name, then the reference is interpreted as an
absolute URI and we are done. Otherwise, the reference URI's scheme
is inherited from the base URI's scheme component.
So // is correct :-)
Yes, this is documented in RFC 3986, section 5.2:
(edit: Oops, my RFC reference was outdated).
It is indeed correct, as other answers have stated. You should note though, that some web crawlers will set off 404s for these by requesting them on your server as if a local URL. (They disregard the double slash and treat it as a single slash).
You may want to set up a rule on your webserver to catch these and redirect them.
For example, with Nginx, you'd add something like:
location ~* /(?<redirect_domain>((([a-z]|[0-9]|\-)+)\.)+([a-z])+)/(?<redirect_path>.*) {
return 301 $scheme:/$redirect_domain/$redirect_path;
}
Do note though, that if you use periods in your URIs, you'll need to increase the specificity or it will end up redirecting those pages to nonexistent domains.
Also, this is a rather massive regex to be running for each query -- in my opinion, it's worth punishing non-compliant browsers with 404s over a (slight) performance hit on the majority of compliant browsers.
We are seeing 404 errors in our logs when using //somedomain.com as references to JS files.
The references that cause the 404s come out looking like this:
ref:
<script src="//somedomain.com/somescript.js" />
404 request:
http://mydomain.com//somedomain.com/somescript.js
With these showing up regularly in our web server logs, it is safe to say that: All browsers and Bots DO NOT honor RFC 3986 section 4.2. The safest bet is to include the protocol whenever possible.
The pattern I see on html5-boilerplate is:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>
It runs smoothly on different schemes like http, https, file.
As your example is linking to an external domain, if you are using HTTPS then you should verify that the external domain is setup for SSL as well. Otherwise, your users may see SSL errors and/or 404 errors (e.g. older versions of Plesk store HTTP and HTTPS in separate folders). For CDNs, it shouldn't be an issue but for any other website it could be.
On a side note, tested while updated an old website and also works in the url= part of a META REFRESH.