Strict Transport Layer Security (STLS)
Mobile applications communicate with their backend servers over a network, as servers are located elsewhere. Network channels could be secured (encrypted) or non-secured. Encryption makes data unintelligible, preventing its misuse by ensuring confidentiality even when communication is intercepted. Servers and applications have keys needed for decrypting data. Whether a mobile app (client) would encrypt outbound communication or not depends on what security mechanism the server supports. If the server provides a secured connection (URL starts with HTTPS), then the app’s outbound data would be encrypted. If the URL begins with ‘HTTP’ only (non-secured), then the data would be sent in the plain-text format. Let us have a look at an example where an attacker exploits this scenario and harms an application’s users.
A mobile application communicates with its server that supports secure connections. An attacker wants to gain access to the application. He creates a replica of the server’s login page. The duplicate page’s address begins with ‘HTTP’. The attacker carries out DNS poisoning (A malicious trick to route the communication to a different destination). A user opens the application and gets redirected to the attacker’s login page, as a result of DNS poisoning. The app sends over login credentials in the plain-text format. The attacker uses the credentials and gets access to the server. He injects a malicious code into the server. The code downgrades the server’s security so that all communications with server remain unencrypted. This way, the attacker manages to obtain the other users’ login credentials as well. Using those, the attacker accesses their account on the server and collects sensitive information.
The solution is to enforce strict transport layer security (STLS). When implemented, servers ask applications to communication only in an encrypted fashion. Once instructed, the app would refuse to communicate with systems that are not HTTPS compliant.