Best practices for accepting user data

This article shows how to validate input -- one of the first lines of defense in any secure program.

In July, 2003, the CERT Coordination Center reported a dangerous set of vulnerabilities in Microsoft Windows' DirectX MIDI Library. The DirectX MIDI library is a low-level Windows library for playing music stored in the MIDI format. Unfortunately, this library failed to check all the data values inside MIDI files; incorrect data values for the fields "text," "copyright," or "MThd track" in a MIDI file could cause the library to fail and attackers could exploit the failure to make the system run any code they wanted. This was especially dangerous, because Internet Explorer, when it viewed a Web page with a link to a MIDI file, would automatically load the file and try to play it. The result? An attacker could simply post a Web page that when viewed would make the browsing user's computer erase all its files, send all its confidential files elsewhere by e-mail, crash, or do whatever else the attacker wanted.

Check your input

In nearly all secure programs, your first line of defense is to check every piece of data you receive. If you can keep malicious data from entering your program, or at least keep it from being processed, your program becomes much harder to attack. This is very similar to how firewalls protect computer networks from attackers; it won't prevent all attacks, but it does make a program much more resistant. This process is called checking, validating, or filtering your data.

One obvious question is, where should the checking be performed? When the data first enters the program, or later by a lower-level routine that actually uses the data? Often, it's best to check in both places; that way, if an attacker manages to slip around one defense, they'll still encounter the other. The most important rule is that all data must be checked before it's used.