Input validation: ALL input is hostile until proven otherwise

Until you have done complete input validation, you do not know if input is hostile or not. This includes all of your communication peers, even if it is developed at your company or even if YOU developed it. As a simple example, Oracle once assumed that only their clients would be communicating with their servers. When attackers tried directly connecting to the server, they discovered that input validation was weak at best. Examples include CVE-2003-0095, CVE-2002-1641, and CVE-2003-1208, but these are not a complete list of Oracle’s problems in the early 2000s.

Even if the entity has authenticated, they are not to be trusted—successful authentication does not show intent. Plenty of attacks are initiated by insiders; they are often behind some of the most expensive attacks that you never hear about. Cross-site request forgeries mean an authenticated user might be inadvertently attacking your system.

Never trust the client

Clients are always hostile until proven otherwise. For example, some web applications (incorrectly) rely on the client to validate data. After all, in a web browser, JavaScript can validate data. However, the user controls the client, and hence the execution environment. What this means is that everything the server sends to the client is a request that the client can execute, ignore, or do whatever it wants. An attacker might run the client in a debugger, allowing changing arbitrary memory locations. Or, she might not be using the expected client, but instead using an attack tool. What this means is that if you are working on the server, you must assume that the client is sending hostile data.

In web applications, you can use client-side data validation to give the user a better experience with your software. However, you must assume that an attacker disabled the validation software, so you must also validate the data on the server. For more information, here is but one link: Client Side Data Validation: A False Sense of Security by Tarak Modi.

Never trust the server

Counterfeit cell base stations have been used to eavesdrop on conversations, collect phone information, etc. Examples include a demonstration project a Iowa State University, IMSI-catcher, a verified bogus GSM base station, information on how to build an inexpensive bogus GSM base station, and a reported man-in-the-middle (MITM) attack on 4G and CDMA systems. Unfortunately, the GSM standard originally explicitly stated that they would not even authenticate the base station—they changed this in the 3G standard, but how long will it take to upgrade every GSM base station and handset? How much will it cost?

Hostile web servers exploit bugs in web clients. Examples of what they do include:

1. make the client part of a botnet to spend spam, attack other computers, etc.
2. track the client’s movements on the web, including to the bank and then sending the username and password to the attacker
3. extract personal information, sending it to marketing types and/or criminals.

Browser flaws and social engineering can cause users to visit malicious websites. Also, hostile websites can be ordinary web sites that have been compromised. A 2008 report by John Leyden noted, “More than 10,000 web pages have been booby trapped with malware in one of the largest attacks of its kind to date.” Unfortunately, what was the largest is now normal. This type type of attack is called a “drive-by download attack”. Microsoft reported:

Blacole, a family of exploits used by the so-called Blackhole exploit kit to deliver malicious software through infected web pages, was the most commonly detected exploit family in the first half of 2012 by a large margin

This problem is not just web servers. Trusted servers (e.g. software repositories) can and have been compromised. Do you always verify the digital signature on everything you download? Where did you get the key you use to check? Could the attacker be controlling both? What about downloads without signatures? Many popular applications have had insecure update mechanisms, for examples, see Secure Software Updates: Disappointments and New Challenges by Bellissimo, Burgess, and Fu.

Even if the real server is still secure, DNS cache poisoning attacks, ARP poisoning, man-in-the-middle (MITM) attacks, and host-based malware can compromise other applications via server impersonation. Consider this example described in Malicious JavaScript insertion through ARP Poisoning Attacks by Bojan Zdrnja, in IEEE Security & Privacy, volume 7, number 3, May/June 2009:

1. An attacker compromises a machine at a hosting company.
2. They use this machine to perform an ARP poisoning attack on another web server hosted at the same place. The result of this attack is routing all of the second victim’s traffic through the first victim.
3. They modify the web pages in transit to add hostile JavaScript. A simple Internet search will turn up lots of examples.

Note that the second victim can be uncompromised and yet still be a “hostile web server” as far as their web clients are concerned. This means that if you are writing a client, you must assume that the server is hostile.

In other words, when you are working on a system, no matter whether it is an embedded system, an app for a mobile device, a client, or a server, you have to assume that your communication peer is hostile until proven otherwise. It takes more time, but the benefit is more secure code. You also get the benefit of more robust code that better withstands non-hostile bugs in peers as well.