I'm loading an external page into an IFRAME, which contains an advertisment that I don't want to let load.
Is there a way I can set a URL/domain blacklist for any content inside an IFRAME?
I'm assuming you're developing on the server-side, some kind of Web app.
What I'd reach for in this situation is something like Perl::HTTP::Proxy.
Instead of pointing your IFRAME directly at the external site, point it to a proxy process (page, servlet, PHP script, doesn't matter) on your own site. This code fetches the content of the URL given to it and filters out the offending ad code before serving the modified response.
I can't comment on the legality or ethics of doing this; depending on the situation, someone might not be happy that you're serving their content but not showing the ads they're getting money for.
No, if you could alter an external page then it could lead to XSS attacks. You'll have to rely on things like AdBlock Plus, etc.
No. But there is one way you can interfere with an iframe's scripts externally:
<iframe security="restricted">
This is an IE6+-only extension, see http://msdn.microsoft.com/en-us/library/ms534622(VS.85).aspx.
This mechanism is poorly-designed and pretty much a dead loss for any kind of actual security, but if the ad in the child page relies on JavaScript to write its iframe (many ad networks do this), then you might be able to break it like this. Of course you would also be breaking any other scripts on the page, and you may well still get a bunch of non-script-based ads.
Not really satisfactory.
Proxy the request internally and manipulate the raw HTML before returning it?
Related
It looks like AJAX is indeed unable (at least for all practical purposes) to write foreign HTML to the current page. But what if your CDN website had, say, a JS that would simply document.write() everything? Then your HTML document would have nothing but a remote script.
<html>
<script src="https://pastebin.com/raw.php?i=0wm5v7i6">
</script>
</html>
I tried this. Funny thing is, sometimes it works and other times it does a kind of security error:
Why doesn't this work? What if, on your own website, you simply put everything on an easy host like Google Drive?
What if, on your own website, you simply put everything on an easy host like Google Drive?
That is possible, unless
You want control over your website and don't want to depend on the security and availibility of another site, or that somebody reports your pastebin as abuse and it gets deleted.
You want to make proper use of security features like content security policy and don't want to allow everything from pastebin.com.
You want search engines to find you. Although at least google does limited interpretation of JavaScript I doubt that they will handle this content the way you like.
From the looks of it, PasteBin doesn't supply content over SSL (https). You've put https in the URL to your script, but PasteBin just redirects this request to http, and the net effect is that you are trying to access a script over http when the page is accessed over https, and Chrome prevents that.
Just try going to https://pastebin.com/raw.php?i=0wm5v7i6: your browser will be redirected to http://pastebin.com/raw.php?i=0wm5v7i6.
On the website http://imaginaryman-test.blogspot.com/ the typewriter is inside of an IFAME . Everything works correctly on all browsers when you go to the site directly http://castedspell.com/mark/ but when viewing the version embeded in an IFRAME it does not work on IE and throws errors in Chrome.
Unsafe JavaScript attempt to access frame with URL http://imaginaryman-test.blogspot.com/ from frame with URL http://castedspell.com/mark/. Domains, protocols and ports must match.
This is the source code for the embedded IFRAME
https://github.com/totheleftpanda/typeWrite/tree/master/mark
I understand that this is a security problem but I don`t know how to fix it and can not find any material that would help me solve the issue.
The easiest method is to set a PHP (or any server language) proxy that just gets the content of the page from the other domain and outputs it. The only real drawback is that the cookies of the client for the remote domain aren't sent.
Take a look at http://benalman.com/projects/jquery-postmessage-plugin/. This is a jquery plugin that sends message between the two frames. The two frames do not need to be on the same domain. But you do need to access both pages to be able modify them. I also wrote a post here that answers communication between iframes. How to capture clicks from iframe on another domain?
Your only chance is something like easyXDM. (or do it manually using the hash, but would prefer easyXDM)
See the SO answer: Cross-domain hash change communication
eg. if you wanna call a method:
http://easyxdm.net/wp/2010/03/17/remote-procedure-calls-rpc/
EDIT:
If I try your demo in firefox I don't get the "Unsafe JavaScript attempt to access" error at all. But in Chrome it's thrown many times.
You have so much other code in your example that I'm not even sure that your code causes the problem. You should do a very limited/basic test to see if your flash-communication works, without all those other javascripts.
I have had similar issues with this before. Basically if you have an iframe that contains a page from a domain that differs from the main page's domain, javascript will not be able to cross the boundaries between them. Javascript within the iframe will be able to talk within the iframe, javascript in the main page will be able to talk within the main page, but they will not be able to talk to each other.
This is a security issue that aims to stop cross-site scripting attacks. There are a number of hacks that you can put in place to get around this problem but they are all (or at least the ones I know of) rather hairy.
Here are some questions that you should answer before trying to go further:
1) What exactly are you trying to do between the pages using javascript?
2) Do you have access to the source of both pages?
It may be waaay simpler than the above answers. It looks like this function:
function playSound(){
swf.playSound();
}
Is written in the DOM timeline before swf is actually assigned to the swfObject in the function below it.
I would recommend moving that function down further and then retest.
Certain websites like Twitter, Flickr, etc avoid being stuck within an iframe. Is there any way to stop this from happening? I just need to see the public data so I am open to disabling Javascript, etc. How do I disable Javascript running on the iframe? Is this possible?
You can't disable JavaScript on iFrames or any other resources AFAIK.
The only way to reliably do this is to load the sites through a proxy PHP or other server-side script, filter out any JavaScript (which will break many sites), and fix all relative references to images and other media - a task that would take an insane amount of time to complete if you want the sites to actually work.
If you just need some data from the sites, proxying might work. Seeing as the Same Origin Policy would prevent you getting anything from an IFRAME from a different domain anyway, it is also the only way to access content on those sites using JavaScript.
In IE only, there is the <iframe security="restricted"> attribute. This disables JavaScript in the targeted document, which would break a JS frame-escape script — along with all other interaction that's script-dependent.
However, apart from the browser compatibility issue, it's very rude to frame a site that doesn't want to be framed, and it will work less and less anyway as more sites deploy X-Frame-Options.
I'm not sure what you mean by “need to see the public data”... as Pekka said, you won't be able to ‘see’ into an iframe's DOM from outside it, as that would be a security problem.
I need to be allow content from our site to be embeded in other users web sites.
The conent will be chargeable so I need to keep it secure but one of the requirements is that the subscribing web site only needs to drop some javascript into their page.
It looks like the only way to secure our content is to check the url of the page hosting our javascript matches the subscribing site. Is there any other way to do this given that we don't know the client browsers who will be hitting the subscribing sites?
Is the best way to do this to supply a javascript include file that populates a known page element when the page loads? I'm thinking of using jquery so the include file would first call in jquery (checking if it's already loaded and using some sort of namespace protection), then on page load populate the given element.
I'd like to include a stylesheet as well if possible to style the element but I'm not sure if I can load this along with the javascript.
Does this sound like a reasonable approach? Is there anything else I should consider?
Thanks in advance,
Mike
It looks like the only way to secure our content is to check the url of the page hosting our javascript matches the subscribing site.
Ah, but in client-side or server-side code?
They both have their disadvantages. Doing it with server-side code is unreliable because some browsers won't be passing a Referer header at all, and if you want to stop caches keeping a copy of the script, preventing the Referer-check from taking place, you have to serve with nocache or Vary: Referer headers, which would harm performance.
On the other hand, with client-side checks in the script you return, you can't be sure your environment you're running in hasn't been sabotaged. For example if your inclusion script tag was like:
<script src="http://include.example.com/includescript?myid=123"></script>
and your server-side script looked up 123 as being the ID for a customer using the domain customersite.foo, it might respond with the script:
if (location.host.slice(-16)==='customersite.foo') {
// main body of script
} else {
alert('Sorry, this site is not licensed to include content from example.com');
}
Which seems simple enough, except that the including site might have replaced String.prototype.slice with a function that always returned customersite.foo. Or various other functions used in the body of the script might be suspect.
Including a <script> from another security context cuts both ways: the including-site has to trust the source-site not to do anything bad in their security context like steal end-user passwords or replace the page with a big goatse; but equally, the source-site's code is only a guest in the including-site's potentially-maliciously-customised security context. So a measure of trust must exist between the two parties wherever one site includes script from another; the domain-checking will never be a 100% foolproof security mechanism.
I'd like to include a stylesheet as well if possible to style the element but I'm not sure if I can load this along with the javascript.
You can certainly add stylesheet elements to the document's head element, but you would need some strong namespacing to ensure it didn't interfere with other page styles. You might prefer to use inline styles for simplicity and to avoid specificity-interference from the page's main style sheet.
It depends really whether you want your generated content to be part of the host page (in which case you might prefer to let the including site deal with what styles they wanted for it themselves), or whether you want it to stand alone, unaffected by context (in which case you would probably be better off putting your content in an <iframe> with its own styles).
I'm thinking of using jquery so the include file would first call in jquery
I would try to avoid pulling jQuery into the host page. Even with noconflict there are ways it can conflict with other scripts that are not expecting it to be present, especially complex scripts like other frameworks. Running two frameworks on the same page is a recipe for weird errors.
(If you took the <iframe> route, on the other hand, you get your own scripting context to play with, so it wouldn't be a problem there.)
You can store the users domain, and a key within your local database. That, or the key can be an encrypted version of the domain to keep you from having to do a database lookup. Either one of these can determine whether you should respond to the request or not.
If the request is valid, you can send your data back out to the user. This data can indeed load in jQuery and and additional CSS reference.
Related:
How to load up CSS files using Javascript?
check if jquery has been loaded, then load it if false
I'm just looking for clarification on this.
Say I have a small web form, a 'widget' if you will, that gets data, does some client side verification on it or other AJAX-y nonsense, and on clicking a button would direct to another page.
If I wanted this to be an 'embeddable' component, so other people could stick this on their sites, am I limited to basically encapsulating it within an iframe?
And are there any limitations on what I can and can't do in that iframe?
For example, the button that would take you to another page - this would load the content in the iframe? So it would need to exist outwith the iframe?
And finally, if the button the user clicked were to take them to an https page to verify credit-card details, are there any specific security no-nos that would stop this happening?
EDIT: For an example of what I'm on about, think about embedding either googlemaps or multimap on a page.
EDIT EDIT: Okay, I think I get it.
There are Two ways.
One - embed in an IFrame, but this is limited.
Two - create a Javascript API, and ask the consumer to link to this. But this is a lot more complex for both the consumer and the creator.
Have I got that right?
Thanks
Duncan
There's plus points for both methods. I for one, wouldn't use another person's Javascript on my page unless I was absolutely certain I could trust the source. It's not hard to make a malicious script that submits the values of all input boxes on a page. If you don't need access to the contents of the page, then using an iframe would be the best option.
Buttons and links can be "told" to navigate the top or parent frame using the target attribute, like so:
This is a link
<form action="http://some.url/with/a/page" target="_parent"><button type="submit">This is a button</button></form>
In this situation, since you're navigating away from the hosting page, the same-origin-policy wouldn't apply.
In similar situations, widgets are generally iframes placed on your page. iGoogle and Windows Live Gadgets (to my knowlege) are hosted in iframes, and for very good reason - security.
If you are using AJAX I assume you have a server written in C# or Java or some OO language.
It doesn't really matter what language only the syntax will vary.
Either way I would advise against the iFrame methods.
It will open up way way too many holes or problems like Http with Https (or vice-versa) in an iFrame will show a mixed content warning.
So what do you do?
Do a server-side call to the remote site
Parse the response appropriately on the server
Return via AJAX what you need
Display returned content to the user
You know how to do the AJAX just add a server-side call to the remote site.
Java:
URL url = new URL("http://www.WEBSITE.com");
URLConnection conn = url.openConnection();
or
C#:
HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create("http://www.WEBSITE.com");
WebResponse res = req.GetResponse();
I think you want to get away from using inline frames if possible. Although they are sometimes useful, they can cause issues with navigation and bookmarking. Generally, if you can do it some other way than an iframe, that is the better method.
Given that you make an AJAX reference, a Javascript pointer would probably be the best bet i.e. embed what you need to do in script tags. Note that this is how Google embed things such as Google Analytics and Google Ads. It also has the benefit of also being pullable from a url hosted by you, thus you can update the code and 'voila' it is active in all the web pages that use this. (Google usually use version numbers as well so they don't switch everyone when they make changes).
Re the credit card scenario, Javascript is bound by the 'same origin policy'. For a clarification, see http://en.wikipedia.org/wiki/Same_origin_policy
Added: Google Maps works in the same way and with some caveats such as a user/site key that explicitly identify who is using the code.
Look into using something like jQuery, create a "plugin" for your component, just one way, and just a thought but if you want to share the component with other folks to use this is one of the things that can be done.