The Dangers of Trusting User Input

June 01, 2016
Info notes

Where is the problem?

In a previous Info note, we discussed the ImageMagick vulnerability, which enables attackers to perform remote code execution (RCE) on a large number of web servers. According to that Info Note: "the issue is that the user input is not sanitized and shell command injection is possible". Moreover, to put things into perspective the root cause of that vulnerability and the key explanation of its effectiveness, is that a legacy programme or library can be used in a new context, without having been subjected to input sanitation and validation first. This enables to use a feature of the original code for an attack. Note, this is not the first time a library not intended to be used online gives attackers the ability to perform arbitrary code execution. Shellshock is a similar in nature vulnerability. This Info note focuses on the risks of trusting user input, the importance of user input sanitization and validation, recommendations indicating best security practices to limit such attacks and the need to fund open source projects for security purposes.

The importance of user input validation

In 1981 Jon Postel's quote "Be liberal in what you accept, and conservative in what you send" formed what's known as the "Robustness Principle or Postel's law", a fundamental implementation guideline for the then newly introduced TCP protocol. The robustness principle was quickly adopted in network design, programming languages, software development etc., but despite its wide acceptance at that time, it would be later challenged by information security specialists.

Nowadays, being liberal in what one accepts may lead to serious security risks: buffer overflows, remote code execution, Cross Site Scripting (XSS), SQL injections, to name but a few. Handling unexpected user input in a secure manner is an application design decision. In fact, one of the fundamental application security principles is to never trust user input.

User input validation is hence a necessary step in software design. Often, it is preceded by input sanitization, which is a complementary method that implies changing the user input to an acceptable format rather than refusing it, should it fail to pass the first step.


ImageMagick is a representative example of a piece of software originating in the 1990s that was not originally designed with application security in mind:

  • No sanitization of commands when passed to external libraries.
  • User input considered legitimate by default.

To be fair, ImageMagick was not intended to be used online but instead to be used locally as a command line tool to quickly perform image processing. It was latter interfaced in many programming languages and included in several web frameworks as an easy and lightweight image processing solution. With that being said it does not mean that ImageMagick should not adopt secure coding techniques but it denotes what was pointed out in the ENISA's report on Shellshock: "The bug, which has little impact in the intended environment, can now have devastating effects". Additionally when such vulnerabilities are disclosed it is sometimes difficult to point the finger only in one direction. The issue is more complicated when certain code is reused in different context and more parties are involved. Thus input/data validation must be a holistic approach performed in every tier.


For developers

Code reviewing, to systematically examine code for overlooked mistakes, hereby preventing potential vulnerabilities at an early stage, is essential. OWASP offers guidance on how code reviewing should be structured and executed with the OWASP Code Review Project.

Nowadays it is critical for every application and especially web applications, to comply with known secure coding techniques such as OWASP's Secure Coding Practices. In regards to input validation the most recommended approach is white listing wherever possible. In white listing validation developers define legitimate input and anything else is rejected before processed by the application.

Developers must be very careful when including external components in web frameworks for various operations. They must evaluate the risks these components may hinder when used in a different context than the context they were originally designed for and assess potential vulnerabilities by incorporating security mechanisms on their own, e.g. proper input validation.

Essentially, security aware project governance is the key for guiding the implementation of a project and making sure the above security best practices are incorporated into the software development life-cycle in a systematic, organized and coherent manner.

For administrators

Administrators need to be well aware of the infrastructure they maintain to determine rapidly the consequences of a vulnerability in a component or software they manage.

Administrators must not rely on default settings when installing software. It is best practice to disable unwanted features for security but also maintenance reasons.

They must enforce file access policies, configure applications to use appropriate permissions, and limit upload permissions in order to reduce the surface of the attack especially in cases of malicious file uploads.

Administrators should be more security conscious and proactive by enhancing the perimeter security and using a Web Application Firewall in order to limit attack vectors that manipulate application data input.

Funding security research and auditing

In order to pinpoint security weaknesses and harden security practices, some widely used projects receive public funding for third party audit, e.g. OpenSSL, OpenSSH. However, for most open source projects, it is very challenging to perform such audits with no or limited funding relying on voluntary work. It would be beneficial for projects generally and for open source projects in particular to receive funding for security auditing purposes similarly to the Core Infrastructure Initiative which is a Linux Foundation collaboration project aiming to support security in open source projects. The European Research Council has recently funded open source projects for code auditing, secure coding and cryptographic design processes. EU can intensify its efforts towards that direction and play an important role in enhancing cyber security in Europe by helping European security researchers perform security auditing and code reviewing in well-known and widely used open source projects.


In the aftermath of ImageMagick vulnerability it becomes evident that select vulnerabilities thrive in the absence of suitable implementation of security principles and measures such as input validation. Furthermore, the context in which these vulnerabilities occur is also important to consider. It is essential for development teams as well as administrators to be security conscious and always implement best security practices to limit the risk of being affected by trivial vulnerabilities. In the contemporary and ever increasing hostile cyber environment, there is a lot of room for supporting security in open source projects, an opportunity that EU should embrace as an additional layer towards a safer cyber Europe.

About "Info Notes" from ENISA

With the "Info Notes" series ENISA aims at giving the interested reader some background and recommendations about NIS related topics. The background and recommendations are derived from past experiences and common sense, and should be taken as starting points for discussions on possible course of action by relevant stakeholders. Feel free to get in touch with ENISA to discuss or inquire more information on the "Info Notes" series (

We use cookies on our website to support technical features that enhance your user experience.
We also use analytics. To opt-out from analytics, click for more information.

I've read it More information