If I put an iframe in document A pointing to document B, does document B reach me through the server hosting document A, or are both documents sent directly to me?
Following from this, if HTTPS is enabled for the server hosting document A but not the server hosting document B, is B encrypted before it is sent to me?
When using an <iframe>, it is very similar to loading a complete browser window instance inside of another. The <iframe> can have its own sessions, cookies, etc. that are independent of the parent browser window.
If the parent page is delivered via HTTPS, it has no effect on how the <iframe> contained in the page is loaded (encrypted or not). Example: if you have a https:// page that contains an <iframe> with an address of http://, that content will be loaded in the clear (not encrypted).
Checkout this page on <iframe>'s from MDN - it documents this element in great detail.
Also - <iframe>'s are relics of browsers from the 90's, so avoid using them if at all possible. They present all sorts of issues, especially with security and responsive design, so try to go with another option if possible.
Your browser is accessing both. The iframe is simply saying "go get this too", not retrieving the content for you. For that reason, HTTPS will not carry over to protect document B, it will be HTTP traffic and unencrypted.
Related
I have a static website, it only contains html and css. No javascript, no php, no databases. On this site, I'm using images, which I get from image-hosting websites (like imgur).
I've noticed when I visit my website (on Google Chrome at least), if I click the information button next to the URL, it says there are cookies on this site. If I click on the cookies button, it says The following cookies were set when you viewed this page and has a list from cookies, including from those sites that I use for image-hosting.
If I delete them, they come back after a while, but not immediately. I'm trying to avoid cookies as the site is very simple. Are they considered part of my site? If so, is there anything I can do, except hosting the images myself?
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
Are they considered part of my site?
That depends on your perspective.
The browser doesn't consider them to be part of your site. Cookies are stored on a per-domain basis, so a cookie received in response to a request for an image from http://example.com will belong to http://example.com and not to your site.
However, for the purpose of privacy laws (such as GDPR) then they are considered part of your site and, if they are used by the third party to track personally identifiable information, you are required to jump through the usual GDPR hoops.
If so, is there anything I can do, except hosting the images myself?
Not really.
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
Cookies are generally set with HTTP response headers, not with JavaScript.
Whenever a browser requests a file from a server it automatically forwards any cookie data along with the request. Image Hosting services may use that for different purposes.
I always though that if you link to an image directly (as in a link ending in .png for example) it would be the same as if you were hosting the image yourself, and there would be no javascript being run (to save cookies).
So the question is, how to they set these cookies?
Let's say, you use a simple img tag to load an image from a hoster.
<img src="imageHoster.tld/123xyz.png">
The site imageHoster.tld can handle that request by redirecting all requests to e.g. requestHandler.php and that file can set the cookie before sending the image with a simple
<?
setcookie("cookieName", "whateverValue", time()+3600);
header('content-type: image/png');
...
?>
What happens there is actually the same as if you would set the image source like that:
<img src="imageHoster.tld/requestHandler.php?img=123xyz">
Are they considered part of my site?
Since these so called third party cookies are set when visiting your site one could consider them as part of your site. To be on the safe side I would at least mention the use of third party services in the data privacy statement.
If so, is there anything I can do, except hosting the images myself?
Third party cookies can be disabled in the clients browser. But you can't disable them for the visitors of your site. So no, to avoid third parties setting cookies on client browsers visiting your site you can only avoid using their services.
In my website with SSL certified URL, I need to include http content for static contents - JS, CSS, Images etc.
E.g. the page at https://www.example.com will refer to http://subdomain.example.com/images/a.jpg.
Is there a way to include HTTP element within HTTPS page, avoiding any security alerts in the browser?
No. The security warnings are there for a reason and cannot be bypassed.
What if someone altered the JS en-route with a man-in-the-middle attack? They could add their own code and have full access to the DOM, making the SSL worthless.
To be secure, you need to load the entire page over HTTPS, not just the HTML document. If you are secure, then the warnings about being insecure will go away.
You don't need to define http:// when calling your static assets. You can use the protocol-relative url, basically you can do this :
<img src="//subdomain.abc.com/images/a.jpg" alt="">
It will get the image through the same protocol as the page you're on.
Paul Irish will explain that better than me on his blog
I don’t think you can bypass security alerts (on browsers that give them) if your https page includes http content. But check whether the references work with https as well (depends on the server of course). If they do, you can use URLs like //subdomain.example.com/images/a.jpg which means that the protocol (http or https) of the page itself will be used.
Is there a reason we include the http / https protocol on the href attribute of links?
Would it be fine to just leave it off:
my site
The inclusion of the “http:” or “https:” part is partly just a matter of tradition, partly a matter of actually specifying the protocol. If it is defaulted, the protocol of the current page is used; e.g., //www.example.com becomes http://www.example.com or https://www.example.com depending on the URL of the referring page. If a web page is saved on a local disk and then opened from there, it has no protocol (just the file: pseudo-protocol), so URLs like //www.example.com won’t work; so here’s one reason for including the “http:” or “https:” part.
Omitting also the “//” part is a completely different issue altogether, turning the URL to a relative URL that will be interpreted as relative to the current base URL.
The reason why www.example.com works when typed or pasted on a browser’s address line is that relative URLs would not make sense there (there is no base URL to relate to), so browser vendors decided to imply the “http://” prefix there.
URLs in href are not restricted to only HTTP documents. They support all the protocols supported by browsers- ftp, mailto, file etc.
Also, you can preceed URL name with '#', to link to a html id internally in the page. You can give just the name or directory path, without a protocol, which will be taken as a relative URL.
My solution was to trick the browser with a redirect service, such as bit.ly and goo.gl (which will be discontinued soon), in addition to others.
When the browser realizes that the url of the shortcuts is https, it automatically releases the link image, the link is released and instead displays the http image, without showing the original link.
The annoying part is that, according to the access, it will display in the panel control of your redirector, thousands of "clicks", which is actually "display".
With this experience I'm going to look for a Wordpress plugin for redirection and create my own "redirects links". So I will have https // mysite.com /id → redirect to http link.
I'm maintaining an application that goes sort of like this:
There is a Page A with a Frame that shows Page B. Now page B is part of a completely different product in a separate domain.
Now, they want that when an option in B is clicked, the WHOLE page is redirected to another page in A. The problem is that the url of A is something like www.client.A.com/Order/Details/123, and when we click in be it should redirect to something like www.client.A.com/Order/Edit/123 but B doesn't know anything about A. It doesn't know which order # is currently selected or anything about A. Page A who has the frame B does know it.
For now my solution has been to just redirect to the AllOrders so something like client.MyCompany/Orders
but since B doesn't know which client is calling it (its a multi-tenant app), I'll add it in the webconfig. (so each client has its own webconfig with a different value).
I dont find this solution optimal but I can't think of anything else! I already tried putting the needed url in page A in a hidden Div (since A does know all the info) and then trying to read the whole DOM of the page from B to find it.... unfortunately I can only get access to Frame B's DOM... (I tried with jquery).
I know frames are evil, but this is how it is written... any ideas?
Thanks!
If the parent page A and the iframe page B are in different domains, you will not be able to access methods or fields via B's parent property, nor will script in A be able to reach into B's content, nor will you be able to share global variables between A and B. This boundary placed between page A and page B is a key part of the browser security model. It's what prevents evil.com from wrapping your online bank web page and stealing your account info just by reading the internal variables of the javascript of the bank's web page.
If you have the luxury of requiring the latest generation of browsers, you can use the postmessage technique mentioned in one of the other answers here. If you need to support older browsers, you may be able to pass small amounts of information using cross-domain client scripting techniques in the browser. One example of this is to use iframes to communicate info between the outer page A and the inner page B. It's not easy and there are many steps involved, but it can be done. I wrote an article on this awhile ago.
You will not be able to monitor clicks in B's iframe from the parent page A. That's a violation of browser security policies at multiple levels. (Click hijacking, for one) You won't be able to see when B's URL changes - A can write to the iframe.src property to change the URL, but once the iframe.src points to a different domain than A's domain, A can no longer read the iframe.src property.
If A and B are in different subdomains of the same root domain, you may have an opportunity to "lower" the domain to a common root. For example, if the outer page A is hosted in subdomain A.foo.bar.com, and B is hosted in subdomain foo.bar.com, then you can lower the domain in page A to foo.bar.com (by assigning window.domain = "foo.bar.com" in A's script). Page A will then behave as a peer of page B and the two can then access each other's data as needed, even though A is technically being served from a different domain than B. I wrote an article on domain lowering, too.
Domain lowering can only peel off innermost subdomains to operate in the context of a root domain. You can't change A.foo.bar.com to abc.com.
There is also a slight risk in lowering domains to a common root domain. When you operate your page in its own subdomain, your html and script are segregated from the other subdomains off the common root domain. If a server in one of the other subdomains is compromised, it doesn't really affect your html page.
If you lower your page's domain to the common root domain, you are exposing your internals to script running on the common root domain and to script from other subdomains that has also lowered its domain to the common root. If a server in one of the other subdomains is compromised, it will have access to your script's internals and therefore it may have compromised your subdomain as well.
in case the page & frame are not on the same domain, you'll have to use postmessage as the same-domain policy prohibits normal javascript-communication between pages/frames of different domains because of security concerns.
postmessage is part of html5 and works in all modern browsers (including IE8). if you need support for older browsers (specifally IE6/7), you could use the jQuery postmessage plugin (which transparently falls back to some nice hash-tag trickery for older browsers).
and as a sidenote: not sure if frames are evil, there are some problems (usability, SEO, ...) related to them, but i did some research and most of these can be tackled i think.
If you want to communicate between frames in javascript you can use 'parent':
If frame A has a variable value, eg:
var orderNo = 2;
For frame B to read it it would refer to
var frameA_orderNo = parent.frames[0].orderNo;
(assuming that frame A is the first frame declared)
So you can set up global variables within each frame that the other frame can read and therefore you can get the order # in old fashioned javascript (never tried it in jquery).
Wow frames - never thought I'd think about them again.
I have a page on a website that contains a secure form inside an iframe. Although the form data submitted is secure the page doesn't appear secure as the URL in the browser is just HTTP. Is there anything I can do to show the users that the form is secure?
Although the form data submitted is secure
It may or may not be encrypted. But it's not secure, and the browser is absolutely correct to deny you a padlock icon.
If the parent page is http, then that page could easily have been altered by a man-in-the-middle attack to point the usually-secure <iframe> to a completely different server to the expected one. Or, the parent page might have had JavaScript injected into it to log any keypresses you make into the form and send them to the attacker's server.
The user would have no way of checking whether this had happened, short of viewing the page source and reading and understanding every line of markup and script inside it. This is absolutely unrealistic.
If you aren't on a page where all content is secured by https, any submission from that page is insecure, regardless of where the form action is pointed.
Open the form in a new window or host the container page on a secure server. Users have a right to be skeptical of an insecure page hosting a supposedly secure page -- it's practically begging for XSS attacks.
Whether the host page is secured or not, placing https secured pages inside an iframe is not a good idea. Even https pages are not invulnerable to xss and MIM attacks. The only way to avoid any confusion as to which domain/web server your web browser is talking to is go direct to the source page - i.e. the one you are trying to put inside your iframe.
Iframes are a convenient way to quickly include content from another page/site, but they open up a whole bunch of opportunities to the dishonest!
Nothing that will trigger the usual browser "This is secure" indicators.