I have a few applications relying on hash functions, which were developed a while ago before browsers changed their policy to restrict Crypto.subtle to HTTPS connections.
Deploying the webapps on secure connection isn't a problem for me, but testing them locally is.
Is there a configuration in about:config that allows me to change the setting, for FireFox, Chrome, and Safari?
Probably too late to help you, but there's a config flag available on Chrome that allows you to specify insecure contexts that should be considered secure.
On Chrome, open chrome://flags and search for the flag "Insecure origins treated as secure". Add the insecure context domains you want to test on and relaunch the browser. Works for me.
I couldn't find a similar flag on Firefox.
Related
I have a particularly knarly IE11 bug that appears to be caused by HTTP/2. At present the only evidence I have is that if Fiddler is intercepting (therefore forcing HTTP/1.1) the bug goes away.
In order to isolate it I really need to turn off HTTP/2 in IE11.
I've disabled HTTP/2 in Internet Options and rebooted the computer but IE11 stubbornly carries on using HTTP/2.
Does anyone who what this setting actually does?
Does anyone know how to disable HTTP/2 in IE11?
It’s a design change of Wininet component which enabled HTTP2 by default for AppContainer and LowIL processes. As we know , most of IE content process (internet and restricted zone) run as Low integrity level.
So we have two workaround:
1. Disable LCIE;
2. Add the specified URL to trust site zone or intranet zone.
Firefox 48 has a new security restriction that blocks javascript calls in iframes if the port is different. Is there a way to disable this in about:config or some other setting (basically disable the same origin policy)?
I work on an enterprise website. The site has a page like a.site.com:12345 which has an iframe b.site.com:12346. We are setting document.domain=".site.com" for both pages. The b.site.com iframe is able to make javascript calls to the parent window and access the a.site.com dom. This is working for all current versions of browsers and works in firefox 47 and lower. The new firefox 48 does not allow these calls since the ports are different.
Our production environment is fine since in prod all servers use the same SSL port but in our test environment all the servers use different/non standard SSL ports. This means we are not able to test firefox 48 without moving code to production and is halting testing efforts. While disabling the same origin policy is not desirable it is better than not testing at all. How can I disable this new security restriction?
The issue is fixed in firefox 49 nightly beta build. Looks like this was a firefox 48 issue alone.
I am working on a web development project and I was testing it primarily on Firefox. However, when I tried it on Google Chrome, it would not load completely and Chrome would warn me that the site had "insecure content". After searching for answers, I was advised to make my website use "https" rather than "http". I do not know much about SSL or anything like it, but I followed a set of instructions for setting up Apache to work with SSL. The instructions are here:
https://www.digitalocean.com/community/articles/how-to-create-a-ssl-certificate-on-apache-for-ubuntu-12-04
I followed them. The good news is, my website is accessable by https. The bad news is, unless https is typed, the website is inaccessible. On top of that, both Chrome and Firefox present messages saying "this certificate is not trusted", which is ironic, since I only did any of this to secure the site in the first place.
Can anyone show me where I went wrong or give a more complete explanation of what's going on? I am working on Ubuntu 12.10 with Apache 2 and PHP5.
you can search online to get the best SSL vendor and use that we use symantec at work http://www.symantec.com/theme.jsp?themeid=compare-ssl-certificates
use the below javascript to redirect http to https.
window.location.replace("http://stackoverflow.com");
"this certificate is not trusted" message is due to the fact that you are using a self-generated certificate. SSL uses a trusted third party (certificate authority) to ensure secure communication. You will need to purchase a certificate from one of these for your production environment. Simple google SSL certificate and you will get a whole bunch of options.
Do browser plug-ins, such as the Yahoo toolbar or others, have the ability to set cookies on multiple domains as the user browses the web? Does the browser expose the necessary access to do this to a plug-in? If this varies across browsers, that would be helpful to know as well.
Thanks!
Cookies are stored in files and real plugins (i.e. ones using NPAPI rather than the browser's addon/extension engine) can read/write files. Hence, it's possible to do for any browser this way, although not really straightforward.
Firefox exposes cookies even to addons since there are cookie editor addons (that can edit cookie for any site).
Chrome/Chromium allows setting of cookies through "content scripts" that run in the context of a page (any page) - that's only in the beta branch so far, but soon to be in stable. However, the downside is that you might have to visit the site for it to work (you could fake that using iframes).
No idea about Opera.
The only one I have found that works quite well for creating/updating/viewing cookies is Firecookie
Our web application uses Windows Integrated Authentication (aka NTLM Auth) for security.
It's working fine for both IE and Firefox users, but Safari users are seeing intermittent problems. Browsing the site will work fine, but every once in a while there will be problems loading elements of a page (e.g. CSS or JS files). Reload and the problem will go away.
If we use a debugging proxy (Fiddler) we can see that there is a lot of extra 401 requests happening with Safari. Every once in a while a request for a resource will get stuck in a 401 request loop, and eventually fail.
I can't see anything that we're doing to cause this, and it would appear that it's a bug in Safari. Has anyone ran across this issue before, and have any suggestions for a resolution?
Thanks,
Darren.
Some web sites http://www.musteat.org/nodes/show/151 indicate this is an issue with negotiated authentication.
You can turn off Negotiate in favor of pure NTLM in IIS via the NTAuthenticationProviders Metabase setting, and the following ADSUTIL command.
cscript adsutil.vbs set w3svc/WebSite/<SiteID>/NTAuthenticationProviders "NTLM"
Change < SiteID > to the appropriate ID, typically 1.