Baseline for Ed 2 of tr 24772

7.27 Resource Names [HTS]

7.27.1 Description of application vulnerability

Interfacing with the directory structure or other external identifiers on a system on which software executes is very common. Differences in the conventions used by operating systems can result in significant changes in behaviour when the same program is executed under different operating systems. For instance, the directory structure, permissible characters, case sensitivity, and so forth can vary among operating systems and even among variations of the same operating system. For example, Microsoft prohibits “/?:&\*”<>|#%”; but UNIX, Linux, and OS X operating systems allow any character except for the reserved character ‘/’ to be used in a filename.

Some operating systems are case sensitive while others are not. On non-case sensitive operating systems, depending on the software being used, the same filename could be displayed, as “filename”, “Filename” or “FILENAME” and all would refer to the same file.

Some operating systems, particularly older ones, only rely on the significance of the first n characters of the file name. n can be unexpectedly small, such as the first 8 characters in the case of Win16 architectures which would cause “filename1”, “filename2” and “filename3” to all map to the same file.

Variations in the filename, named resource or external identifier being referenced can be the basis for various kinds of problems. Such mistakes or ambiguity can be unintentional, or intentional, and in either case they can be potentially exploited, if surreptitious behaviour is a goal.

7.27.2 Cross reference

JSF AV Rules: 46, 51, 53, 54, 55, and 56

MISRA C 2012: 1.1

CERT C guidelines: MSC09-C and MSC10-C

7.27.3 Mechanism of Failure

The wrong named resource, such as a file, may be used within a program in a form that provides access to a resource that was not intended to be accessed. Attackers could exploit this situation to intentionally misdirect access of a named resource to another named resource.

7.27.4 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Where possible, use an API that provides a known common set of conventions for naming and accessing external resources, such as POSIX, ISO/IEC 9945:2003 (IEEE Std 1003.1-2001).
  
• 
  Analyze the range of intended target systems, develop a suitable API for dealing with them, and document the analysis.
  
• 
  Ensure that programs adapt their behaviour to the platform on which they are executing, so that only the intended resources are accessed. The means that information on such characteristics as the directory separator string and methods of accessing parent directories need to be parameterized and not exist as fixed strings within a program.
  
• 
  Avoid creating resource names that are longer than the guaranteed unique length of all potential target platforms.
  
• 
  Avoid creating resources, which are differentiated only by the case in their names.
  

Avoid all Unicode characters and all control characters5F¹⁰ in filenames and the extensions.

7.28 Injection [RST]

7.28.1 Description of application vulnerability

Injection problems span a wide range of instantiations. The basic form of this weakness involves the software allowing injection of additional data in input data to alter the control flow of the process. Command injection problems are a subset of injection problems, in which the process can be tricked into calling external processes of an attacker’s choice through the injection of command syntax into the input data. Multiple leading/internal/trailing special elements injected into an application through input can be used to compromise a system. As data is parsed, improperly handled multiple leading special elements may cause the process to take unexpected actions that result in an attack. Software may allow the injection of special elements that are non-typical but equivalent to typical special elements with control implications. This frequently occurs when the product has protected itself against special element injection. Software may allow inputs to be fed directly into an output file that is later processed as code, such as a library file or template. Line or section delimiters injected into an application can be used to compromise a system.

Many injection attacks involve the disclosure of important information — in terms of both data sensitivity and usefulness in further exploitation. In some cases injectable code controls authentication; this may lead to a remote vulnerability. Injection attacks are characterized by the ability to significantly change the flow of a given process, and in some cases, to the execution of arbitrary code. Data injection attacks lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Often the actions performed by injected control code are not logged.

SQL injection attacks are a common instantiation of injection attack, in which SQL commands are injected into input to effect the execution of predefined SQL commands. Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL injection vulnerabilities. If poorly implemented SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password. If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of the SQL injection vulnerability. Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL injection attack.

Injection problems encompass a wide variety of issues — all mitigated in very different ways. The most important issue to note is that all injection problems share one thing in common — they allow for the injection of control data into the user controlled data. This means that the execution of the process may be altered by sending code in through legitimate data channels, using no other mechanism. While buffer overflows and many other flaws involve the use of some further issue to gain execution, injection problems need only for the data to be parsed. Many injection attacks involve the disclosure of important information in terms of both data sensitivity and usefulness in further exploitation. In some cases injectable code controls authentication, this may lead to a remote vulnerability.

7.28.2 Cross reference

CWE:

74. Failure to Sanitize Data into a Different Plane ('Injection')

76. Failure to Resolve Equivalent Special Elements into a Different Plane

78. Failure to Sanitize Data into an OS Command (aka ‘OS Command Injection’)

89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

