deardaniel/secdata-raw huggingface dataset:
CWE-643: Improper Neutralization of Data within XPath Expressions ('XPath Injection')

Description:
The product uses external input to dynamically construct an XPath expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.

Extended Description:
The net effect is that the attacker will have control over the information selected from the XML database and may use that ability to control application flow, modify logic, retrieve unauthorized data, or bypass important checks (e.g. authentication).

Affected languages: Not Language-Specific
Parent weaknesses: CWE-943, CWE-91

Consequences:
  - Access Control: Bypass Protection Mechanism
  - 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:
  - [Implementation] Use parameterized XPath queries (e.g. using XQuery). This will help ensure separation between data plane and control plane.
  - [Implementation] Properly validate user input. Reject data where appropriate, filter where appropriate and escape where appropriate. Make sure input that will be used in XPath queries is safe in that context.

Demonstrative examples:
Consider the following simple XML document that stores authentication information and a snippet of Java code that uses XPath query to retrieve authentication information:
The Java code used to retrieve the home directory based on the provided credentials is:
<users> <user> <login>john</login> <password>abracadabra</password> <home_dir>/home/john</home_dir> </user> <user> <login>cbc</login> <password>1mgr8</password> <home_dir>/home/cbc</home_dir> </user> </users>
XPath xpath = XPathFactory.newInstance().newXPath(); XPathExpression xlogin = xpath.compile("//users/user[login/text()='" + login.getUserName() + "' and password/text() = '" + login.getPassword() + "']/home_dir/text()"); Document d = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new File("db.xml")); String homedi
CWE-644: Improper Neutralization of HTTP Headers for Scripting Syntax

Description:
The product does not neutralize or incorrectly neutralizes web scripting syntax in HTTP headers that can be used by web browser components that can process raw headers, such as Flash.

Extended Description:
An attacker may be able to conduct cross-site scripting and other attacks against users who have these components enabled. 
             If a product does not neutralize user controlled data being placed in the header of an HTTP response coming from the server, the header may contain a script that will get executed in the client's browser context, potentially resulting in a cross site scripting vulnerability or possibly an HTTP response splitting attack. It is important to carefully control data that is being placed both in HTTP response header and in the HTTP response body to ensure that no scripting syntax is present, taking various encodings into account.

Affected languages: Not Language-Specific
Affected technologies: Web Based, Web Server
Parent weaknesses: CWE-116

Consequences:
  - Integrity: Execute Unauthorized Code or Commands
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] Perform output validation in order to filter/escape/encode unsafe data that is being passed from the server in an HTTP response header.
  - [Architecture and Design] Disable script execution functionality in the clients' browser.

Demonstrative examples:
In the following Java example, user-controlled data is added to the HTTP headers and returned to the client. Given that the data is not subject to neutralization, a malicious user may be able to inject dangerous scripting tags that will lead to script execution in the client browser.

response.addHeader(HEADER_NAME, untrustedRawInputData);

Real-world examples:
  - CVE-2006-3918: Web server does not remove the Expect header from an HTTP request when it is reflected back in an error message, allowing a Flash SWF file to perform XSS attacks.
CWE-645: Overly Restrictive Account Lockout Mechanism

Description:
The product contains an account lockout protection mechanism, but the mechanism is too restrictive and can be triggered too easily, which allows attackers to deny service to legitimate users by causing their accounts to be locked out.

Extended Description:
Account lockout is a security feature often present in applications as a countermeasure to the brute force attack on the password based authentication mechanism of the system. After a certain number of failed login attempts, the users' account may be disabled for a certain period of time or until it is unlocked by an administrator. Other security events may also possibly trigger account lockout. However, an attacker may use this very security feature to deny service to legitimate system users. It is therefore important to ensure that the account lockout security mechanism is not overly restrictive.

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

Consequences:
  - Availability: DoS: Resource Consumption (Other)

Mitigations:
  - [Architecture and Design] Implement more intelligent password throttling mechanisms such as those which take IP address into account, in addition to the login name.
  - [Architecture and Design] Implement a lockout timeout that grows as the number of incorrect login attempts goes up, eventually resulting in a complete lockout.
  - [Architecture and Design] Consider alternatives to account lockout that would still be effective against password brute force attacks, such as presenting the user machine with a puzzle to solve (makes it do some computation).

