Creating an application and presenting it to others requires a lot of different security considerations. One of the most fundamental security controls is to provide a secure communication channel between the application and the server. For web applications, that focuses on the web browser to server communications. For mobile applications, it could be a built in web browser or the application making API calls directly. If you are developing IoT devices, it is the connection between the device and the back-end server.
Secure communication is most commonly conducted using HTTPS, or WSS for web sockets. HTTPS implements TLS (SSL is no longer recommended) to encrypt the data between the client and server. The encryption of the data reduces the risk of an attacker on the same network pathway from reading or manipulating the data. In addition, the use of a certificate provides authentication of who the client is communicating with. Let’s take a look at how each of these helps reduce risk.
Authentication
The first thing we want to understand is how authentication is provided by our secure communication. Certificates are issued by certificate authorities that are supposed to verify the identity of the organization requesting the certificate. Once the application is complete, and the certificate is installed on the server, the user will receive the valid certificate. When the user visits that application over HTTPS, a green lock will typically appear indicating that the connection is secure. It is possible to dig into that status icon to get the name of the organization that requested the certificate. For organizations that get an EV (Extended Verification) certificate, it may show the organization name in the address bar.
Certificates from root certificate authorities are already trusted by most browsers. This factor makes browsing most applications seamless. If a certificate is self-signed or not from a trusted authority, browsers will display a warning message to the user. This warning helps bring to attention the fact there is an issue, or higher risk, when visiting that application. Many organizations will use self-signed certificates internally. If the certificate is not properly deployed and trusted on all the user systems, it can lead to confusion when dealing with the browser alert. It could create a situation where user’s just click through any notifications without understanding them. This authentication and trust allows the user to know who they are communicating with.
Secure Communication
Protecting the communication from eavesdroppers is critical for applications that transmit sensitive data, such as PII, credit card numbers, account numbers, etc. When data is transmitted in clear text, it is possible for others on the same network segments (between the user and the server) to potentially view that data. This allows for stealing passwords and other sensitive information.
Don’t assume that a site/application that doesn’t contain sensitive information shouldn’t be concerned with secure communication. Just because there is a lack of sensitive information, there is still a risk to the end user. Just as an attacker may eavesdrop on communications, there is also the possibility they can manipulate the traffic from the server to the client. Using this technique, the attacker can modify the response to remove security controls, modify the content displayed, or even inject malicious content into the page to attack the user directly. By encrypting the transmission, it makes it much more difficult to manipulate any of the data, helping provide more protection to the end user.
How Browsers Help
Starting this year, well, this month actually, both FireFox and Chrome are releasing updates to help notify users when their connection is insecure. The browsers already have a mechanism to help alert users of issues with certificates (self-signed, expired) and they are now adding additional notifications.
FireFox will be adding a grey lock with a red line through it when an application is found to be using HTTP (non-secure) and transmits passwords.
Chrome will be adding a notification similar to FireFox when an application is found to be using HTTP and transmits passwords or credit card numbers.
In both cases, the goal is to help notify the user that some form of sensitive information is being passed over a non-secure channel, exposing them to more risk.
What Now?
Here are a few questions to consider regarding the use of secure communications:
- Do you know what applications, in your organization, are not using a secure communication channel?
- Have you analyzed the risk around not implementing HTTPS?
- What is preventing the use of HTTPS on all of your applications?
- Do you have a plan to provide a response to users that may have questions if they see these new notifications?
- Do your QA engineers know how to identify and properly handle this scenario during testing?
There may be technical issues prohibiting the use of HTTPS. If so, are they documented and understood? The first step is having a grasp on your applications and the user base. the next step is understanding the technical details to support the appropriate implementation.
Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.
James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.