I have started developing a web app using React.js that serves as the front-end for a bigger project. Cutting to the chase, my issue is that I cannot find a way to communicate with a secure (https) API. This is running locally, and since my organization has self-signed certificates the browsers do not accept them. Namely, Chrome, Firefox, Edge, and Opera were used, with all of them resulting in more or less the same error: NET::ERR_CERT_COMMON_NAME_INVALID and Cross-Origin Request Blocked.
Some context regarding the followed process around the certificates. They were installed both at the user and at the local machine levels as trusted authorities, without and with administrative rights. They were also imported into the browsers, all the while every endpoint has CORS enabled. Still, the errors remain and I am unable to seize data from a single axios GET call. As expected, when trying to communicate with the same non-secure (http) API, all calls go through without issues. Additionally, Postman and curling both yield desirable results in every case.
I have not found a way to bypass this error so that I can move on with my implementation. I have also advised several other questions here, like:
How to generate a self-signed SSL certificate using OpenSSL?
Getting Chrome to accept self-signed localhost certificate
accepting HTTPS connections with self-signed certificates
Any assistance is most welcome. I bid you all a lovely day!
Related
I am intercepting HTTPS requests of android apps in my phone through Fiddler for pentesting purpose. I have installed fiddler certificate in my android phone, so that I can intercept HTTPS request.
My question is that, I can see the HTTPS requests from and to my phone in clear text in Fiddler. So, is it a bug of an android app or is it normal to see HTTPS request in clear text ?
please help I am new in pentesting world :)
It doesn't sound like anything is wrong.
HTTPS is HTTP wrapped in an encrypted tunnel created using the Transport Layer Security (TLS) protocol (which in many contexts is synonymous with SSL). It sounds like you're installing the Fiddler Certificate Authority certificate on the phone. By doing this, you're telling the phone: "Fiddler is allowed to generate new TLS certificates for any host". The phone should then be perfectly happy to accept a TLS certificate generated by Fiddler rather than the actual app's TLS cert, Fiddler can therefore intercept the HTTPS traffic, intercept it and pass it upstream. In the real world it would be infeasibly difficult for the attacker to install a CA certificate on a target's phone, thus the attacker would be prevented from intercepting and reading the HTTPS traffic.
It is possible to force an application or user agent to only accept a given certificate (this is called certificate pinning). It's also possible to force an application to only use HTTPS (HTTP Strict-Transport-Security). There are other relevant controls but these are probably worth looking into.
In the mean time, check out https://en.wikipedia.org/wiki/Certificate_authority.
I'm looking to implement a running express server using https, powering an AngularJS application. Currently I have the majority of the application running just on http, but would like to switch over. This isn't a publicly available application. Am I ok to simply use self-signed certificates to implement this in our production environment? Or should I be going through a trusted certificate authority even for internal use?
Using OpenSSL seems pretty simple to generate the key and pem files... but I feel dumb when it comes to acquiring something through a trusted authority. If it's recommended that I DO in fact use a trusted CA, and not self-signed, could someone point me in the right direction on where to go for this?
The answer is "it depends".
You can certainly use self-signed certs, but you will have to manually make sure that all your endpoints are configured to trust your self-signed certs. This is what a trusted certificate authority is used for. The browser has pre-built trust for certificates issues by various public certificate authorities and, in turn, they agree to follow certain procedures related to issuing their certificates. If you go through that process, then browsers will automatically recognized and trust https connections using your certificates (assuming everything is as expected with the connection). If you don't go through that process, then you have to manually tell each endpoint that is going to access your application to trust your certificates. For closed applications with a small number of controlled endpoints, this is very feasible. For open applications or applications with a wide variety of endpoints (random browsers, phones, etc...), this is difficult.
And, you do not want to "teach" your user base to either ignore security/certificate warnings or to blindly trust things that the browser tells them might be insecure so you want to not leave this to your users - you want to pre-configure the endpoints to trust your new self-signed certs.
To give you an example, there are home security camera systems that have web access. If the only ways you need to do web access are from 2 or 3 different browsers, it's not really a problem to use a self-signed cert and configure those 3 browsers to trust it.
But, if you had some web application that many different people would access, then it wouldn't really be practical to manage the certificate trust on a rotating set of browsers and it would just be a lot less complicated and a lot more likely to be secure to use a trusted CA.
Personally I prefer using CA trusted certificates over self-signed certificates for production environments (or even developer environments) since you need to trust/add exceptions or overwrite programatic SSL checks when you are using self-signed certificates.
If you decide to use CA trusted certificates, I recommend looking into Certbot + Let's Encrypt. It is a trusted CA and supports most of the famous servers. It is also free and really easy to use. The only downside is that you need to renew the certificate every 3 months. This too can be automated depending on your platform/server.
The Application
In short, the application surfaces data from a backend onto a web page. The client application is a Single Page Application made using AngularJS. It calls an ASP.NET Web API service located on a different domain to retrieve the data. I utilize BreezeJS on both the client application and the web service to manage this data. The client is hosted on a SharePoint Online site, and the service is hosted on IIS7.
The Error
I encounter an "Access is Denied" error when AngularJS attempts to make an XMLHttpRequest.open() call targeting this web service. However, though this seems like a simple CORS issue, it has some peculiarities which have me stumped:
Foremost, this error only occurs when using Internet Explorer 11 (or a previous version). When the application is viewed in Chrome or Firefox, it can connect and retrieve data from the service.
The web service is configured to accept the calling origin.
No network traffic is detected either by the native IE development tools or by Fiddler.
Specifically, the line: xhr.open(method, url, true); of the angular.js file throws this error.
Does anyone have any insight as to why this error occurs?
Also, if more specific details are needed I certainly can provide them. I'm not even sure where the issue might be coming from and I don't want to dump tons of irrelevant lines of code.
I think that this is due to using "localHost", i.e when attempting to access a resource in the "Local intranet" zone from an origin in the "Internet" zone.
See: Access denied in IE 10 and 11 when ajax target is localhost
This is not just a localhost issue as previously suggested. I have a production AngularJS application that is trying to POST to a public Web API 2 on a different domain. IE11, Chrome, and Firefox work without a hitch when the site is accessed externally. When accessing from a subnet that can talk directly to those servers, I get Access Denied and IE doesn't even send the request (Chrome and Firefox work flawlessly, of course. One workaround (I refuse to call this a fix) is to add the site as a Trusted Site in IE11. Even when the security settings for Internet mirror the settings for Trusted Site, I get access denied. I have to add the site on each internal IE system to gain access.
We can activate secure connection for backends but as oppose to front-end we get this certificate warning: (is there a solution to no get this warning?)
This is probably not the site that you are looking for!
You attempted to reach backend.xxxx.appspot.com, but instead you actually reached a server identifying itself as *.appspot.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of requestprocessor.qminer-trial.appspot.com.
You cannot proceed because the website operator has requested heightened security for this domain.
Help me understand
When you connect to a secure website, the server hosting that site presents your browser with something called a "certificate" to verify its identity. This certificate contains identity information, such as the address of the website, which is verified by a third party trusted by your computer. By checking that the address in the certificate matches the address of the website, it is possible to verify that you are securely communicating with the website that you intended and not a third party (such as an attacker on your network).
In this case, the address listed in the certificate does not match the address of the website that your browser tried to go to. One possible reason for this is that your communications are being intercepted by an attacker who is presenting a certificate for a different website, which would cause a mismatch. Another possible reason is that the server is set up to return the same certificate for multiple websites, including the one you are attempting to visit, even though that certificate is not valid for all of those websites. Google Chrome can say for sure that you reached *.appspot.com, but cannot verify that that is the same site as requestprocessor.qminer-trial.appspot.com which you intended to reach. If you proceed, Chrome will not check for any further name mismatches.
This is a known issue: http://code.google.com/p/googleappengine/issues/detail?id=7288
It's a limitation of SSL and browser implementations: Wildcard subdomains on appengine over https on firefox
The workaround, as per docs, is to use -dot- in place of dots in your subdomain name: subdomain-dot-domain.appspot.com
This surely works for subdomains (tested), but I'm not sure if it works for backend domains. Please test it and let us know.
Update:
I tested this on one of my test backends (forgot it's still up) and it works as expected with the -dot- workaround.
I am working on writing a OMS implementation. I have verified that service is compliant with the service and schema definitions.
When trying to set up the account in Outlook 2007 to test the service, it allows me to use an https address, but not an http address.
According to the documentation (http://msdn.microsoft.com/en-us/library/bb277363.aspx) "The URL of the OMS Web service can be either http or https, but it is https if not otherwise specified"
I have not been able to find any doucmentation that would explain why Outlook will not even let me try to do anything in the wizard if the service url does not start with https.
The error that it returns when a http address is entered is:
The web service address is incorrect or corrupted. Check the web service address or contact your administrator
I have also tried creating a temporary cert on my local machine to test the service, but outlook is rejecting the cert because it is not valid.
Is there any way to test the service or run it over http?
You are not alone in seeing this error, we've also come across this issue, one of the 3! comments on the msdn documentation also reports an issue with using http (http://msdn.microsoft.com/en-us/library/community/history/bb277363.aspx?id=2)
Apart from exposing your service as https there doesn't seem to be a way around this :(
Connection Security
To protect the information as it is
transferred over the Internet, OMS Web
services are required to support SSL
(Secure Socket Layer) encryption. SSL
can be used to establish more secure
connections on untrusted networks,
such as the Internet. SSL enables
encryption and decryption of messages
exchanged between client and server,
thereby helping to protect messages
from being read during transfer.
http://msdn.microsoft.com/en-us/library/bb277361(v=office.12).aspx#OfficeOutlook2007OMSMobileServicesGuidelinesPt1_CommunicationProtocols