Demonstrative examples:
A famous example of this type of weakness being exploited is the eBay attack. eBay always displays the user id of the highest bidder. In the final minutes of the auction, one of the bidders could try to log in as the highest bidder three times. After three incorrect log in attempts, eBay password throttling would kick in and lock out the highest bidder's account for some time. An attacker could then make their own bid and their victim would not have a chance to place the counter bid because they would be locked out. Thus an attacker could win the auction.
CWE-646: Reliance on File Name or Extension of Externally-Supplied File

Description:
The product allows a file to be uploaded, but it relies on the file name or extension of the file to determine the appropriate behaviors. This could be used by attackers to cause the file to be misclassified and processed in a dangerous fashion.

Extended Description:
An application might use the file name or extension of a user-supplied file to determine the proper course of action, such as selecting the correct process to which control should be passed, deciding what data should be made available, or what resources should be allocated. If the attacker can cause the code to misclassify the supplied file, then the wrong action could occur. For example, an attacker could supply a file that ends in a ".php.gif" extension that appears to be a GIF image, but would be processed as PHP code. In extreme cases, code execution is possible, but the attacker could also cause exhaustion of resources, denial of service, exposure of debug or system data (including application source code), or being bound to a particular server side process. This weakness may be due to a vulnerability in any of the technologies used by the web and application servers, due to misconfiguration, or resultant from another flaw in the application itself.

Affected languages: Not Language-Specific
Affected technologies: Web Server
Parent weaknesses: CWE-345

Consequences:
  - Confidentiality: Read Application Data
  - Availability: DoS: Crash, Exit, or Restart
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Architecture and Design] Make decisions on the server side based on file content and not on file name or extension.
CWE-647: Use of Non-Canonical URL Paths for Authorization Decisions

Description:
The product defines policy namespaces and makes authorization decisions based on the assumption that a URL is canonical. This can allow a non-canonical URL to bypass the authorization.

Extended Description:
If an application defines policy namespaces and makes authorization decisions based on the URL, but it does not require or convert to a canonical URL before making the authorization decision, then it opens the application to attack. For example, if the application only wants to allow access to http://www.example.com/mypage, then the attacker might be able to bypass this restriction using equivalent URLs such as: 
                
                   http://WWW.EXAMPLE.COM/mypage 
                   http://www.example.com/%6Dypage (alternate encoding) 
                   http://192.168.1.1/mypage (IP address) 
                   http://www.example.com/mypage/ (trailing /) 
                   http://www.example.com:80/mypage 
                
             Therefore it is important to specify access control policy that is based on the path information in some canonical form with all alternate encodings rejected (which can be accomplished by a default deny rule).

Affected languages: Not Language-Specific
Affected technologies: Web Server
Parent weaknesses: CWE-863, CWE-180

Consequences:
  - Access Control: Bypass Protection Mechanism
  - 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:
  - [Architecture and Design] Make access control policy based on path information in canonical form. Use very restrictive regular expressions to validate that the path is in the expected form.
  - [Architecture and Design] Reject all alternate path encodings that are not in the expected canonical form.

Demonstrative examples:
Example from CAPEC (CAPEC ID: 4, "Using Alternative IP Address Encodings"). An attacker identifies an application server that applies a security policy based on the domain and application name, so the access control policy covers authentication and authorization for anyone accessing http://example.domain:8080/application. However, by putting in the IP address of the host the application authentication and authorization controls may be bypassed http://192.168.0.1:8080/application. The attacker relies on the victim applying policy to the namespace abstraction and not having a default deny policy in place to manage exceptions.
CWE-648: Incorrect Use of Privileged APIs

Description:
The product does not conform to the API requirements for a function call that requires extra privileges. This could allow attackers to gain privileges by causing the function to be called incorrectly.

