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.
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.
I'm trying to submit a form back to my server using POST and the target is at the same domain (which is HTTPS) however when I submit I get a Mixed Content error. Does the form post not follow the same protocol as the hosting page? If so what is the best way to fix it without always specifying the full url (I use sub domains for different companies)
Does the form post not follow the same protocol as the hosting page?
It does if a relative URL is specified.
e.g. path relative
action="/form/foo"
or protocol relative
action="//example.com/form/foo"
It appears you have something on your action page, or the page that it redirects to loading over plain HTTP. Use developer tools to hunt out this reference.
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.
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.
I have a website in which every page is served via HTTPS. On one of the pages I have a form whose action attribute is set to a relative URL.
The page with the form can only be accessed via HTTPS and the page the form posts to can only be hit via HTTPS, yet in IE I get a security warning telling me I'm about to switch to an insecure connection. Is there any way to prevent this problem beyond codding the full URL including the protocol into the form's action attribute?
Update:
I tried hardcoding the entire URL and still I get the pop-up.
The relevant code is:
<html>
<body>
<form action="https://mydomain.com/editProfile">
...
</form>
</body>
</html>
As soon as I click the submit button in IE6 I get a security alert pop-up. If I click ok, the result page is displayed and the protocol is still HTTPS. I'm starting to wonder if it is the form POST that's causing the issue.
You can't (other than setting the base URL to https). According to RFC 1808 (relative URLs), an URL starting with a scheme name is always interpreted as an absolute URL (section 4, step 2a).
(As others pointed out, relative URLs keep the scheme, so the problem was elsewhere, probably with an unencrypted image or CSS file, but the question was interesting in its own right.)
Internet explorer is notorious for demanding that there are NO http requests in your https page or the security popup pops up.
Are all your links in the page relative?
Are there no hidden redirects in your webserver?
Think about pictures/css files/javascript files, can they all be retrieved using https?