Is there any way to detect that a users browser hasn't enabled the Allow mixed content feature?
What i want is that if it isn't enabled, the div where the http-iframe should otherwise load displays some text telling the user what went wrong.
You should read this article: http://blogs.msdn.com/b/ieinternals/archive/2009/06/22/https-mixed-content-in-ie8.aspx
I assume that you own the secure site? if so you should consider proxying the insecure content.
anyway you could reference an image/script from the source handle errors on the "onload" event. that should do the trick.
Related
Currently, I am facing an issue with HTML page. So here if a user visited the site then the browser is caching the entire HTML page. So when the user hits the URL again then the browser taking that HTML from the cache instead of calling/requesting to the server for HTML contents. Here our Team member forgot to add meta tags which would force the browser to take content from Server each time. Is there any way that we could resolve the issue? Since the page request itself not reaching the server so User will not see the refresh contents of the website. If user do Ctrl+F5 then they can see updated contents. I went through many sites and stack overflow questions but I did find a solution for forcing HTML page to load contents from server using meta tags.But existing users is there any resolution that we could apply?
Problem is here the page did not call server to get contents it just loads from cache.
There's nothing you can do.
You've previously instructed the browser to cache the file (presumably for a long time) and not check for updates (via ETags or If-Modified-Since) so it is going to use the cached version until its cache expires (from the user intervening or automatically (which might be sooner than your caching instructions said)).
There's no way to provide new caching instructions to the browser without it requesting them from the server (which it won't do because of the existing rules).
By Default, Chrome blocks mixed content. This can be circumvented as per How to get Chrome to allow mixed content?.
Now I reconfigured my website to no longer need mixed content to be allowed. How do I reenable it? The page still shows as "insecure" next to the URL because of it.
Simply restarting chrome will do the trick. Use Ctrl+Shift+T to reopen all tabs. Keep in mind that data entered into forms may be lost.
We have on the public part of our web app some mailto: links in the footer. Someone or something (aka bot) keeps hitting these links and navigating to https://basurl/mailto:some#email.com which results in errors as the webserver isn't happy with the colon in the url.
I assume this is a client setting and outside of our control, correct?
What are the option to prevent this beside obfuscating the link with javascript, also hiding it for bots?
If this is a defective client and not a bot the javascript solution wouldn't help either.
I could supress this kind of error but this is more preventing the symptom instead of the cause...
I assume this is a client setting and outside of our control, correct?
Yes.
What are the option to prevent this beside obfuscating the link with javascript, also hiding it for bots?
It's a bad bot. It probably isn't doing anything good for you. You could examine the IP ranges it comes from and the user agent it sends and block it entirely.
I've been reading up on HTML5's sandbox attribute for <iframe>s. According to the documentation the sandbox attribute allows a developer to selectively restrict what actions can be done in an <iframe>. Is the sandbox attribute purely a security measure? Does the sandbox attribute enable web designers to implement any new functionality and if so can anyone point to any examples?
Well, it is purely a security feature, but it does allow new functionality as well. Take for example embedding third party (user) content (e.g. HTML files). Traditionally you would need to set up a separate domain from which you would serve that content, now however you can simply serve it from wherever you want to and have it treated as if it's from a separate domain.
On top of that it can prevent this third party content from doing certain things, which you could not have prevented previously like:
allow-top-navigation: Preventing it from breaking out
allow-pointer-lock: Preventing it from taking the cursor hostage
allow-popups: Preventing it from breaking out through popups
allow-scripts: Simply blocking all scripts (could also have been done through CSP)
Realistically the combination of the sandbox attribute combined with controlled CSP headers gives an incredible amount of control to run third party code in a safe environment. It's not 100% there yet, but we're getting quite close.
The sandbox can actually be pretty handy in testing. Consider the following:
tester.html
<script> document.cookie='foo=bar' </script>
<iframe src=testee.html>
testee.html
<script> console.log(document.cookie) </script>
When loading tester.html you will see on the console "foo=bar" which was dumped by testee.html.
Now add to the iframe the sandbox attribute and the cookie is gone - the sandbox created a separate runtime environment for testee.html, where it doesn't get cookie pollution from other pages that were/are open in the browser during the development process. So when you need a sterile test bed but can't or don't want to clear the browser cache, here's a quick and simple solution.
The sandbox attribute does not enable any extra functionality, it only restricts the functionality of the iframe. The only reason to use it is as a security measure.
The iframe sandbox is purely a security feature. A good resource is always the W3 HTML5 specification.
When the attribute is set, the content is treated as being from a unique origin, forms, scripts, and various potentially annoying APIs are disabled, links are prevented from targeting other browsing contexts, and plugins are secured.
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.