Home > CWE List > VIEW SLICE: CWE-1178: Weaknesses Addressed by the SEI CERT Perl Coding Standard (4.16) |
|
CWE VIEW: Weaknesses Addressed by the SEI CERT Perl Coding Standard
CWE entries in this view (graph) are fully or partially eliminated by following the guidance presented in the online wiki that reflects that current rules and recommendations of the SEI CERT Perl Coding Standard.
The following graph shows the tree-like relationships between
weaknesses that exist at different levels of abstraction. At the highest level, categories
and pillars exist to group weaknesses. Categories (which are not technically weaknesses) are
special CWE entries used to group weaknesses that share a common characteristic. Pillars are
weaknesses that are described in the most abstract fashion. Below these top-level entries
are weaknesses are varying levels of abstraction. Classes are still very abstract, typically
independent of any specific language or technology. Base level weaknesses are used to
present a more specific type of weakness. A variant is a weakness that is described at a
very low level of detail, typically limited to a specific language or technology. A chain is
a set of weaknesses that must be reachable consecutively in order to produce an exploitable
vulnerability. While a composite is a set of weaknesses that must all be present
simultaneously in order to produce an exploitable vulnerability.
Show Details:
1178 - Weaknesses Addressed by the SEI CERT Perl Coding Standard
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1179
(SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS))
Weaknesses in this category are related to the rules and recommendations in the Input Validation and Data Sanitization (IDS) section of the SEI CERT Perl Coding Standard.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1179
(SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)) >
22
(Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'))
The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.
Directory traversal
Path traversal
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1179
(SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)) >
134
(Use of Externally-Controlled Format String)
The product uses a function that accepts a format string as an argument, but the format string originates from an external source.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1179
(SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)) >
129
(Improper Validation of Array Index)
The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.
out-of-bounds array index
index-out-of-range
array index underflow
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1179
(SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)) >
789
(Memory Allocation with Excessive Size Value)
The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.
Stack Exhaustion
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1179
(SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)) >
116
(Improper Encoding or Escaping of Output)
The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.
Output Sanitization
Output Validation
Output Encoding
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1179
(SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)) >
77
(Improper Neutralization of Special Elements used in a Command ('Command Injection'))
The product constructs all or part of a command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended command when it is sent to a downstream component.
Command injection
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1179
(SEI CERT Perl Coding Standard - Guidelines 01. Input Validation and Data Sanitization (IDS)) >
95
(Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'))
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1180
(SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL))
Weaknesses in this category are related to the rules and recommendations in the Declarations and Initialization (DCL) section of the SEI CERT Perl Coding Standard.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1180
(SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL)) >
628
(Function Call with Incorrectly Specified Arguments)
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1180
(SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL)) >
456
(Missing Initialization of a Variable)
The product does not initialize critical variables, which causes the execution environment to use unexpected values.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1180
(SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL)) >
457
(Use of Uninitialized Variable)
The code uses a variable that has not been initialized, leading to unpredictable or unintended results.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1180
(SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL)) >
477
(Use of Obsolete Function)
The code uses deprecated or obsolete functions, which suggests that the code has not been actively reviewed or maintained.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP))
Weaknesses in this category are related to the rules and recommendations in the Expressions (EXP) section of the SEI CERT Perl Coding Standard.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
394
(Unexpected Status Code or Return Value)
The product does not properly check when a function or operation returns a value that is legitimate for the function, but is not expected by the product.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
783
(Operator Precedence Logic Error)
The product uses an expression in which operator precedence causes incorrect logic to be used.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
477
(Use of Obsolete Function)
The code uses deprecated or obsolete functions, which suggests that the code has not been actively reviewed or maintained.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
248
(Uncaught Exception)
An exception is thrown from a function, but it is not caught.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
391
(Unchecked Error Condition)
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
460
(Improper Cleanup on Thrown Exception)
The product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
705
(Incorrect Control Flow Scoping)
The product does not properly return control flow to the proper location after it has completed a task or detected an unusual condition.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
754
(Improper Check for Unusual or Exceptional Conditions)
The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
252
(Unchecked Return Value)
The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
690
(Unchecked Return Value to NULL Pointer Dereference)
The product does not check for an error after calling a function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
628
(Function Call with Incorrectly Specified Arguments)
The product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
375
(Returning a Mutable Object to an Untrusted Caller)
Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1181
(SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)) >
597
(Use of Wrong Operator in String Comparison)
The product uses the wrong operator when comparing a string, such as using "==" when the .equals() method should be used instead.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1182
(SEI CERT Perl Coding Standard - Guidelines 04. Integers (INT))
Weaknesses in this category are related to the rules and recommendations in the Integers (INT) section of the SEI CERT Perl Coding Standard.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1182
(SEI CERT Perl Coding Standard - Guidelines 04. Integers (INT)) >
189
(Numeric Errors)
Weaknesses in this category are related to improper calculation or conversion of numbers.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1183
(SEI CERT Perl Coding Standard - Guidelines 05. Strings (STR))
Weaknesses in this category are related to the rules and recommendations in the Strings (STR) section of the SEI CERT Perl Coding Standard.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1184
(SEI CERT Perl Coding Standard - Guidelines 06. Object-Oriented Programming (OOP))
Weaknesses in this category are related to the rules and recommendations in the Object-Oriented Programming (OOP) section of the SEI CERT Perl Coding Standard.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1184
(SEI CERT Perl Coding Standard - Guidelines 06. Object-Oriented Programming (OOP)) >
767
(Access to Critical Private Variable via Public Method)
The product defines a public method that reads or modifies a private variable.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1185
(SEI CERT Perl Coding Standard - Guidelines 07. File Input and Output (FIO))
Weaknesses in this category are related to the rules and recommendations in the File Input and Output (FIO) section of the SEI CERT Perl Coding Standard.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1185
(SEI CERT Perl Coding Standard - Guidelines 07. File Input and Output (FIO)) >
59
(Improper Link Resolution Before File Access ('Link Following'))
The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.
insecure temporary file
Zip Slip
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1186
(SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC))
Weaknesses in this category are related to the rules and recommendations in the Miscellaneous (MSC) section of the SEI CERT Perl Coding Standard.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1186
(SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC)) >
561
(Dead Code)
The product contains dead code, which can never be executed.
![]() ![]()
1178
(Weaknesses Addressed by the SEI CERT Perl Coding Standard) >
1186
(SEI CERT Perl Coding Standard - Guidelines 50. Miscellaneous (MSC)) >
563
(Assignment to Variable without Use)
The variable's value is assigned but never used, making it a dead store.
Unused Variable
Relationship
The relationships in this view were determined based on specific statements within the rules from the standard. Not all rules have direct relationships to individual weaknesses, although they likely have chaining relationships in specific circumstances.
View ComponentsA | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z
CWE-767: Access to Critical Private Variable via Public Method
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
If an attacker modifies the variable to contain unexpected values, this could violate assumptions from other parts of the code. Additionally, if an attacker can read the private variable, it may expose sensitive information or make it easier to launch further attacks.
![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages C++ (Undetermined Prevalence) C# (Undetermined Prevalence) Java (Undetermined Prevalence) Example 1 The following example declares a critical variable to be private, and then allows the variable to be modified by public methods. (bad code)
Example Language: C++
private: float price;
public: void changePrice(float newPrice) { price = newPrice; }Example 2 The following example could be used to implement a user forum where a single user (UID) can switch between multiple profiles (PID). (bad code)
Example Language: Java
public class Client {
private int UID; }public int PID; private String userName; public Client(String userName){ PID = getDefaultProfileID(); }UID = mapUserNametoUID( userName ); this.userName = userName; public void setPID(int ID) { UID = ID; }The programmer implemented setPID with the intention of modifying the PID variable, but due to a typo. accidentally specified the critical variable UID instead. If the program allows profile IDs to be between 1 and 10, but a UID of 1 means the user is treated as an admin, then a user could gain administrative privileges as a result of this typo. ![]()
Maintenance
This entry is closely associated with access control for public methods. If the public methods are restricted with proper access controls, then the information in the private variable will not be exposed to unexpected parties. There may be chaining or composite relationships between improper access controls and this weakness.
CWE-563: Assignment to Variable without Use
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
After the assignment, the variable is either assigned another value or goes out of scope. It is likely that the variable is simply vestigial, but it is also possible that the unused variable points out a bug.
![]()
![]() ![]()
![]() ![]()
![]()
Example 1 The following code excerpt assigns to the variable r and then overwrites the value without using it. (bad code)
Example Language: C
r = getName();
r = getNewBuffer(buf);
![]()
CWE-561: Dead Code
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom Filter
Dead code is code that can never be executed in a running program. The surrounding code makes it impossible for a section of code to ever be executed.
![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Undetermined Prevalence) Example 1 The condition for the second if statement is impossible to satisfy. It requires that the variables be non-null. However, on the only path where s can be assigned a non-null value, there is a return statement. (bad code)
Example Language: C++
String s = null;
if (b) { s = "Yes"; }return; if (s != null) { Dead(); }Example 2 In the following class, two private methods call each other, but since neither one is ever invoked from anywhere else, they are both dead code. (bad code)
Example Language: Java
public class DoubleDead {
private void doTweedledee() { }doTweedledumb(); }private void doTweedledumb() { doTweedledee(); }public static void main(String[] args) { System.out.println("running DoubleDead"); }(In this case it is a good thing that the methods are dead: invoking either one would cause an infinite loop.) Example 3 The field named glue is not used in the following class. The author of the class has accidentally put quotes around the field name, transforming it into a string constant. (bad code)
Example Language: Java
public class Dead {
String glue;
public String getGlue() { return "glue"; }
![]()
CWE-628: Function Call with Incorrectly Specified Arguments
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product calls a function, procedure, or routine with arguments that are not correctly specified, leading to always-incorrect behavior and resultant weaknesses.
There are multiple ways in which this weakness can be introduced, including:
![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Undetermined Prevalence) Example 1 The following PHP method authenticates a user given a username/password combination but is called with the parameters in reverse order. (bad code)
Example Language: PHP
function authenticate($username, $password) {
// authenticate user ... authenticate($_POST['password'], $_POST['username']); Example 2 This Perl code intends to record whether a user authenticated successfully or not, and to exit if the user fails to authenticate. However, when it calls ReportAuth(), the third argument is specified as 0 instead of 1, so it does not exit. (bad code)
Example Language: Perl
sub ReportAuth {
my ($username, $result, $fatal) = @_; }PrintLog("auth: username=%s, result=%d", $username, $result); if (($result ne "success") && $fatal) { die "Failed!\n"; }sub PrivilegedFunc { my $result = CheckAuth($username); }ReportAuth($username, $result, 0); DoReallyImportantStuff(); Example 3 In the following Java snippet, the accessGranted() method is accidentally called with the static ADMIN_ROLES array rather than the user roles. (bad code)
Example Language: Java
private static final String[] ADMIN_ROLES = ...;
public boolean void accessGranted(String resource, String user) { String[] userRoles = getUserRoles(user); }return accessGranted(resource, ADMIN_ROLES); private boolean void accessGranted(String resource, String[] userRoles) { // grant or deny access based on user roles ...
![]()
CWE-754: Improper Check for Unusual or Exceptional Conditions
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
The programmer may assume that certain events or conditions will never occur or do not need to be worried about, such as low memory conditions, lack of access to resources due to restrictive permissions, or misbehaving clients or components. However, attackers may intentionally trigger these unusual conditions, thus violating the programmer's assumptions, possibly introducing instability, incorrect behavior, or a vulnerability. Note that this entry is not exclusively about the use of exceptions and exception handling, which are mechanisms for both checking and handling unusual or unexpected conditions. ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Undetermined Prevalence) Example 1 Consider the following code segment: (bad code)
Example Language: C
char buf[10], cp_buf[10];
fgets(buf, 10, stdin); strcpy(cp_buf, buf); The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy(). Example 2 The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc(). (bad code)
Example Language: C
buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size); The traditional defense of this coding error is: "If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null pointer." This argument ignores three important considerations:
Example 3 The following examples read a file into a byte array. (bad code)
Example Language: C#
char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) { String userName = (String) i.Current(); }String pFileName = PFILE_ROOT + "/" + userName; StreamReader sr = new StreamReader(pFileName); sr.Read(byteArray,0,1024);//the file is always 1k bytes sr.Close(); processPFile(userName, byteArray); (bad code)
Example Language: Java
FileInputStream fis;
byte[] byteArray = new byte[1024]; for (Iterator i=users.iterator(); i.hasNext();) { String userName = (String) i.next();
String pFileName = PFILE_ROOT + "/" + userName; FileInputStream fis = new FileInputStream(pFileName); fis.read(byteArray); // the file is always 1k bytes fis.close(); processPFile(userName, byteArray); The code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always 1 kilobyte in size and therefore ignores the return value from Read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and treat it as though it belongs to the attacker. Example 4 The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a NULL dereference. (bad code)
Example Language: Java
String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM) == 0) { ... }... The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a NULL dereference. (bad code)
Example Language: Java
String itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) { ... }... The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved. Example 5 The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined. (bad code)
Example Language: Java
System.clearProperty("os.name");
... String os = System.getProperty("os.name"); if (os.equalsIgnoreCase("Windows 95")) System.out.println("Not supported"); The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved. Example 6 The following VB.NET code does not check to make sure that it has read 50 bytes from myfile.txt. This can cause DoDangerousOperation() to operate on an unexpected value. (bad code)
Example Language: C#
Dim MyFile As New FileStream("myfile.txt", FileMode.Open, FileAccess.Read, FileShare.Read)
Dim MyArray(50) As Byte MyFile.Read(MyArray, 0, 50) DoDangerousOperation(MyArray(20)) In .NET, it is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. The stream and reader classes do not consider it to be unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested. Example 7 This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer. (bad code)
Example Language: C
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr; char hostname[64]; in_addr_t inet_addr(const char *cp); /*routine that ensures user_supplied_addr is in the right format for conversion */ validate_addr_form(user_supplied_addr); addr = inet_addr(user_supplied_addr); hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET); strcpy(hostname, hp->h_name); If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. Since the code does not check the return value from gethostbyaddr (CWE-252), a NULL pointer dereference (CWE-476) would then occur in the call to strcpy(). Note that this code is also vulnerable to a buffer overflow (CWE-119). Example 8 In the following C/C++ example the method outputStringToFile opens a file in the local filesystem and outputs a string to the file. The input parameters output and filename contain the string to output to the file and the name of the file respectively. (bad code)
Example Language: C++
int outputStringToFile(char *output, char *filename) {
openFileToWrite(filename); writeToFile(output); closeFile(filename); However, this code does not check the return values of the methods openFileToWrite, writeToFile, closeFile to verify that the file was properly opened and closed and that the string was successfully written to the file. The return values for these methods should be checked to determine if the method was successful and allow for detection of errors or unexpected conditions as in the following example. (good code)
Example Language: C++
int outputStringToFile(char *output, char *filename) {
int isOutput = SUCCESS;
int isOpen = openFileToWrite(filename); if (isOpen == FAIL) { printf("Unable to open file %s", filename); }isOutput = FAIL; else { int isWrite = writeToFile(output);
if (isWrite == FAIL) { printf("Unable to write to file %s", filename); }isOutput = FAIL; int isClose = closeFile(filename); if (isClose == FAIL) isOutput = FAIL;
return isOutput; Example 9 In the following Java example the method readFromFile uses a FileReader object to read the contents of a file. The FileReader object is created using the File object readFile, the readFile object is initialized using the setInputFile method. The setInputFile method should be called before calling the readFromFile method. (bad code)
Example Language: Java
private File readFile = null;
public void setInputFile(String inputFile) { // create readFile File object from string containing name of file public void readFromFile() { try {
reader = new FileReader(readFile);
// read input file However, the readFromFile method does not check to see if the readFile object is null, i.e. has not been initialized, before creating the FileReader object and reading from the input file. The readFromFile method should verify whether the readFile object is null and output an error message and raise an exception if the readFile object is null, as in the following code. (good code)
Example Language: Java
private File readFile = null;
public void setInputFile(String inputFile) { // create readFile File object from string containing name of file public void readFromFile() { try {
if (readFile == null) {
System.err.println("Input file has not been set, call setInputFile method before calling openInputFile"); }throw NullPointerException; reader = new FileReader(readFile); // read input file catch (NullPointerException ex) {...}
![]()
Relationship
Sometimes, when a return value can be used to indicate an error, an unchecked return value is a code-layer instance of a missing application-layer check for exceptional conditions. However, return values are not always needed to communicate exceptional conditions. For example, expiration of resources, values passed by reference, asynchronously modified data, sockets, etc. may indicate exceptional conditions without the use of a return value.
CWE-460: Improper Cleanup on Thrown Exception
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product does not clean up its state or incorrectly cleans up its state when an exception is thrown, leading to unexpected state or control flow.
Often, when functions or loops become complicated, some level of resource cleanup is needed throughout execution. Exceptions can disturb the flow of the code and prevent the necessary cleanup from happening.
![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages C (Undetermined Prevalence) C++ (Undetermined Prevalence) Java (Undetermined Prevalence) C# (Undetermined Prevalence) Example 1 The following example demonstrates the weakness. (bad code)
Example Language: Java
public class foo {
public static final void main( String args[] ) {
boolean returnValue; returnValue=doStuff(); public static final boolean doStuff( ) { boolean threadLock; boolean truthvalue=true; try { while( //check some condition ) { threadLock=true; //do some stuff to truthvalue threadLock=false; catch (Exception e){ System.err.println("You did something bad"); if (something) return truthvalue; return truthvalue; In this case, a thread might be left locked accidentally.
![]()
CWE-116: Improper Encoding or Escaping of Output
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterThe product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.
Improper encoding or escaping can allow attackers to change the commands that are sent to another component, inserting malicious commands instead. Most products follow a certain protocol that uses structured messages for communication between components, such as queries or commands. These structured messages can contain raw data interspersed with metadata or control information. For example, "GET /index.html HTTP/1.1" is a structured message containing a command ("GET") with a single argument ("/index.html") and metadata about which protocol version is being used ("HTTP/1.1"). If an application uses attacker-supplied inputs to construct a structured message without properly encoding or escaping, then the attacker could insert special characters that will cause the data to be interpreted as control information or metadata. Consequently, the component that receives the output will perform the wrong operations, or otherwise interpret the data incorrectly. ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Often Prevalent) Technologies AI/ML (Undetermined Prevalence) Database Server (Often Prevalent) Web Server (Often Prevalent) Example 1 This code displays an email address that was submitted as part of a form. (bad code)
Example Language: JSP
<% String email = request.getParameter("email"); %>
... Email Address: <%= email %> The value read from the form parameter is reflected back to the client browser without having been encoded prior to output, allowing various XSS attacks (CWE-79). Example 2 Consider a chat application in which a front-end web application communicates with a back-end server. The back-end is legacy code that does not perform authentication or authorization, so the front-end must implement it. The chat protocol supports two commands, SAY and BAN, although only administrators can use the BAN command. Each argument must be separated by a single space. The raw inputs are URL-encoded. The messaging protocol allows multiple commands to be specified on the same line if they are separated by a "|" character. First let's look at the back end command processor code (bad code)
Example Language: Perl
$inputString = readLineFromFileHandle($serverFH);
# generate an array of strings separated by the "|" character. @commands = split(/\|/, $inputString); foreach $cmd (@commands) { # separate the operator from its arguments based on a single whitespace ($operator, $args) = split(/ /, $cmd, 2); $args = UrlDecode($args); if ($operator eq "BAN") { ExecuteBan($args); }elsif ($operator eq "SAY") { ExecuteSay($args); }The front end web application receives a command, encodes it for sending to the server, performs the authorization check, and sends the command to the server. (bad code)
Example Language: Perl
$inputString = GetUntrustedArgument("command");
($cmd, $argstr) = split(/\s+/, $inputString, 2); # removes extra whitespace and also changes CRLF's to spaces $argstr =~ s/\s+/ /gs; $argstr = UrlEncode($argstr); if (($cmd eq "BAN") && (! IsAdministrator($username))) { die "Error: you are not the admin.\n"; }# communicate with file server using a file handle $fh = GetServerFileHandle("myserver"); print $fh "$cmd $argstr\n"; It is clear that, while the protocol and back-end allow multiple commands to be sent in a single request, the front end only intends to send a single command. However, the UrlEncode function could leave the "|" character intact. If an attacker provides: (attack code)
SAY hello world|BAN user12
then the front end will see this is a "SAY" command, and the $argstr will look like "hello world | BAN user12". Since the command is "SAY", the check for the "BAN" command will fail, and the front end will send the URL-encoded command to the back end: (result)
SAY hello%20world|BAN%20user12
The back end, however, will treat these as two separate commands: (result)
SAY hello world
BAN user12 Notice, however, that if the front end properly encodes the "|" with "%7C", then the back end will only process a single command. Example 3 This example takes user input, passes it through an encoding scheme and then creates a directory specified by the user. (bad code)
Example Language: Perl
sub GetUntrustedInput {
return($ARGV[0]); }sub encode { my($str) = @_; }$str =~ s/\&/\&/gs; $str =~ s/\"/\"/gs; $str =~ s/\'/\'/gs; $str =~ s/\</\</gs; $str =~ s/\>/\>/gs; return($str); sub doit { my $uname = encode(GetUntrustedInput("username")); }print "<b>Welcome, $uname!</b><p>\n"; system("cd /home/$uname; /bin/ls -l"); The programmer attempts to encode dangerous characters, however the denylist for encoding is incomplete (CWE-184) and an attacker can still pass a semicolon, resulting in a chain with command injection (CWE-77). Additionally, the encoding routine is used inappropriately with command execution. An attacker doesn't even need to insert their own semicolon. The attacker can instead leverage the encoding routine to provide the semicolon to separate the commands. If an attacker supplies a string of the form: (attack code)
' pwd
then the program will encode the apostrophe and insert the semicolon, which functions as a command separator when passed to the system function. This allows the attacker to complete the command injection.
![]()
Relationship
This weakness is primary to all weaknesses related to injection (CWE-74) since the inherent nature of injection involves the violation of structured messages.
Relationship CWE-116 and CWE-20 have a close association because, depending on the nature of the structured message, proper input validation can indirectly prevent special characters from changing the meaning of a structured message. For example, by validating that a numeric ID field should only contain the 0-9 characters, the programmer effectively prevents injection attacks. However, input validation is not always sufficient, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a last name is inserted into a query. The name "O'Reilly" would likely pass the validation step since it is a common last name in the English language. However, it cannot be directly inserted into the database because it contains the "'" apostrophe character, which would need to be escaped or otherwise neutralized. In this case, stripping the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded. Terminology
The usage of the "encoding" and "escaping" terms varies widely. For example, in some programming languages, the terms are used interchangeably, while other languages provide APIs that use both terms for different tasks. This overlapping usage extends to the Web, such as the "escape" JavaScript function whose purpose is stated to be encoding. The concepts of encoding and escaping predate the Web by decades. Given such a context, it is difficult for CWE to adopt a consistent vocabulary that will not be misinterpreted by some constituency.
Theoretical
This is a data/directive boundary error in which data boundaries are not sufficiently enforced before it is sent to a different control sphere.
Research Gap
While many published vulnerabilities are related to insufficient output encoding, there is such an emphasis on input validation as a protection mechanism that the underlying causes are rarely described. Within CVE, the focus is primarily on well-understood issues like cross-site scripting and SQL injection. It is likely that this weakness frequently occurs in custom protocols that support multiple encodings, which are not necessarily detectable with automated techniques.
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.
For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.
For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.
For users who wish to see all available information for the CWE/CAPEC entry.
For users who want to customize what details are displayed.
×
Edit Custom FilterMany file operations are intended to take place within a restricted directory. By using special elements such as ".." and "/" separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the "../" sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as "/usr/local/bin" to access unexpected files. This is referred to as absolute path traversal.
![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]() ![]()
![]()
![]() Languages Class: Not Language-Specific (Undetermined Prevalence) Example 1 The following code could be for a social networking application in which each user's profile information is stored in a separate file. All files are stored in a single directory. (bad code)
Example Language: Perl
my $dataPath = "/users/cwe/profiles";
my $username = param("user"); my $profilePath = $dataPath . "/" . $username; open(my $fh, "<", $profilePath) || ExitError("profile read error: $profilePath"); print "<ul>\n"; while (<$fh>) { print "<li>$_</li>\n"; }print "</ul>\n"; While the programmer intends to access files such as "/users/cwe/profiles/alice" or "/users/cwe/profiles/bob", there is no verification of the incoming user parameter. An attacker could provide a string such as: (attack code)
../../../etc/passwd
The program would generate a profile pathname like this: (result)
/users/cwe/profiles/../../../etc/passwd
When the file is opened, the operating system resolves the "../" during path canonicalization and actually accesses this file: (result)
/etc/passwd
As a result, the attacker could read the entire text of the password file. Notice how this code also contains an error message information leak (CWE-209) if the user parameter does not produce a file that exists: the full pathname is provided. Because of the lack of output encoding of the file that is retrieved, there might also be a cross-site scripting problem (CWE-79) if profile contains any HTML, but other code would need to be examined. Example 2 In the example below, the path to a dictionary file is read from a system property and used to initialize a File object. (bad code)
Example Language: Java
String filename = System.getProperty("com.domain.application.dictionaryFile");
File dictionaryFile = new File(filename); However, the path is not validated or modified to prevent it from containing relative or absolute path sequences before creating the File object. This allows anyone who can control the system property to determine what file is used. Ideally, the path should be resolved relative to some kind of application or user home directory. Example 3 The following code takes untrusted input and uses a regular expression to filter "../" from the input. It then appends this result to the /home/user/ directory and attempts to read the file in the final resulting path. (bad code)
Example Language: Perl
my $Username = GetUntrustedInput();
$Username =~ s/\.\.\///; my $filename = "/home/user/" . $Username; ReadAndSendFile($filename); Since the regular expression does not have the /g global match modifier, it only removes the first instance of "../" it comes across. So an input value such as: (attack code)
../../../etc/passwd
will have the first "../" stripped, resulting in: (result)
../../etc/passwd
This value is then concatenated with the /home/user/ directory: (result)
/home/user/../../etc/passwd
which causes the /etc/passwd file to be retrieved once the operating system has resolved the ../ sequences in the pathname. This leads to relative path traversal (CWE-23). Example 4 The following code attempts to validate a given input path by checking it against an allowlist and once validated delete the given file. In this specific case, the path is considered valid if it starts with the string "/safe_dir/". (bad code)
Example Language: Java
String path = getInputPath();
if (path.startsWith("/safe_dir/")) { File f = new File(path); }f.delete() An attacker could provide an input such as this: (attack code)
/safe_dir/../important.dat
The software assumes that the path is valid because it starts with the "/safe_path/" sequence, but the "../" sequence will cause the program to delete the important.dat file in the parent directory Example 5 The following code demonstrates the unrestricted upload of a file with a Java servlet and a path traversal vulnerability. The action attribute of an HTML form is sending the upload file request to the Java servlet. (good code)
Example Language: HTML
<form action="FileUploadServlet" method="post" enctype="multipart/form-data">
Choose a file to upload: <input type="file" name="filename"/> <br/> <input type="submit" name="submit" value="Submit"/> </form> When submitted the Java servlet's doPost method will receive the request, extract the name of the file from the Http request header, read the file contents from the request and output the file to the local upload directory. (bad code)
Example Language: Java
public class FileUploadServlet extends HttpServlet {
...
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html");
PrintWriter out = response.getWriter(); String contentType = request.getContentType(); // the starting position of the boundary header int ind = contentType.indexOf("boundary="); String boundary = contentType.substring(ind+9); String pLine = new String(); String uploadLocation = new String(UPLOAD_DIRECTORY_STRING); //Constant value // verify that content type is multipart form data if (contentType != null && contentType.indexOf("multipart/form-data") != -1) { // extract the filename from the Http header
BufferedReader br = new BufferedReader(new InputStreamReader(request.getInputStream())); ... pLine = br.readLine(); String filename = pLine.substring(pLine.lastIndexOf("\\"), pLine.lastIndexOf("\"")); ... // output the file to the local upload directory try { BufferedWriter bw = new BufferedWriter(new FileWriter(uploadLocation+filename, true));
for (String line; (line=br.readLine())!=null; ) { if (line.indexOf(boundary) == -1) { } //end of for loopbw.write(line); }bw.newLine(); bw.flush(); bw.close(); } catch (IOException ex) {...} // output successful upload response HTML page // output unsuccessful upload response HTML page else {...} ...
This code does not perform a check on the type of the file being uploaded (CWE-434). This could allow an attacker to upload any executable file or other file with malicious code. Additionally, the creation of the BufferedWriter object is subject to relative path traversal (CWE-23). Since the code does not check the filename that is provided in the header, an attacker can use "../" sequences to write to files outside of the intended directory. Depending on the executing environment, the attacker may be able to specify arbitrary files to write to, leading to a wide variety of consequences, from code execution, XSS (CWE-79), or system crash. Example 6 This script intends to read a user-supplied file from the current directory. The user inputs the relative path to the file and the script uses Python's os.path.join() function to combine the path to the current working directory with the provided path to the specified file. This results in an absolute path to the desired file. If the file does not exist when the script attempts to read it, an error is printed to the user. (bad code)
Example Language: Python
import os
import sys def main():
filename = sys.argv[1]
main()
path = os.path.join(os.getcwd(), filename) try:
with open(path, 'r') as f:
except FileNotFoundError as e:
file_data = f.read()
print("Error - file not found")
However, if the user supplies an absolute path, the os.path.join() function will discard the path to the current working directory and use only the absolute path provided. For example, if the current working directory is /home/user/documents, but the user inputs /etc/passwd, os.path.join() will use only /etc/passwd, as it is considered an absolute path. In the above scenario, this would cause the script to access and read the /etc/passwd file. (good code)
Example Language: Python
import os
import sys def main():
filename = sys.argv[1]
main()
path = os.path.normpath(f"{os.getcwd()}{os.sep}{filename}") if path.startswith("/home/cwe/documents/"):
try:
with open(path, 'r') as f:
except FileNotFoundError as e:
file_data = f.read()
print("Error - file not found")
The constructed path string uses os.sep to add the appropriate separation character for the given operating system (e.g. '\' or '/') and the call to os.path.normpath() removes any additional slashes that may have been entered - this may occur particularly when using a Windows path. The path is checked against an expected directory (/home/cwe/documents); otherwise, an attacker could provide relative path sequences like ".." to cause normpath() to generate paths that are outside the intended directory (CWE-23). By putting the pieces of the path string together in this fashion, the script avoids a call to os.path.join() and any potential issues that might arise if an absolute path is entered. With this version of the script, if the current working directory is /home/cwe/documents, and the user inputs /etc/passwd, the resulting path will be /home/cwe/documents/etc/passwd. The user is therefore contained within the current working directory as intended.
![]()
Relationship
Pathname equivalence can be regarded as a type of canonicalization error.
Relationship
Some pathname equivalence issues are not directly related to directory traversal, rather are used to bypass security-relevant checks for whether a file/directory can be accessed by the attacker (e.g. a trailing "/" on a filename could bypass access rules that don't expect a trailing /, causing a server to provide the file when it normally would not).
Terminology Like other weaknesses, terminology is often based on the types of manipulations used, instead of the underlying weaknesses. Some people use "directory traversal" only to refer to the injection of ".." and equivalent sequences whose specific meaning is to traverse directories. Other variants like "absolute pathname" and "drive letter" have the *effect* of directory traversal, but some people may not call it such, since it doesn't involve ".." or equivalent. Research Gap Research Gap Incomplete diagnosis or reporting of vulnerabilities can make it difficult to know which variant is affected. For example, a researcher might say that "..\" is vulnerable, but not test "../" which may also be vulnerable. Any combination of directory separators ("/", "\", etc.) and numbers of "." (e.g. "....") can produce unique variants; for example, the "//../" variant is not listed (CVE-2004-0325). See this entry's children and lower-level descendants. Other
In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to apply to a wider range of files. For example, the product may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.
|