Develop Reference

Can an HTTPS web application make calls to a non-HTTPS origin?

I have a small web application that needs to make calls to a device on my local network. It does this using fetch to the local IP address of the device (e.g. http://192.168.1.25:8060). The device does not serve its traffic over HTTPS and cannot. The web application is public facing and I would like to add a service worker for offline support.
Service workers require HTTPS, and calls from an HTTPS origin to a non-HTTPS origin are a security risk and so are not allowed by modern browsers. Without using a local proxy (which would defeat the purpose), is there some way around this "limitation"?
How can "https://example.com" make a call to http://192.168.1.25:8060?

Possible duplicate of How can I allow Mixed contents (http with https) using content-security-policy meta tag?. Browsers won't allow this because it breaks the user trust model.
A local HTTPS proxy is ideal. Configure a public DNS entry like internal.example.com with a low TTL (if your internal IP changes often) to point to your internal IP. Create a trusted SSL cert for that subdomain, then run your local HTTPS proxy with that SSL cert. If your internal server is behind a firewall, point internal.example.com to a public web server first, create the cert on that public server, than copy the cert and change the DNS to your local server. Or use a wildcard cert *.example.com to avoid that "temporary public" hassle entirely.

Why do I get a getCurrentPosition() and watchPosition() "insecure origins" error in Chrome on localhost?

I'm working on a website in my local development environment (Ubuntu 16.04) and testing the website on Chrome (58) via http://localhost.example/ - which connects to the local web server.
Running this Javascript:
$(document).ready(function() {
if (navigator.geolocation) {
navigator.geolocation.getCurrentPosition(showPosition);
}
});
Triggers this error:
[Deprecation] getCurrentPosition() and watchPosition() no longer work
on insecure origins. To use this feature, you should consider
switching your application to a secure origin, such as HTTPS. See
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins for more details.
Why is that? I understand that public facing websites need to be running HTTPS for the geolocation library/ functionality to work. We have a number of public websites running similar code across HTTPS.
However according to the depreciation documentation:
localhost is treated as a secure origin over HTTP, so if you're able
to run your server from localhost, you should be able to test the
feature on that server.
The above Javascript is running in-line in the HTML body loaded via http://localhost.example/test-page/ - so why am I getting the "insecure origins" error in Chrome?
Firefox (53) shows the in browser access location prompt, as expected.

Chrome considers localhost over http as secure. As you are using hostnme localhost.example over http, this is not considered as secure.
Note: Firefox will behave similarly as of Firefox 55

SSL over HTTP protocol ensures the private communication within Client and Server. The information might transmit through the private networks while transmission. Any third person (hacker) on the network can steal that information. To avoid that browser forces the user to use a secure connection.
On the local server, the information is not going beyond our private local network since there is not need of this kind of security. So we can expect a browser to allow geolocation without SSL on the local server. Ideally, the browser developer should skip this validation for localhost and 127.0.0.1 or similar origins.
There must be tricks available to avoid such issues i.e. you can install self-signed SSL certificate on the local server or you can edit the Chrome configuration file to allow domains to access the geolocation, webcam etc.
Helpful links,
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
https://ngrok.com/

SOP violation in paho mqtt

when I am trying to use Paho MQTT javacrript with Mosquito MQTT websockets, everything works as long as the web server that I am using to serve my page and Mosquito are in the same server (same origin). However, if I try to connect to a different Mosquito instance (cross domain), Firefox throws a security error.
Problem is that the Javascript client initiates a http connection to the Mosquito web socket server and it gets upgraded to ws:// as part of negotiation. Had the initial request itself been over ws:// , SOP would not have kicked in.
I tried to connect to the second server from http://mitsuruog.github.io/what-mqtt/ and it works fine without SOP error. So, I know that the server can support ws:// . How to get this done using the Paho implementation?
Is there any way to work around this?

The issue is that I was trying to initiate an un-secure (ws:// instrad of wss://) while the page was itself loaded over https:// . This results in a mixed content error that is not explicitly reported by Firefox. Chrome prints a better warning and allows to temporarily bypass it as well.

What is the correct CORS entry for limiting an http:// connection to a remote, hosted web server from a grunt web server on a home network?

I've setup a remote, hosted javascript server (DreamFactory Server http://www.dreamfactory.com/) that responds via REST API's.
Locally, I'm running an Angularjs application through the grunt web server via $grunt serve
https://www.npmjs.com/package/grunt-serve
I have setup CORS on the remote server to allow '*' for multiple http:// connection types. THIS WORKS CORRECTLY.
My question is how I can limit the CORS configuration to only allow a connection from my home, grunt web server?
I've tried to create an entry for "localhost", "127.0.0.1", also my home Internet IP that is reported from whatismyip.com, the dns entry that my provider lists for my home IP when I ping it, a dyndns entry that I create for my home internet IP... None of them work, except for '*' (which allows any site to connect).
I think it is an educational issue for me to understand what that CORS entry should look like to allow ONLY a connection from my home web server.
Is this possible? If so, what and where should I be checking in order to find the correct entry to clear in the CORS configuration?
-Brian

To work and actually apply restrictions, the client requesting the connection must support and enforce CORS. In an odd sort of way (from a security point of view), restricting access using CORS requires a self-policing client (one that follows the prescribed access rules). This works for modern browsers as they all follow the rules so it generally works for applications that are served through a browser.
But, CORS access restrictions do not prevent other types of clients (such as any random script in any language) from accessing your API.
In other words, CORS is really about access rules from web pages that are enforced by the local browser. It doesn't sound like your grunt/angular code would necessarily be something that implements and enforces CORS.
If you really want to prevent other systems from accessing your DreamFactory Server, then you will need to implement some server-side access restrictions in the API server itself.
If you just have one client accessing it and that client is using "protected" code that is not public, then you could just implement a password or some sort of logon credentials and your one client would be the only client that would have the logon credentials.
If the access is always from one particular fixed IP address, you could refuse connections on your server from any IP address that was not in a config file you maintained.

You can't secure an API with CORS, for that you will need to implement an authentication scheme on your server. There's essentially 4 steps to do this.
Update the headers your server sends with a few additional Access-control statements.
Tell Angular to allow cross-domain requests.
Pass credentials in your API calls from Angular.
Implement an HTTP Authentication scheme on your web server or in your API code.
This post by Georgi Naumov is a good place to look for details of an implementation in Angular and PHP.
AngularJS $http, CORS and http authentication

Error when using ssl with websocket

I am using ssl communication with websocket.
so I added the secure communication in my javascript code like this "wss://myip"
when lunch a websocket communication from my page with https://myip
i get the following error.
failed: Error in connection establishment: net::ERR_SSL_PROTOCOL_ERROR
I am using lighttpd server and chrome navigator on a linux machine.
could any one help me?thanks in advance

At present, this does not appear to be supported by lighttpd. The following link suggests using HAProxy as frontend to proxy the traffic to the websockets application:
Redirecting websocket traffic on port 80 with lighttpd
(actually without lighttpd)