Extended Description:
When a product contains certain functions that perform operations requiring an elevated level of privilege, the caller of a privileged API must be careful to: 
                
                   ensure that assumptions made by the APIs are valid, such as validity of arguments 
                   account for known weaknesses in the design/implementation of the API 
                   call the API from a safe context 
                
             If the caller of the API does not follow these requirements, then it may allow a malicious user or process to elevate their privilege, hijack the process, or steal sensitive data. 
             For instance, it is important to know if privileged APIs do not shed their privileges before returning to the caller or if the privileged function might make certain assumptions about the data, context or state information passed to it by the caller. It is important to always know when and how privileged APIs can be called in order to ensure that their 

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

Consequences:
  - Access Control: Gain Privileges or Assume Identity
  - Confidentiality: Read Application Data
  - Integrity: Execute Unauthorized Code or Commands

Mitigations:
  - [Implementation] Before calling privileged APIs, always ensure that the assumptions made by the privileged code hold true prior to making the call.
  - [Architecture and Design] Know architecture and implementation weaknesses of the privileged APIs and make sure to account for these weaknesses before calling the privileged APIs to ensure that they can be called safely.
  - [Implementation] If privileged APIs make certain assumptions about data, context or state validity that are passed by the caller, the calling code must ensure that these assumptions have been validated prior to making the call.
  - [Implementation] If privileged APIs do not shed their privilege prior to returning to the calling code, then calling code needs to shed these privileges immediately and safely right after the call to the privileged APIs. In particular, the calling code needs to ensure that a privileged thread of execution will never

Real-world examples:
  - CVE-2003-0645: A Unix utility that displays online help files, if installed setuid, could allow a local attacker to gain privileges when a particular file-opening function is called.
CWE-649: Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking

Description:
The product uses obfuscation or encryption of inputs that should not be mutable by an external actor, but the product does not use integrity checks to detect if those inputs have been modified.

Extended Description:
When an application relies on obfuscation or incorrectly applied / weak encryption to protect client-controllable tokens or parameters, that may have an effect on the user state, system state, or some decision made on the server. Without protecting the tokens/parameters for integrity, the application is vulnerable to an attack where an adversary traverses the space of possible values of the said token/parameter in order to attempt to gain an advantage. The goal of the attacker is to find another admissible value that will somehow elevate their privileges in the system, disclose information or change the behavior of the system in some way beneficial to the attacker. If the application does not protect these critical tokens/parameters for integrity, it will not be able to determine that these values have been tampered with. Measures that are used to protect data for confidentiality should not be relied upon to provide the integrity service.

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

Consequences:
  - Integrity: Unexpected State

Mitigations:
  - [Architecture and Design] Protect important client controllable tokens/parameters for integrity using PKI methods (i.e. digital signatures) or other means, and checks for integrity on the server side.
  - [Architecture and Design] Repeated requests from a particular user that include invalid values of tokens/parameters (those that should not be changed manually by users) should result in the user account lockout.
  - [Architecture and Design] Client side tokens/parameters should not be such that it would be easy/predictable to guess another valid state.
  - [Architecture and Design] Obfuscation should not be relied upon. If encryption is used, it needs to be properly applied (i.e. proven algorithm and implementation, use padding, use random initialization vector, user proper encryption mode). Even with proper encryption where the ciphertext does not leak information about the p

Real-world examples:
  - CVE-2005-0039: An IPSec configuration does not perform integrity checking of the IPSec packet as the result of either not configuring ESP properly to support the integrity service or using AH improperly. In either c
CWE-65: Windows Hard Link

Description:
The product, when opening a file or directory, does not sufficiently handle when the name is associated with a hard link to a target that is outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.

Extended Description:
Failure for a system to check for hard links can result in vulnerability to different types of attacks. For example, an attacker can escalate their privileges if a file used by a privileged program is replaced with a hard link to a sensitive file (e.g. AUTOEXEC.BAT). When the process opens the file, the attacker can assume the privileges of that process, or prevent the program from accurately processing data.

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

Consequences:
  - Confidentiality: Read Files or Directories

Mitigations:
  - [Architecture and Design] Follow the principle of least privilege when assigning access rights to entities in a software system. 
                   Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected ar

Real-world examples:
  - CVE-2002-0725: File system allows local attackers to hide file usage activities via a hard link to the target file, which causes the link to be recorded in the audit trail instead of the target file.
  - CVE-2003-0844: Web server plugin allows local users to overwrite arbitrary files via a symlink attack on predictable temporary filenames.
