Page History

...

In addition to the letters of the English alphabet ("A" through "Z" and "a" through "z"), the digits ("0" through "9"), and the space, only the following characters can be regarded as really "safe:"

! " % & ' ( ) * + , - . / : ; < = > ?_

When naming files, variables, etc., only these characters should be considered for use.

File Names

File names containing particular characters can be troublesome and can cause unexpected behavior leading to potential vulnerabilities.  If a program allows the user to specify a filename in the creation or renaming of a file, certain checks should be made to disallow the following characters and patterns:

• Leading dashes
• Control characters such as newlines, carriage returns, and escape
• Spaces
• Invalid character encodings
• Any characters other than letters, numbers, and
  punctuation designated above as 'safe'.

Most of these characters or patterns are primarily a problem to scripts or automated parsing, but since they are not used very commonly anyway, it is best to disallow their use to reduce potential problems.  Interoperability concerns also exist because different operating systems handle filenames of this sort in different ways.  Leading dashes can cause programs when programs are called with this filename as a parameter, the first character or characters of the file might be taken to mean that its an option switch.  Control characters in a filename can cause unexpected results from shell scripts and in logging.  Spaces can again cause problems with scripts and anytime double quotes aren't used to surround the filename.  Character encodings can be a huge issue and are also discussed in MSC10-A. Character Encoding - UTF8 Related Issues.  Other special characters are included in this recommendation because they are commonly used as seperators and having them in a filename can cause unexpected and potentially insecure behavior.

Non-Compliant Coding Example: Encoding

In the following non-compliant code, unsafe characters are used as part of a filename.

...

An implementation is free to define its own mapping of the non-"safe" characters. For example, when tested on a Red Hat Linux distribution, the following filename resulted:

??????

Compliant Solution: Encoding

Use a descriptive filename, containing only the subset of ASCII described above.

#include <fcntl.h>
#include <sys/stat.h>

int main(void) {
   char *file_name = "name.ext";
   mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH;

   int fd = open(file_name, O_CREAT | O_EXCL | O_WRONLY, mode);
   if (fd == -1) {
      /* Handle Error */
   }
}

Non-Compliant Code Example: File Name

char myFilename[1000];
char const elimNewLn[] = "\n";

fgets(myFilename, sizeof(myFilename)-1, stdin);
myFilename[sizeof(myFilename)-1] = '\0';
myFilename[strcspn(myFilename, elimNewLn)] = '\0'; 

This example is borrowed in spirit from FIO30-C. Exclude user input from format strings except that we remove a newline assuming that fgets will include it.  No checks are performed on the filename to prevent troublesome characters.  If an attacker knew this code was in a program used to create or rename files that would later be used in a script or automated process of some sort, they could choose particular characters in the output filename to confuse the later process for malicious purposes.

Compliant Solution: File Name

char myFilename[1000];
char const elimNewln[] = "\n";
char const badChars[] = "-\n\r ,;'\\<\"";
do
{
 	fgets(myFilename, sizeof(myFilename)-1, stdin);
        myFilename[sizeof(myFilename)-1] ='\0';
        myFilename[strcspn(myFilename, elimNewln)]='\0';
 }while ( (strcspn(myFilename, badChars)) < (strlen(myFilename)));

In this solution, the program does not accept a filename that violates the guidelines above.  As the solution shows, you probably have to find each location in code by hand that a user is allowed to specify a filename and solve it with a similar check as above.

Risk Assessment

Non-compliance to this rule is fairly widespread, but it is also somewhat expensive to fix.  Predicting all of the possible troublesome characters is also a challenge.  A best-effort attempt at conforming to the recommendation will help reduce vulnerabilities however.

Risk Assessment

Failing to use only the subset of ASCII guaranteed to work can result in misinterpreted data.

Related Rules and Recommendations

STR02-A. Sanitize data passed to complex subsystems

Reference

\[[Kuhn 06|AA. C References#Kuhn 06]\] UTF-8 and Unicode FAQ for Unix/Linux
\[[ISO/IEC 646-1991|AA. C References#ISO/IEC 646-1991]\] ISO 7-bit coded character set for information interchange
\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 5.2.1, "Character sets"
\[[MISRA 04|AA. C References#MISRA 04]\] Rule 3.2, "The character set and the corresponding encoding shall be documented," and Rule 4.1, "Only those escape sequences that are defined in the ISO C standard shall be used"
\[[Wheeler 03|AA. C References#Wheeler03]\] 5.4 File Names

...

MSC08-A. Library functions should validate their parameters      14. Miscellaneous (MSC)       MSC10-A. Character Encoding - UTF8 Related Issues