deardaniel/secdata-raw huggingface dataset:
CWE-27: Path Traversal: 'dir/../../filename'

Description:
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize multiple internal "../" sequences that can resolve to a location that is outside of that directory.

Extended Description:
This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. 
             The 'directory/../../filename' manipulation is useful for bypassing some path traversal protection schemes. Sometimes a program only removes one "../" sequence, so multiple "../" can bypass that check. Alternately, this manipulation could be used to bypass a check for "../" at the beginning of the pathname, moving up more than one directory level.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-23

Consequences:
  - Confidentiality: Read Files or Directories

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2002-0298: Server allows remote attackers to cause a denial of service via certain HTTP GET requests containing a %2e%2e (encoded dot-dot), several "/../" sequences, or several "../" in a URI.
CWE-270: Privilege Context Switching Error

Description:
The product does not properly manage privileges while it is switching between different contexts that have different privileges or spheres of control.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-269

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  - [Architecture and Design] Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the s
  - [Architecture and Design] Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

Real-world examples:
  - CVE-2002-1688: Web browser cross domain problem when user hits "back" button.
  - CVE-2003-1026: Web browser cross domain problem when user hits "back" button.
  - CVE-2002-1770: Cross-domain issue - third party product passes code to web browser, which executes it in unsafe zone.
  - CVE-2005-2263: Run callback in different security context after it has been changed from untrusted to trusted. * note that "context switch before actions are completed" is one type of problem that happens frequently
CWE-271: Privilege Dropping / Lowering Errors

Description:
The product does not drop privileges before passing control of a resource to an actor that does not have those privileges.

Extended Description:
In some contexts, a system executing with elevated permissions will hand off a process/file/etc. to another process or user. If the privileges of an entity are not reduced, then elevated privileges are spread throughout a system and possibly to an attacker.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-269

Consequences:
  - Access Control: Gain Privileges or Assume Identity
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. 
                   Ensure that appropriate compartm
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  - [Architecture and Design] Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

Demonstrative examples:
The following code calls chroot() to restrict the application to a subset of the filesystem below APP_HOME in order to prevent an attacker from using the program to gain unauthorized access to files located elsewhere. The code then opens a file specified by the user and processes the contents of the file.
Constraining the process inside the application's home directory before opening any files is a valuable security measure. However, the absence of a call to setuid() with some non-zero value means the application is continuing to operate with unnecessary root privileges. Any successful exploit carried out by an attacker against the application can now result in a privilege escalation attack because any malicious operations will be performed with the privileges of the superuser. If the appl

Real-world examples:
  - CVE-2000-1213: Program does not drop privileges after acquiring the raw socket.
  - CVE-2001-0559: Setuid program does not drop privileges after a parsing error occurs, then calls another program to handle the error.
  - CVE-2001-0787: Does not drop privileges in related groups when lowering privileges.
  - CVE-2002-0080: Does not drop privileges in related groups when lowering privileges.
  - CVE-2001-1029: Does not drop privileges before determining access to certain files.
CWE-272: Least Privilege Violation

Description:
The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-271

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Detection methods:
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Dynamic Analysis with Automated Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Manual Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           
  - Automated Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             