CWE-650: Trusting HTTP Permission Methods on the Server Side

Description:
The server contains a protection mechanism that assumes that any URI that is accessed using HTTP GET will not cause a state change to the associated resource. This might allow attackers to bypass intended access restrictions and conduct resource modification and deletion attacks, since some applications allow GET to modify state.

Extended Description:
The HTTP GET method and some other methods are designed to retrieve resources and not to alter the state of the application or resources on the server side. Furthermore, the HTTP specification requires that GET requests (and other requests) should not have side effects. Believing that it will be enough to prevent unintended resource alterations, an application may disallow the HTTP requests to perform DELETE, PUT and POST operations on the resource representation. However, there is nothing in the HTTP protocol itself that actually prevents the HTTP GET method from performing more than just query of the data. Developers can easily code programs that accept a HTTP GET request that do in fact create, update or delete data on the server. For instance, it is a common practice with REST based Web Services to have HTTP GET requests modifying resources on the server side. However, whenever that happens, the access control needs to be properly enforced in the application. No assumptions should 

Affected languages: Not Language-Specific
Affected technologies: Web Based, Web Server
Parent weaknesses: CWE-436

Consequences:
  - Access Control: Gain Privileges or Assume Identity
  - Integrity: Modify Application Data
  - Confidentiality: Read Application Data

Mitigations:
  - [System Configuration] Configure ACLs on the server side to ensure that proper level of access control is defined for each accessible resource representation.
CWE-651: Exposure of WSDL File Containing Sensitive Information

Description:
The Web services architecture may require exposing a Web Service Definition Language (WSDL) file that contains information on the publicly accessible services and how callers of these services should interact with them (e.g. what parameters they expect and what types they return).

Extended Description:
An information exposure may occur if any of the following apply: 
                
                   The WSDL file is accessible to a wider audience than intended. 
                   The WSDL file contains information on the methods/services that should not be publicly accessible or information about deprecated methods. This problem is made more likely due to the WSDL often being automatically generated from the code. 
                   Information in the WSDL file helps guess names/locations of methods/resources that should not be publicly accessible.

Affected languages: Not Language-Specific
Affected technologies: Web Server
Parent weaknesses: CWE-538

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] Limit access to the WSDL file as much as possible. If services are provided only to a limited number of entities, it may be better to provide WSDL privately to each of these entities than to publish WSDL publicly.
  - [Architecture and Design] Make sure that WSDL does not describe methods that should not be publicly accessible. Make sure to protect service methods that should not be publicly accessible with access controls.
  - [Architecture and Design] Do not use method names in WSDL that might help an adversary guess names of private methods/resources used by the service.

Demonstrative examples:
The WSDL for a service providing information on the best price of a certain item exposes the following method: float getBestPrice(String ItemID) An attacker might guess that there is a method setBestPrice (String ItemID, float Price) that is available and invoke that method to try and change the best price of a given item to their advantage. The attack may succeed if the attacker correctly guesses the name of the method, the method does not have proper access controls around it and the service itself has the functionality to update the best price of the item.
CWE-652: Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')

Description:
The product uses external input to dynamically construct an XQuery expression used to retrieve data from an XML database, but it does not neutralize or incorrectly neutralizes that input. This allows an attacker to control the structure of the query.

Extended Description:
The net effect is that the attacker will have control over the information selected from the XML database and may use that ability to control application flow, modify logic, retrieve unauthorized data, or bypass important checks (e.g. authentication).

Affected languages: Not Language-Specific
Parent weaknesses: CWE-943, CWE-91

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Implementation] Use parameterized queries. This will help ensure separation between data plane and control plane.
  - [Implementation] Properly validate user input. Reject data where appropriate, filter where appropriate and escape where appropriate. Make sure input that will be used in XQL queries is safe in that context.

Demonstrative examples:
An attacker may pass XQuery expressions embedded in an otherwise standard XML document. The attacker tunnels through the application entry point to target the resource access layer. The string below is an example of an attacker accessing the accounts.xml to request the service provider send all user names back. doc(accounts.xml)//user[name='*'] The attacks that are possible through XQuery are difficult to predict, if the data is not validated prior to executing the XQL.