If I can insert iframes in a forum comment, example:
<iframe src="http://badwebsite.comm/xss.html"></iframe>
cat xss.html
<html>
<head>
<script>
window.top.location = "http://badwebsite.comm/stolecred.html";
</script>
</head>
</html>
So when anyone enters this forum, it will be redirected to http://badwebsite.comm/stolecred.html/.
From this point, the stolecred.html can be an exact copy of the login page for the original forum.
After the user gave his credentials, the http://badwebsite.comm/stolecred.html can redirect it to the original website.
Question:
So allowing iframes in a forum is a very big security problem? It shouldn't be allowed in any manner? Why does a modern browser allow window.top.location to work in an iframe?
There is no limited risk (as long as there isn't a bug in the browser).
If you run the example below, you'll get the following error message in the JavaScript console of your browser:
Unsafe JavaScript attempt to initiate navigation for frame with URL 'Why is "window.top.location" working in iframes?' from frame with URL 'http://schneidr.de/misc/bad_redirect.html'. The frame attempting navigation of the top-level window is sandboxed, but the 'allow-top-navigation' flag is not set.
(Error message from Chrome, wording may be different in other browsers)
<iframe src="http://schneidr.de/misc/bad_redirect.html"></iframe>
The reason for the error is, that the browser doesn't trust JavaScript that is embedded via a frame from a different domain. Because of this it is automatically sandboxed.
To allow the JavaScript changes in an iframe you need to set the sandbox="" attribute, for this example to sandbox="allow-top-navigation". So, if you allow iframes in comments you should at least filter this attribute before saving and displaying it.
If you do this it is pretty safe to allow iframes from a security point of view. Personally I wouldn't allow it on a site I administer because I have no control over the content displayed via the iframe, which could bring me legal trouble.
Related
I have a html page with an iFrame on another domain.
<iframe id="myframe"src="https://www.example.com" height="1000" width=100%>
I want to get some info of that website and used them on my html page. For example I want to extract the tag and set it as title of my html.
I used this code I found on W3School
var iframe = document.getElementById("myframe");
var y = (iframe.contentWindow || iframe.contentDocument);
if (y.document)y = y.document;
var strHeader = y.body.getElementsByClassName("header");
I wrote in with IDE HelloWebFree (similar to notepad++). When I try my code within the IDE it works fine. But when I try to open it with safari, Google Chrome or Firefox it doesn't work.
I get the error:"SecurityError: Permission denied to access property "document" on cross-origin object".
I don't need to change anything to the iframe content, I just want to read it and use it in my own html. So I don't see why it is a security issue. Why does it works within my IDE and not in the browser?
I have read a lot of post about this issue, but the most ones or more then 5 years old and not applicable anymore. someone an idea?
The reason this happens in browsers is to protect the user's security.
It is in place to protect the user from any random website reading his personal info from his Facebook, or Banking website or whatever.
If you want to access public information from a website, then I suggest scraping it on the backend.
We have an intranet website, lets call it https://www.myintranetsite.com. Note that I can't access its source code.
I would like to use it in another web page in an IFrame, so I am creating a very basic HTML page like:
<html><body>
<div>
<iframe id="myIframe" width="100%" height="1200px" src="https://www.myintranetsite.com/"></iframe>
</div>
</body></html>
When I open the HTML page with Microsoft Edge, it works, however Google Chrome does not work and it shows the error below:
When I do F12 in the browser, the error message I see in the console is on below:
Uncaught ReferenceError: $ is not defined
at login?isajax=true:19
As I understand, JQuery is used in the myintranetsite.com and Chrome does not load it for some reason, probably security related... Version of Chrome: 81.0.4044.122 (64bit)
How can I overcome this issue? I've tried those but no help:
clearing the cache,
adding myintranetsite to trusted sites in internet options,
clearing SSL Stage,
disabling cookies in
chrome
I've checked this but it did not help either: jQuery/iframe not working in Chrome
Any help or advice would be appreciated.
Your understanding that this is prevented by security measures is correct, basically you get a jQuery error because jQuery would be loaded by the inner page, but since the inner page is not loaded, it's not loading jQuery either. You will need to create some proxy pages, let's see the steps:
Step 1
Create a separate page, let's call it myintranetproxy. I will assume that the location of this page you create is /myintranetproxy, so, if you have different routes, feel free to make the changes you need.
Step 2
Make sure that myintranetproxy shows a text or something at this stage, like 'Hello World', just to ensure that it's loaded at the next step.
Step 3
Load myintranetproxy:
<html><body>
<div>
<iframe id="myIframe" width="100%" height="1200px" src="/myintranetproxy"></iframe>
</div>
</body></html>
now you should see your temporary content inside the iframe.
Step 4
Change myintranetproxy, it should now send a GET request to https://www.myintranetsite.com/ and once the response arrives, write that HTML as it is instead of your "Hello World"
Step 5
Make sure that you change any URL in the response you get to the absolute URL of the page. This will affect iframe, script, link, img tags. You can implement this, or use an HTML parser for this purpose.
The most likely cause is that your somehow mixing HTTP and HTTPS. Chrome really does not like this, make sure your parent page and the page in the iframe are both using the same protocol
Sometimes iFrames are disabled as mitigation against clickjacking attempts.
In order for the intranet site to be framed, all of the mitigations below would need to be disabled.
Content Security Policy (CSP) frame-ancestors directive
X-Frame-Options Response Headers
Legacy Browser Frame Breaking Script
more about those clickjacking mitigations and how to enable/disable those protections can be found here
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 for example).
I need to set the value attribute of several elements in the document of an iframe. I am able to easily do this from Chrome Tools Console. But the same commands do NOT work from a JavaScript injected into the page by Keyboard Maestro or AppleScript.
The iframe is generated by a Chrome extension: Evernote Web Clipper.
In the below examples, I have already invoked the Evernote Web Clipper.
This script/commands work from Chrome Console, after I have selected the iframe document:
var remElem = document.getElementById("comments");
remElem.value = "KM This is a test";
var titleElem = document.getElementById("title")
titleElem.value = 'KMTEST title'
I suspect that I first need to get or select the iframe document before I run the above script. How do I do this?
I have tried many different SO solutions, and none of them work.
Here is a screenshot of the main document in Chrome Tools:
Screenshot of iframe document in Chrome Tools:
Here is what I have tried, unsuccessfully:
// *** NONE of These Work ***
//--- Method 1 ---
var frame = window.frames[‘frame1’];
var documentObj = frame.document;
var element = documentObj.getElementsByName(‘frame1Text’);
//--- Method 2 ---
var frame = document.getElementById(‘myframe1’);
var documentObj = frame.contentWindow.document;
var element = documentObj.getElementById(‘frame1Text’);
//--- Method 3 ---
window.frames[1].document.getElementById('someElementId')
For example, from Chrome Tools, when I have the main document selected:
//--- From Chrome Tools with Main document selected ---
enFrm = document.getElementById("evernoteGlobalTools")
/*RESULTS
<iframe id="evernoteGlobalTools" src="chrome-extension://pioclpoplcdbaefihamjohnefbikjilc/content/global_tools/global_tools.html" class="evernoteClipperVisible" style="height: 528px !important;"></iframe>
*/
oDoc = enFrm.contentWindow.document;
/* ERROR
VM882:1 Uncaught DOMException: Blocked a frame with origin "http://forum.latenightsw.com" from accessing a cross-origin frame.
at <anonymous>:1:27
(anonymous) # VM882:1
*/
oDoc = enFrm.contentWindow.document;
/* ERROR
VM892:1 Uncaught DOMException: Blocked a frame with origin "http://forum.latenightsw.com" from accessing a cross-origin frame.
at <anonymous>:1:27
*/
Any/All suggestions/ideas gratefully accepted.
The error you are facing:
Uncaught DOMException: Blocked a frame with origin "http://forum.latenightsw.com" from accessing a cross-origin frame.
clearly states that your code has been blocked due to a Cross-Origin Resource Sharing restriction (A.K.A. Content Security policy or evn CORS).
Your domain forum.latenightsw.com is quite rightly considered not the same when compared to chrome-extension://pioc…
(main page versus extension's injected IFrame's domain …). Accessing the IFrame's DOM in such a situation would be a HUGE security flaw.
I fear there is no realistic solution that would let you run this code from the main page Javascript context.
If you were in control of the chrome extension, you could try adding your domain as a host permission in the manifest file (If this was really relevant). (More details on Google Chrome documentation).
I'm not sure window.postMessage would help you here.
If you have static code to execute you could create a Bookmarklet containing the code, then ask your visitors to add it to their bookmarks (bar) and click it to execute changes. But this is not a realistic solution and won't probably fit your need.
EDIT
In response to «Please help me understand why that is any more of a security issue» comment.
Browsers sandboxes code in contexts, each context has its own set of security restrictions and some of them are at risk (mostly) regarding XSS attacks.
WEB page is the most exposed context to attacks, any browser will execute the code it contains after fetching its URL. This is the ideal target for attacks (such as XSS) because the more people visit an affected website the more people pay the costs. This is why restriction such as Cross-Origin Resource Sharing exist which prevent different frames (with different domains) to access each other documents by default.
There are factors that ease attacks, for instance: identified security flaws in open source outdated CMS consisting in not correct escaping of content coming from the database letting tags appear in the page source (which is then executed by browsers…), etc.
In the "Extension" context, some APIs require the developer to explicitly ask for permissions in the extension's manifest file. Interactions with the current page (active tab) is granted if the ActiveTab permission has been declared. Once you install an extension, you give access to APIs the extension has requested for.
The developer console context is a particular case. What is executed their ONLY COMES FROM YOU AND WILL ONLY AFFECT YOUR EXPERIENCE.
One can guess that risks are quite limited there compared to code in websites source (where there may have injected malicious code using XSS attacks).
In other words, only the code you enter in the console will be exectuted there and no code from a WEB page will gain access to the console context.
You may have experienced browsers warning you about risks when you past code to execute in the console, telling you to do so if and only if you understand what the code will do or at least if you absolutely trust the author/origin of the snippet.
A (not so) fictional scenario: Access Iframe content from main page.
Let say we have a web page containing malicious script. This script could try to identify installed extensions by periodically scanning DOM nodes and look for specific extensions injected content, and ultimately access that content.
All this reminds me an interesting article for developers.
The scenario I'm going to describe is about Excel, but you can spot the same problem in all Office tools.
Scenario:
In my default browser (NOT Internet Explorer) I'm logged in my own specific website, let's call it www.mypersonalwebsite.com
I have an Excel folder with the A1 cell containing a URL pointing to http://www.mypersonalwebsite.com/url/visible/only/to/loggedin/users
When I click on the URL in A1 cell:
my default browser is trying to open this URL
the website is refusing to serve the page because the request is coming from a non logged in user
So that's the problem: why is the browser complaining about the user session when I'm already logged in? And how can I solve it?
I found many similar questions about this problem on stackoverflow and I think I composed a portable and "definitive" solution to this problem.
First of all: why is the browser complaining about the user session?
The answer is "Microsoft Office Protocol Discovery". In a few words: it's something that works only if you are using Microsoft Windows and your default browser is Internet Explorer.
Basically, if you are not using Microsoft Windows OR your default browser is not Internet Explorer, when you click on an URL, the request sent to the browser will always be with an empty cookie. This means that, despite the default browser could use a correct cookie to authenticate the user, the request coming from Excel will never use it. But if you try to reload the page (and the webserver is not redirecting to a different error page), the browser will use the domain cookie and you'll see the correct page.
Second question: how can I solve this problem?
I think I found a very good solution, composed by an HTML part and a webserver part.
HTML part
Starting from the fact that you need to reload the page to use the cookie, I created a simple static page containing a little javascript code and some html. This is just an example. The main part of this code is here.
<!DOCTYPE HTML>
<html lang="en-US">
<head>
<script type='text/javascript'>
function getParameterByName(name) {
var match = RegExp('[?&]' + name + '=([^&]*)').exec(window.location.search);
return match && decodeURIComponent(match[1].replace(/\+/g, ' '));
}
</script>
<meta charset="UTF-8">
<script type="text/javascript">
window.location.href = getParameterByName('newUrl');
</script>
<title>Page Redirection</title>
</head>
<body>
<!-- Note: don't tell people to `click` the link, just tell them that it is a link. -->
If you are not redirected automatically, follow the <a href='<?php echo $newUrl; ?>'>link</a>
</body>
</html>
You can access to the querystring via javascript in many ways, you can find a very interesting thread here.
This static page, let's call it redirect.html, will only do one thing: it will redirect the browser to the page specified in the newUrl parameter. Now if I put in the A1 cell something like:
http://www.mypersonalwebsite.com/redirect.html?newUrl=http://www.mypersonalwebsite.com/url/visible/only/to/loggedin/users
and if I click on this URL:
Excel will go to this URL using the default browser
The browser will open the redirect.html page with an empty cookie
The browser will reload the page using the domain cookie
The user will see the correct page as an authenticated user
The pros of this trick are: it works on all platforms and on all browsers supporting javascript. The cons are that we need to modify all URLs in all our Excel folders.
The webserver part
To hide this redirection to the end users, and save us to modify all our Office documents, we can use another trick. In this example I will use nginx:
if ($http_user_agent ~* "(Excel|PowerPoint|Microsoft Office)") {
rewrite ^/(.*)$ /redirect.html?url=$1 break;
}
The meaning of this little if block is: if the incoming request is from a user agent like Excel, Powerpoint and so on, nginx will do an internal redirection to the redirect.html page, that will again do the browser redirection explained above.
This nginx redirect will completely hide the redirect trick, so we can use the original URLs and the users will always see the correct page.
I'm sure all this can be improved, and I would like to learn how to do it.
I hope this will help someone in finding a complete solution to this Office problem.
I am writing a simple lightbox-like plugin for my app, and I need to embed an iframe that is linked to an arbitrary page. The problem is, many web sites (for example, facebook, nytimes, and even stackoverflow) will check to see if is being embedded within a frame and if so, will refresh the page with itself as the parent page. This is a known issue, and I don't think there's anything that can be done about this. However, I would like the ability to know before hand if a site supports embed or not. If it doesn't, I'd like to open the page in a new tab/window instead of using an iframe.
Is there a trick that allows me to check this in javascript?
Maybe there is a server-side script that can check links to see if they permit an iframe embed?
I am developing a browser extension, so there is an opportunity to do something very creative. My extension is loaded on every page, so I'm thinking there's a way to pass a parameter in the iframe url that can be picked up by the extension if it destroys the iframe. Then I can add the domain to a list of sites that don't support iframe embed. This may work since extensions aren't loaded within iframes. I will work on this, but in the meantime....
Clarification:
I am willing to accept that there's no way to "bust" the "frame buster," i.e. I know that I can't display a page in an iframe that doesn't want to be in one. But I'd like for my app to fail gracefully, which means opening the link in a new window if iframe embed is not supported. Ideally, I'd like to check iframe embed support at runtime (javascript), but I can see a potential server-side solution using a proxy like suggested in the comments above. Hopefully, I can build a database of sites that don't allow iframe embed.
Check x-frame-options header by using following code
$url = "http://stackoverflow.com";
$header = get_headers($url, 1);
echo $header["X-Frame-Options"];
If return value DENY, SAMEORIGIN or ALLOW-FROM then you can't use iframe with that url.
Probably pretty late but what you need to do is make a request, likely from your server and look for the x-frame-options header. If it's there at all you can just open a new tab because if it is there is is one of the following: DENY, SAMEORIGIN, ALLOW-FROM. In any of these cases it's likely that you don't have access to open it in an iframe.
This subject has been discussed forever on the web with a particularly interesting (failed) attempt here:
Frame Buster Buster ... buster code needed
The bottom line is that even if you are able to construct a proxy that parses the contents of the page that you want in your iframe and removes the offending code before it is served to the iframe you may still come under "cease and desist" from the site if they get to hear about you doing it.
If you don't want your development to be widely available, you could probably get away with it. If you want your development to become popular, forget about it, and build a less underhand way of dealing with it.
Or develop it for mobile only... ;)
UPDATE: OK following on from your comment here's a bit of taster:
in javascript capture the click on the link
$("a").click(function(e){
preventDefault(e); // make sure the click doesn't happen
// call a server side script using ajax and pass the URL this.href
// return either a true or false; true = iframe breakout
// set the target attribute of the link to "_blank" for new window (if true)
// set the target attribute of the link to "yourframename" for iframe (if false)
// only now load the page in the new window or iframe
});
server side in PHP
$d = file_get_contents($url); // $url is the url your sent from the browser
// now parse $d to find .top .parent etc... in the <head></head> block
// return true or false