The importance of input validation in IoT security

Nazli Kuran, cybersecurity expert at Kiwa

Cybersecurity has been a passion of mine for years. My journey in this field began out of curiosity, leading me to specialize in web penetration testing. Since joining Kiwa, my focus has shifted to IoT security, with an emphasis on testing against standards like ETSI EN 303645. One topic that consistently fascinates me is input validation—an area where web penetration testing and IoT security assessments often intersect.

Input validation is specifically addressed in provision 5.13-1 of the ETSI EN 303645, making it a key focus of my work. Let’s explore why it’s so crucial for securing IoT devices and how it fits into broader cybersecurity efforts.

What is input validation?

Input validation acts as a gatekeeper for the data entering your IoT device, ensuring it’s safe and correctly formatted. Imagine it as a security guard at a building entrance - only allowing in individuals who meet the requirements. For example, an IoT thermostat expecting a temperature input between -20°C and 40°C should not accept absurd values like 10,000°C, which could crash the system or create opportunities for attacks. Without this verification, IoT devices become vulnerable to a wide array of threats, including injection attacks.

Why is input validation crucial in IoT?

IoT devices often operate in environments where they process data from numerous sources: user inputs, sensors or even internet traffic. Without rigorous input validation, attackers can manipulate these inputs to execute harmful commands or gain unauthorized access to the device. Take buffer overflow attacks, for example. If a device expects 16 bytes of data but receives 64 bytes without proper validation, the excess data could overflow into other parts of the system's memory. This not only risks a system crash but could also allow for remote code execution, a severe security breach.

Are HTML tags in an embedded control unit a hidden threat?

Now, let’s imagine you’re working with an embedded control unit that unexpectedly starts processing HTML tags. It might seem like an odd quirk, but could it actually lead to a security risk, such as Cross-Site Scripting (XSS)? Let’s unpack this scenario. HTML tags function like instructions for web browsers, telling them how to display content. However, when an embedded control unit begins processing HTML, it is likely doing something it wasn’t designed to do. This deviation can lead to serious security concerns.

What’s the risk?

If an embedded control unit can process HTML tags, there’s a chance it could also execute scripts, such as JavaScript, within those tags. This is where vulnerabilities like XSS come into play. Imagine an attacker injecting a script like this: <script>alert('You’ve been hacked!')</script> If the system executes this code, a pop-up saying ‘You've been hacked!’ appears—indicating an XSS vulnerability. Hackers could exploit this to run malicious code, steal data or alter the device’s behavior.

Risks beyond XSS

Even if JavaScript isn’t executed, HTML tags still pose a risk. Here are a few potential concerns:

• UI manipulation: Attackers could modify the device’s user interface, potentially displaying false or misleading information.
• Misuse of features: HTML tags could be used to inject undesirable content or cause abnormal device behavior.
• Unauthorized access: If the system processes HTML tags, it might allow certain functions, such as form submissions, that could send or manipulate sensitive data.