90. Failure to Sanitize Data into LDAP Queries (aka ‘LDAP Injection’)

91. XML Injection (aka Blind XPath Injection)
92. Custom Special Character Injection
95. Insufficient Control of Directives in Dynamically Code Evaluated Code (aka 'Eval Injection')

97. Failure to Sanitize Server-Side Includes (SSI) Within a Web Page

98. Insufficient Control of Filename for Include/Require Statement in PHP Program (aka ‘PHP File Inclusion’)
99. Insufficient Control of Resource Identifiers (aka ‘Resource Injection’)

144. Failure to Sanitize Line Delimiters

145. Failure to Sanitize Section Delimiters

161. Failure to Sanitize Multiple Leading Special Elements

163. Failure to Sanitize Multiple Trailing Special Elements
165. Failure to Sanitize Multiple Internal Special Elements
166. Failure to Handle Missing Special Element
167. Failure to Handle Additional Special Element
168. Failure to Resolve Inconsistent Special Elements

564. SQL Injection: Hibernate

CERT C guidelines: FIO30-C

7.28.3 Mechanism of failure

A software system that accepts and executes input in the form of operating system commands (such as system(), exec(), open()) could allow an attacker with lesser privileges than the target software to execute commands with the elevated privileges of the executing process. Command injection is a common problem with wrapper programs. Often, parts of the command to be run are controllable by the end user. If a malicious user injects a character (such as a semi-colon) that delimits the end of one command and the beginning of another, he may then be able to insert an entirely new and unrelated command to do whatever he pleases.

Dynamically generating operating system commands that include user input as parameters can lead to command injection attacks. An attacker can insert operating system commands or modifiers in the user input that can cause the request to behave in an unsafe manner. Such vulnerabilities can be very dangerous and lead to data and system compromise. If no validation of the parameter to the exec command exists, an attacker can execute any command on the system the application has the privilege to access.

There are two forms of command injection vulnerabilities. An attacker can change the command that the program executes (the attacker explicitly controls what the command is). Alternatively, an attacker can change the environment in which the command executes (the attacker implicitly controls what the command means). The first scenario where an attacker explicitly controls the command that is executed can occur when:

• 
  Data enters the application from an untrusted source.
  
• 
  The data is part of a string that is executed as a command by the application.
  
• 
  By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have. 
  

Eval injection occurs when the software allows inputs to be fed directly into a function (such as "eval") that dynamically evaluates and executes the input as code, usually in the same interpreted language that the product uses. Eval injection is prevalent in handler/dispatch procedures that might want to invoke a large number of functions, or set a large number of variables.

A PHP file inclusion occurs when a PHP product uses require or include statements, or equivalent statements, that use attacker-controlled data to identify code or HTML (HyperText Markup Language) to be directly processed by the PHP interpreter before inclusion in the script.

A resource injection issue occurs when the following two conditions are met:

• 
  An attacker can specify the identifier used to access a system resource. For example, an attacker might be able to specify part of the name of a file to be opened or a port number to be used.
  
• 
  By specifying the resource, the attacker gains a capability that would not otherwise be permitted.  For example, the program may give the attacker the ability to overwrite the specified file, run with a configuration controlled by the attacker, or transmit sensitive information to a third-party server. Note: Resource injection that involves resources stored on the file system goes by the name path manipulation and is reported in separate category. See the Error: Reference source not found description for further details of this vulnerability. Allowing user input to control resource identifiers may enable an attacker to access or modify otherwise protected system resources.
  

Line or section delimiters injected into an application can be used to compromise a system. As data is parsed, an injected/absent/malformed delimiter may cause the process to take unexpected actions that result in an attack. One example of a section delimiter is the boundary string in a multipart MIME (Multipurpose Internet Mail Extensions) message. In many cases, doubled line delimiters can serve as a section delimiter.

7.28.4 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Assume all input is malicious. Use an appropriate combination of black-lists and white-lists to ensure only valid, expected and appropriate input is processed by the system.
  
• 
  Narrowly define the set of safe characters based on the expected values of the parameter in the request.
  
• 
  Anticipate that delimiters and special elements would be injected/removed/manipulated in the input vectors of their software system and program appropriate mechanisms to handle them.
  
• 
  Implement SQL strings using prepared statements that bind variables.
  
• 
  Use vigorous white-list style checking on any user input that may be used in a SQL command. Rather than escape meta-characters, it is safest to disallow them entirely since the later use of data that have been entered in the database may neglect to escape meta-characters before use.
  
• 
  Follow the principle of least privilege when creating user accounts to a SQL database. Users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data.
  
• 
  Assign permissions to the software system that prevents the user from accessing/opening privileged files.
  
• 
  Restructure code so that there is not a need to use the eval() utility.