Mitigations:
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  - [Architecture and Design] Follow the principle of least privilege when assigning access rights to entities in a software system.
  - [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. 
                   Ensure that appropriate compartm

Demonstrative examples:
The following example demonstrates the weakness.

setuid(0); 
                      // Do some important stuff 
                      setuid(old_uid); 
                      // Do some non privileged stuff.

The following example demonstrates the weakness.

AccessController.doPrivileged(new PrivilegedAction() { 
                         public Object run() { 
                                  // privileged code goes here, for example: 
                                  System.loadLibrary("awt"); return null; 
                                  // nothing to return 
                                  
                            }
CWE-273: Improper Check for Dropped Privileges

Description:
The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.

Extended Description:
If the drop fails, the product will continue to run with the raised privileges, which might provide additional access to unprivileged users.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-754, CWE-754, CWE-271

Consequences:
  - Access Control: Gain Privileges or Assume Identity
  - Access Control: Gain Privileges or Assume Identity

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. 
                   Ensure that appropriate compartm
  - [Implementation] Check the results of all functions that return a value and verify that the value is expected.
  - [Implementation] In Windows, make sure that the process token has the SeImpersonatePrivilege(Microsoft Server 2003). Code that relies on impersonation for security must ensure that the impersonation succeeded, i.e., that a proper privilege demotion happened.

Demonstrative examples:
This code attempts to take on the privileges of a user before creating a file, thus avoiding performing the action with unnecessarily high privileges:
The call to ImpersonateNamedPipeClient may fail, but the return value is not checked. If the call fails, the code may execute with higher privileges than intended. In this case, an attacker could exploit this behavior to write a file to a location that the attacker does not have access to.
bool DoSecureStuff(HANDLE hPipe) { bool fDataWritten = false; ImpersonateNamedPipeClient(hPipe); HANDLE hFile = CreateFile(...); /../ RevertToSelf() /../ }

Real-world examples:
  - CVE-2006-4447: Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
  - CVE-2006-2916: Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
CWE-274: Improper Handling of Insufficient Privileges

Description:
The product does not handle or incorrectly handles when it has insufficient privileges to perform an operation, leading to resultant weaknesses.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-755, CWE-269

Consequences:
  - Other: Other

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Real-world examples:
  - CVE-2001-1564: System limits are not properly enforced after privileges are dropped.
  - CVE-2005-3286: Firewall crashes when it can't read a critical memory block that was protected by a malicious process.
  - CVE-2005-1641: Does not give admin sufficient privileges to overcome otherwise legitimate user actions.
CWE-276: Incorrect Default Permissions

Description:
During installation, installed file permissions are set to allow anyone to modify those files.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, ICS/OT
Parent weaknesses: CWE-732, CWE-732

Consequences:
  - Confidentiality: Read Application Data

Detection methods:
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
          
            Cost effective for partial coverage: 
             
               Inter-application Flow Analys
  - Manual Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
          
            Cost effective for partial coverage: 
             
               Binary / Bytecode disassemble
  - Dynamic Analysis with Automated Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
          
            Cost effective for partial coverage: 
             
               Host-based Vulnerability Scan
  - Dynamic Analysis with Manual Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
          
            Highly cost effective: 
             
               Host Application Interface Scanner 
       

Mitigations:
  - [Architecture and Design] The architecture needs to access and modification attributes for files to only those users who actually require those actions.
  - [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. 
           Ensure that appropriate compartmentaliza

Real-world examples:
  - CVE-2005-1941: Executables installed world-writable.
  - CVE-2002-1713: Home directories installed world-readable.
  - CVE-2001-1550: World-writable log files allow information loss; world-readable file has cleartext passwords.
  - CVE-2002-1711: World-readable directory.
  - CVE-2002-1844: Windows product uses insecure permissions when installing on Solaris (genesis: port error).
CWE-277: Insecure Inherited Permissions

Description:
A product defines a set of insecure permissions that are inherited by objects that are created by the program.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-732

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  - [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. 
                   Ensure that appropriate compartm

Real-world examples:
  - CVE-2005-1841: User's umask is used when creating temp files.
  - CVE-2002-1786: Insecure umask for core dumps [is the umask preserved or assigned?].
CWE-278: Insecure Preserved Inherited Permissions

Description:
A product inherits a set of insecure permissions for an object, e.g. when copying from an archive file, without user awareness or involvement.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-732

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  - [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. 
                   Ensure that appropriate compartm

Real-world examples:
  - CVE-2005-1724: Does not obey specified permissions when exporting.
CWE-279: Incorrect Execution-Assigned Permissions

Description:
While it is executing, the product sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-732

Consequences:
  - Confidentiality: Read Application Data

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  - [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. 
                   Ensure that appropriate compartm

Real-world examples:
  - CVE-2002-0265: Log files opened read/write.
  - CVE-2003-0876: Log files opened read/write.
  - CVE-2002-1694: Log files opened read/write.
CWE-28: Path Traversal: '..\filedir'

Description:
The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize "..\" sequences that can resolve to a location that is outside of that directory.

Extended Description:
This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. 
             The '..\' manipulation is the canonical manipulation for operating systems that use "\" as directory separators, such as Windows. However, it is also useful for bypassing path traversal protection schemes that only assume that the "/" separator is valid.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-23

Consequences:
  - Confidentiality: Read Files or Directories

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe
  - [Implementation] Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous i

Real-world examples:
  - CVE-2002-0661: "\" not in denylist for web server, allowing path traversal attacks when the server is run in Windows and other OSes.
  - CVE-2002-0946: Arbitrary files may be read files via ..\ (dot dot) sequences in an HTTP request.
  - CVE-2002-1042: Directory traversal vulnerability in search engine for web server allows remote attackers to read arbitrary files via "..\" sequences in queries.
  - CVE-2002-1209: Directory traversal vulnerability in FTP server allows remote attackers to read arbitrary files via "..\" sequences in a GET request.
  - CVE-2002-1178: Directory traversal vulnerability in servlet allows remote attackers to execute arbitrary commands via "..\" sequences in an HTTP request.
CWE-280: Improper Handling of Insufficient Permissions or Privileges

Description:
The product does not handle or incorrectly handles when it has insufficient privileges to access resources or functionality as specified by their permissions. This may cause it to follow unexpected code paths that may leave the product in an invalid state.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-755

Consequences:
  - Other: Other

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. 
                   Ensure that appropriate compartm
  - [Implementation] Always check to see if you have successfully accessed a resource or system functionality, and use proper error handling if it is unsuccessful. Do this even when you are operating in a highly privileged mode, because errors or environmental conditions might still cause a failure. For example, environ

Real-world examples:
  - CVE-2003-0501: Special file system allows attackers to prevent ownership/permission change of certain entries by opening the entries before calling a setuid program.
  - CVE-2004-0148: FTP server places a user in the root directory when the user's permissions prevent access to the their own home directory.
CWE-281: Improper Preservation of Permissions

Description:
The product does not preserve permissions or incorrectly preserves permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-732, CWE-732

Consequences:
  - Confidentiality: Read Application Data

Real-world examples:
  - CVE-2002-2323: Incorrect ACLs used when restoring backups from directories that use symbolic links.
  - CVE-2001-1515: Automatic modification of permissions inherited from another file system.
  - CVE-2005-1920: Permissions on backup file are created with defaults, possibly less secure than original file.
  - CVE-2001-0195: File is made world-readable when being cloned.
CWE-282: Improper Ownership Management

Description:
The product assigns the wrong ownership, or does not properly verify the ownership, of an object or resource.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-284

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Demonstrative examples:
This function is part of a privileged program that takes input from users with potentially lower privileges.
This code does not confirm that the process to be killed is owned by the requesting user, thus allowing an attacker to kill arbitrary processes.
def killProcess(processID): os.kill(processID, signal.SIGKILL)
def killProcess(processID): 
                         user = getCurrentUser() 
                            
                            #Check process owner against requesting user 
                            if getProcessOwner(processID) == user: os.kill(processID, signal.SIGKILL) return 
                            else: print("You cannot kill a process you don't own") return

Real-world examples:
  - CVE-1999-1125: Program runs setuid root but relies on a configuration file owned by a non-root user.