cwe_mitigation_ids_temp.json

[{"_key":"cwe_mitigation_00000","_id":"cwe_mitigation/cwe_mitigation_00000","_rev":"_dVfOTS2---","original_id":"5","name":"J2EE Misconfiguration: Data Transmission Without Encryption","metadata":{"Phase":"System Configuration","Description":"The application configuration should ensure that SSL or an encryption mechanism of equivalent strength and vetted reputation is used for all access-controlled pages."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00001","_id":"cwe_mitigation/cwe_mitigation_00001","_rev":"_dVfOTS2--_","original_id":"6","name":"J2EE Misconfiguration: Insufficient Session-ID Length","metadata":{"Phase":"Implementation","Description":"Session identifiers should be at least 128 bits long to prevent brute-force session guessing. A shorter session identifier leaves the application open to brute-force session guessing attacks."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00002","_id":"cwe_mitigation/cwe_mitigation_00002","_rev":"_dVfOTS2--A","original_id":"6","name":"J2EE Misconfiguration: Insufficient Session-ID Length","metadata":{"Phase":"Implementation","Description":"A lower bound on the number of valid session identifiers that are available to be guessed is the number of users that are active on a site at any given moment. However, any users that abandon their sessions without logging out will increase this number. (This is one of many good reasons to have a short inactive session timeout.) With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is less than 4 minutes. Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00003","_id":"cwe_mitigation/cwe_mitigation_00003","_rev":"_dVfOTS2--B","original_id":"7","name":"J2EE Misconfiguration: Missing Custom Error Page","metadata":{"Phase":"Implementation","Description":"Handle exceptions appropriately in source code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00004","_id":"cwe_mitigation/cwe_mitigation_00004","_rev":"_dVfOTS2--C","original_id":"7","name":"J2EE Misconfiguration: Missing Custom Error Page","metadata":{"Phase":"Implementation","Description":"Always define appropriate error pages. The application configuration should specify a default error page in order to guarantee that the application will never leak error messages to an attacker. Handling standard HTTP error codes is useful and user-friendly in addition to being a good security practice, and a good configuration will also define a last-chance error handler that catches any exception that could possibly be thrown by the application."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00005","_id":"cwe_mitigation/cwe_mitigation_00005","_rev":"_dVfOTS2--D","original_id":"7","name":"J2EE Misconfiguration: Missing Custom Error Page","metadata":{"Phase":"Implementation","Description":"Do not attempt to process an error or attempt to mask it."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00006","_id":"cwe_mitigation/cwe_mitigation_00006","_rev":"_dVfOTS2--E","original_id":"7","name":"J2EE Misconfiguration: Missing Custom Error Page","metadata":{"Phase":"Implementation","Description":"Verify return values are correct and do not supply sensitive information about the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00007","_id":"cwe_mitigation/cwe_mitigation_00007","_rev":"_dVfOTS2--F","original_id":"8","name":"J2EE Misconfiguration: Entity Bean Declared Remote","metadata":{"Phase":"Implementation","Description":"Declare Java beans \"local\" when possible. When a bean must be remotely accessible, make sure that sensitive information is not exposed, and ensure that the application logic performs appropriate validation of any data that might be modified by an attacker."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00008","_id":"cwe_mitigation/cwe_mitigation_00008","_rev":"_dVfOTS2--G","original_id":"9","name":"J2EE Misconfiguration: Weak Access Permissions for EJB Methods","metadata":{"Phase":"Architecture and Design","Description":"Follow the principle of least privilege when assigning access rights to EJB methods. Permission to invoke EJB methods should not be granted to the ANYONE role."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00009","_id":"cwe_mitigation/cwe_mitigation_00009","_rev":"_dVfOTS2--H","original_id":"11","name":"ASP.NET Misconfiguration: Creating Debug Binary","metadata":{"Phase":"System Configuration","Description":"Avoid releasing debug binaries into the production environment. Change the debug mode to false when the application is deployed into production."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00010","_id":"cwe_mitigation/cwe_mitigation_00010","_rev":"_dVfOTS2--I","original_id":"12","name":"ASP.NET Misconfiguration: Missing Custom Error Page","metadata":{"Phase":"System Configuration","Description":"Handle exceptions appropriately in source code. ASP .NET applications should be configured to use custom error pages instead of the framework default page."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00011","_id":"cwe_mitigation/cwe_mitigation_00011","_rev":"_dVfOTS2--J","original_id":"12","name":"ASP.NET Misconfiguration: Missing Custom Error Page","metadata":{"Phase":"Architecture and Design","Description":"Do not attempt to process an error or attempt to mask it."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00012","_id":"cwe_mitigation/cwe_mitigation_00012","_rev":"_dVfOTS6---","original_id":"12","name":"ASP.NET Misconfiguration: Missing Custom Error Page","metadata":{"Phase":"Implementation","Description":"Verify return values are correct and do not supply sensitive information about the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00013","_id":"cwe_mitigation/cwe_mitigation_00013","_rev":"_dVfOTS6--_","original_id":"13","name":"ASP.NET Misconfiguration: Password in Configuration File","metadata":{"Phase":"Implementation","Description":"Credentials stored in configuration files should be encrypted, Use standard APIs and industry accepted algorithms to encrypt the credentials stored in configuration files."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00014","_id":"cwe_mitigation/cwe_mitigation_00014","_rev":"_dVfOTS6--A","original_id":"14","name":"Compiler Removal of Code to Clear Buffers","metadata":{"Phase":"Implementation","Description":"Store the sensitive data in a \"volatile\" memory location if available."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00015","_id":"cwe_mitigation/cwe_mitigation_00015","_rev":"_dVfOTS6--B","original_id":"14","name":"Compiler Removal of Code to Clear Buffers","metadata":{"Phase":"Build and Compilation","Description":"If possible, configure your compiler so that it does not remove dead stores."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00016","_id":"cwe_mitigation/cwe_mitigation_00016","_rev":"_dVfOTS6--C","original_id":"14","name":"Compiler Removal of Code to Clear Buffers","metadata":{"Phase":"Architecture and Design","Description":"Where possible, encrypt sensitive data that are used by a software system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00019","_id":"cwe_mitigation/cwe_mitigation_00019","_rev":"_dVfOTS6--D","original_id":"15","name":"External Control of System or Configuration Setting","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00020","_id":"cwe_mitigation/cwe_mitigation_00020","_rev":"_dVfOTS6--E","original_id":"15","name":"External Control of System or Configuration Setting","metadata":{"Phase":"Implementation","Description":"Because setting manipulation covers a diverse set of functions, any attempt at illustrating it will inevitably be incomplete. Rather than searching for a tight-knit relationship between the functions addressed in the setting manipulation category, take a step back and consider the sorts of system values that an attacker should not be allowed to control."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00021","_id":"cwe_mitigation/cwe_mitigation_00021","_rev":"_dVfOTS6--F","original_id":"15","name":"External Control of System or Configuration Setting","metadata":{"Phase":"Implementation","Description":"In general, do not allow user-provided or otherwise untrusted data to control sensitive values. The leverage that an attacker gains by controlling these values is not always immediately obvious, but do not underestimate the creativity of the attacker."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00022","_id":"cwe_mitigation/cwe_mitigation_00022","_rev":"_dVfOTS6--G","original_id":"20","name":"Improper Input Validation","metadata":{"Phase":"Architecture and Design","Description":"Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build \"recognizers\" for that language.  This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00023","_id":"cwe_mitigation/cwe_mitigation_00023","_rev":"_dVfOTS6--H","original_id":"20","name":"Improper Input Validation","metadata":{"Phase":"Architecture and Design","Description":"Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00024","_id":"cwe_mitigation/cwe_mitigation_00024","_rev":"_dVfOTS6--I","original_id":"20","name":"Improper Input Validation","metadata":{"Phase":"Architecture and Design","Description":"Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00025","_id":"cwe_mitigation/cwe_mitigation_00025","_rev":"_dVfOTS6--J","original_id":"20","name":"Improper Input Validation","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00026","_id":"cwe_mitigation/cwe_mitigation_00026","_rev":"_dVfOTS6--K","original_id":"20","name":"Improper Input Validation","metadata":{"Phase":"Architecture and Design","Description":"\n                  For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.\n                  Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00027","_id":"cwe_mitigation/cwe_mitigation_00027","_rev":"_dVfOTS6--L","original_id":"20","name":"Improper Input Validation","metadata":{"Phase":"Implementation","Description":"When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00028","_id":"cwe_mitigation/cwe_mitigation_00028","_rev":"_dVfOTS6--M","original_id":"20","name":"Improper Input Validation","metadata":{"Phase":"Implementation","Description":"Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00029","_id":"cwe_mitigation/cwe_mitigation_00029","_rev":"_dVfOTS6--N","original_id":"20","name":"Improper Input Validation","metadata":{"Phase":"Implementation","Description":"Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00030","_id":"cwe_mitigation/cwe_mitigation_00030","_rev":"_dVfOTS6--O","original_id":"20","name":"Improper Input Validation","metadata":{"Phase":"Implementation","Description":"\n                  Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.\n                  Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00031","_id":"cwe_mitigation/cwe_mitigation_00031","_rev":"_dVfOTS6--P","original_id":"20","name":"Improper Input Validation","metadata":{"Phase":"Implementation","Description":"When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00042","_id":"cwe_mitigation/cwe_mitigation_00042","_rev":"_dVfOTS6--Q","original_id":"22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00043","_id":"cwe_mitigation/cwe_mitigation_00043","_rev":"_dVfOTS6--R","original_id":"22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00044","_id":"cwe_mitigation/cwe_mitigation_00044","_rev":"_dVfOTS6--S","original_id":"22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')","metadata":{"Phase":"Implementation","Description":"\n                  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 inputs after they have been checked.\n                  Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes \"..\" sequences and symbolic links (CWE-23, CWE-59). This includes:\n                  \n                     \n                        realpath() in C\n                        getCanonicalPath() in Java\n                        GetFullPath() in ASP.NET\n                        realpath() or abs_path() in Perl\n                        realpath() in PHP\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00045","_id":"cwe_mitigation/cwe_mitigation_00045","_rev":"_dVfOTS6--T","original_id":"22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')","metadata":{"Phase":"Architecture and Design","Description":"Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00046","_id":"cwe_mitigation/cwe_mitigation_00046","_rev":"_dVfOTS6--U","original_id":"22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')","metadata":{"Phase":"Operation","Description":"Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00047","_id":"cwe_mitigation/cwe_mitigation_00047","_rev":"_dVfOTS6--V","original_id":"22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00048","_id":"cwe_mitigation/cwe_mitigation_00048","_rev":"_dVfOTS6--W","original_id":"22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')","metadata":{"Phase":"Architecture and Design","Description":"\n                  When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.\n                  For example, ID 1 could map to \"inbox.txt\" and ID 2 could map to \"profile.txt\". Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00049","_id":"cwe_mitigation/cwe_mitigation_00049","_rev":"_dVfOTS6--X","original_id":"22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run the code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.\n                  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00050","_id":"cwe_mitigation/cwe_mitigation_00050","_rev":"_dVfOTS6--Y","original_id":"22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.\n                  This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00051","_id":"cwe_mitigation/cwe_mitigation_00051","_rev":"_dVfOTS6--Z","original_id":"22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')","metadata":{"Phase":"Implementation","Description":"\n                  Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.\n                  If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.\n\t\t  Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.\n                  In the context of path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00052","_id":"cwe_mitigation/cwe_mitigation_00052","_rev":"_dVfOTS6--a","original_id":"22","name":"Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')","metadata":{"Phase":"Operation","Description":"When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00062","_id":"cwe_mitigation/cwe_mitigation_00062","_rev":"_dVfOTS6--b","original_id":"23","name":"Relative Path Traversal","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00063","_id":"cwe_mitigation/cwe_mitigation_00063","_rev":"_dVfOTS6--c","original_id":"23","name":"Relative Path Traversal","metadata":{"Phase":"Implementation","Description":"\n                  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 inputs after they have been checked.\n                  Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes \"..\" sequences and symbolic links (CWE-23, CWE-59). This includes:\n                  \n                     \n                        realpath() in C\n                        getCanonicalPath() in Java\n                        GetFullPath() in ASP.NET\n                        realpath() or abs_path() in Perl\n                        realpath() in PHP\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00064","_id":"cwe_mitigation/cwe_mitigation_00064","_rev":"_dVfOTS6--d","original_id":"24","name":"Path Traversal: '../filedir'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00065","_id":"cwe_mitigation/cwe_mitigation_00065","_rev":"_dVfOTS6--e","original_id":"24","name":"Path Traversal: '../filedir'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00066","_id":"cwe_mitigation/cwe_mitigation_00066","_rev":"_dVfOTS6--f","original_id":"25","name":"Path Traversal: '/../filedir'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00067","_id":"cwe_mitigation/cwe_mitigation_00067","_rev":"_dVfOTS6--g","original_id":"25","name":"Path Traversal: '/../filedir'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00068","_id":"cwe_mitigation/cwe_mitigation_00068","_rev":"_dVfOTS6--h","original_id":"26","name":"Path Traversal: '/dir/../filename'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00069","_id":"cwe_mitigation/cwe_mitigation_00069","_rev":"_dVfOTS6--i","original_id":"26","name":"Path Traversal: '/dir/../filename'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00070","_id":"cwe_mitigation/cwe_mitigation_00070","_rev":"_dVfOTS6--j","original_id":"27","name":"Path Traversal: 'dir/../../filename'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00071","_id":"cwe_mitigation/cwe_mitigation_00071","_rev":"_dVfOTS6--k","original_id":"27","name":"Path Traversal: 'dir/../../filename'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00072","_id":"cwe_mitigation/cwe_mitigation_00072","_rev":"_dVfOTS6--l","original_id":"28","name":"Path Traversal: '..\\filedir'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00073","_id":"cwe_mitigation/cwe_mitigation_00073","_rev":"_dVfOTS6--m","original_id":"28","name":"Path Traversal: '..\\filedir'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00074","_id":"cwe_mitigation/cwe_mitigation_00074","_rev":"_dVfOTS6--n","original_id":"29","name":"Path Traversal: '\\..\\filename'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00075","_id":"cwe_mitigation/cwe_mitigation_00075","_rev":"_dVfOTS6--o","original_id":"29","name":"Path Traversal: '\\..\\filename'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00076","_id":"cwe_mitigation/cwe_mitigation_00076","_rev":"_dVfOTS6--p","original_id":"30","name":"Path Traversal: '\\dir\\..\\filename'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00077","_id":"cwe_mitigation/cwe_mitigation_00077","_rev":"_dVfOTS6--q","original_id":"30","name":"Path Traversal: '\\dir\\..\\filename'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00078","_id":"cwe_mitigation/cwe_mitigation_00078","_rev":"_dVfOTS6--r","original_id":"31","name":"Path Traversal: 'dir\\..\\..\\filename'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00079","_id":"cwe_mitigation/cwe_mitigation_00079","_rev":"_dVfOTS6--s","original_id":"31","name":"Path Traversal: 'dir\\..\\..\\filename'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00080","_id":"cwe_mitigation/cwe_mitigation_00080","_rev":"_dVfOTS6--t","original_id":"32","name":"Path Traversal: '...' (Triple Dot)","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00081","_id":"cwe_mitigation/cwe_mitigation_00081","_rev":"_dVfOTS6--u","original_id":"32","name":"Path Traversal: '...' (Triple Dot)","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00082","_id":"cwe_mitigation/cwe_mitigation_00082","_rev":"_dVfOTS6--v","original_id":"33","name":"Path Traversal: '....' (Multiple Dot)","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00083","_id":"cwe_mitigation/cwe_mitigation_00083","_rev":"_dVfOTS6--w","original_id":"33","name":"Path Traversal: '....' (Multiple Dot)","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00084","_id":"cwe_mitigation/cwe_mitigation_00084","_rev":"_dVfOTS6--x","original_id":"34","name":"Path Traversal: '....//'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00085","_id":"cwe_mitigation/cwe_mitigation_00085","_rev":"_dVfOTS6--y","original_id":"34","name":"Path Traversal: '....//'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00088","_id":"cwe_mitigation/cwe_mitigation_00088","_rev":"_dVfOTS6--z","original_id":"35","name":"Path Traversal: '.../...//'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00089","_id":"cwe_mitigation/cwe_mitigation_00089","_rev":"_dVfOTS6--0","original_id":"35","name":"Path Traversal: '.../...//'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00090","_id":"cwe_mitigation/cwe_mitigation_00090","_rev":"_dVfOTS6--1","original_id":"37","name":"Path Traversal: '/absolute/pathname/here'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00091","_id":"cwe_mitigation/cwe_mitigation_00091","_rev":"_dVfOTS6--2","original_id":"37","name":"Path Traversal: '/absolute/pathname/here'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00092","_id":"cwe_mitigation/cwe_mitigation_00092","_rev":"_dVfOTS6--3","original_id":"38","name":"Path Traversal: '\\absolute\\pathname\\here'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00093","_id":"cwe_mitigation/cwe_mitigation_00093","_rev":"_dVfOTS6--4","original_id":"38","name":"Path Traversal: '\\absolute\\pathname\\here'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00094","_id":"cwe_mitigation/cwe_mitigation_00094","_rev":"_dVfOTS6--5","original_id":"39","name":"Path Traversal: 'C:dirname'","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00095","_id":"cwe_mitigation/cwe_mitigation_00095","_rev":"_dVfOTS6--6","original_id":"39","name":"Path Traversal: 'C:dirname'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00096","_id":"cwe_mitigation/cwe_mitigation_00096","_rev":"_dVfOTS6--7","original_id":"40","name":"Path Traversal: '\\\\UNC\\share\\name\\' (Windows UNC Share)","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00097","_id":"cwe_mitigation/cwe_mitigation_00097","_rev":"_dVfOTS6--8","original_id":"40","name":"Path Traversal: '\\\\UNC\\share\\name\\' (Windows UNC Share)","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00098","_id":"cwe_mitigation/cwe_mitigation_00098","_rev":"_dVfOTS6--9","original_id":"41","name":"Improper Resolution of Path Equivalence","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00099","_id":"cwe_mitigation/cwe_mitigation_00099","_rev":"_dVfOTS6-_-","original_id":"41","name":"Improper Resolution of Path Equivalence","metadata":{"Phase":"Implementation","Description":"Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00100","_id":"cwe_mitigation/cwe_mitigation_00100","_rev":"_dVfOTT----","original_id":"41","name":"Improper Resolution of Path Equivalence","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00108","_id":"cwe_mitigation/cwe_mitigation_00108","_rev":"_dVfOTT---_","original_id":"51","name":"Path Equivalence: '/multiple//internal/slash'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00109","_id":"cwe_mitigation/cwe_mitigation_00109","_rev":"_dVfOTT---A","original_id":"52","name":"Path Equivalence: '/multiple/trailing/slash//'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00110","_id":"cwe_mitigation/cwe_mitigation_00110","_rev":"_dVfOTT---B","original_id":"53","name":"Path Equivalence: '\\multiple\\\\internal\\backslash'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00111","_id":"cwe_mitigation/cwe_mitigation_00111","_rev":"_dVfOTT---C","original_id":"54","name":"Path Equivalence: 'filedir\\' (Trailing Backslash)","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00112","_id":"cwe_mitigation/cwe_mitigation_00112","_rev":"_dVfOTT---D","original_id":"55","name":"Path Equivalence: '/./' (Single Dot Directory)","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00113","_id":"cwe_mitigation/cwe_mitigation_00113","_rev":"_dVfOTT---E","original_id":"56","name":"Path Equivalence: 'filedir*' (Wildcard)","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00114","_id":"cwe_mitigation/cwe_mitigation_00114","_rev":"_dVfOTT---F","original_id":"57","name":"Path Equivalence: 'fakedir/../realdir/filename'","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00115","_id":"cwe_mitigation/cwe_mitigation_00115","_rev":"_dVfOTT---G","original_id":"58","name":"Path Equivalence: Windows 8.3 Filename","metadata":{"Phase":"System Configuration","Description":"Disable Windows from supporting 8.3 filenames by editing the Windows registry. Preventing 8.3 filenames will not remove previously generated 8.3 filenames."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00116","_id":"cwe_mitigation/cwe_mitigation_00116","_rev":"_dVfOTT---H","original_id":"59","name":"Improper Link Resolution Before File Access ('Link Following')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Follow the principle of least privilege when assigning access rights to entities in a software system.\n                  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 areas that can be trusted.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00124","_id":"cwe_mitigation/cwe_mitigation_00124","_rev":"_dVfOTT---I","original_id":"61","name":"UNIX Symbolic Link (Symlink) Following","metadata":{"Phase":"Implementation","Description":"Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00125","_id":"cwe_mitigation/cwe_mitigation_00125","_rev":"_dVfOTT---J","original_id":"61","name":"UNIX Symbolic Link (Symlink) Following","metadata":{"Phase":"Architecture and Design","Description":"\n                  Follow the principle of least privilege when assigning access rights to entities in a software system.\n                  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 areas that can be trusted.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00126","_id":"cwe_mitigation/cwe_mitigation_00126","_rev":"_dVfOTT---K","original_id":"62","name":"UNIX Hard Link","metadata":{"Phase":"Architecture and Design","Description":"\n                  Follow the principle of least privilege when assigning access rights to entities in a software system.\n                  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 areas that can be trusted.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00127","_id":"cwe_mitigation/cwe_mitigation_00127","_rev":"_dVfOTT---L","original_id":"64","name":"Windows Shortcut Following (.LNK)","metadata":{"Phase":"Architecture and Design","Description":"\n                  Follow the principle of least privilege when assigning access rights to entities in a software system.\n                  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 areas that can be trusted.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00128","_id":"cwe_mitigation/cwe_mitigation_00128","_rev":"_dVfOTT---M","original_id":"65","name":"Windows Hard Link","metadata":{"Phase":"Architecture and Design","Description":"\n                  Follow the principle of least privilege when assigning access rights to entities in a software system.\n                  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 areas that can be trusted.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00136","_id":"cwe_mitigation/cwe_mitigation_00136","_rev":"_dVfOTT---N","original_id":"67","name":"Improper Handling of Windows Device Names","metadata":{"Phase":"Implementation","Description":"Be familiar with the device names in the operating system where your system is deployed. Check input for these device names."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00137","_id":"cwe_mitigation/cwe_mitigation_00137","_rev":"_dVfOTT---O","original_id":"69","name":"Improper Handling of Windows ::DATA Alternate Data Stream","metadata":{"Phase":"Testing","Description":"Software tools are capable of finding ADSs on your system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00138","_id":"cwe_mitigation/cwe_mitigation_00138","_rev":"_dVfOTT---P","original_id":"69","name":"Improper Handling of Windows ::DATA Alternate Data Stream","metadata":{"Phase":"Implementation","Description":"Ensure that the source code correctly parses the filename to read or write to the correct stream."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00139","_id":"cwe_mitigation/cwe_mitigation_00139","_rev":"_dVfOTT---Q","original_id":"73","name":"External Control of File Name or Path","metadata":{"Phase":"Architecture and Design","Description":"When the set of filenames is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames, and reject all other inputs. For example, ID 1 could map to \"inbox.txt\" and ID 2 could map to \"profile.txt\". Features such as the ESAPI AccessReferenceMap provide this capability."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00140","_id":"cwe_mitigation/cwe_mitigation_00140","_rev":"_dVfOTT---R","original_id":"73","name":"External Control of File Name or Path","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run your code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict all access to files within a particular directory.\n                  Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00141","_id":"cwe_mitigation/cwe_mitigation_00141","_rev":"_dVfOTT---S","original_id":"73","name":"External Control of File Name or Path","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00142","_id":"cwe_mitigation/cwe_mitigation_00142","_rev":"_dVfOTT---T","original_id":"73","name":"External Control of File Name or Path","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00143","_id":"cwe_mitigation/cwe_mitigation_00143","_rev":"_dVfOTT---U","original_id":"73","name":"External Control of File Name or Path","metadata":{"Phase":"Implementation","Description":"Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes \"..\" sequences and symbolic links (CWE-23, CWE-59)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00144","_id":"cwe_mitigation/cwe_mitigation_00144","_rev":"_dVfOTT---V","original_id":"73","name":"External Control of File Name or Path","metadata":{"Phase":"Installation","Description":"Use OS-level permissions and run as a low-privileged user to limit the scope of any successful attack."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00145","_id":"cwe_mitigation/cwe_mitigation_00145","_rev":"_dVfOTT---W","original_id":"73","name":"External Control of File Name or Path","metadata":{"Phase":"Operation","Description":"If you are using PHP, configure your application so that it does not use register_globals. During implementation, develop your application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00146","_id":"cwe_mitigation/cwe_mitigation_00146","_rev":"_dVfOTT---X","original_id":"73","name":"External Control of File Name or Path","metadata":{"Phase":"Testing","Description":"Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00147","_id":"cwe_mitigation/cwe_mitigation_00147","_rev":"_dVfOTT---Y","original_id":"73","name":"External Control of File Name or Path","metadata":{"Phase":"Testing","Description":"Use dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00148","_id":"cwe_mitigation/cwe_mitigation_00148","_rev":"_dVfOTT---Z","original_id":"73","name":"External Control of File Name or Path","metadata":{"Phase":"Testing","Description":"Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00150","_id":"cwe_mitigation/cwe_mitigation_00150","_rev":"_dVfOTT---a","original_id":"74","name":"Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')","metadata":{"Phase":"Requirements","Description":"Programming languages and supporting technologies might be chosen which are not subject to these issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00151","_id":"cwe_mitigation/cwe_mitigation_00151","_rev":"_dVfOTT---b","original_id":"74","name":"Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')","metadata":{"Phase":"Implementation","Description":"Utilize an appropriate mix of allowlist and denylist parsing to filter control-plane syntax from all input."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00152","_id":"cwe_mitigation/cwe_mitigation_00152","_rev":"_dVfOTT---c","original_id":"75","name":"Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)","metadata":{"Phase":"Requirements","Description":"Programming languages and supporting technologies might be chosen which are not subject to these issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00153","_id":"cwe_mitigation/cwe_mitigation_00153","_rev":"_dVfOTT---d","original_id":"75","name":"Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)","metadata":{"Phase":"Implementation","Description":"Utilize an appropriate mix of allowlist and denylist parsing to filter special element syntax from all input."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00154","_id":"cwe_mitigation/cwe_mitigation_00154","_rev":"_dVfOTT---e","original_id":"76","name":"Improper Neutralization of Equivalent Special Elements","metadata":{"Phase":"Requirements","Description":"Programming languages and supporting technologies might be chosen which are not subject to these issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00155","_id":"cwe_mitigation/cwe_mitigation_00155","_rev":"_dVfOTT---f","original_id":"76","name":"Improper Neutralization of Equivalent Special Elements","metadata":{"Phase":"Implementation","Description":"Utilize an appropriate mix of allowlist and denylist parsing to filter equivalent special element syntax from all input."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00156","_id":"cwe_mitigation/cwe_mitigation_00156","_rev":"_dVfOTT---g","original_id":"77","name":"Improper Neutralization of Special Elements used in a Command ('Command Injection')","metadata":{"Phase":"Architecture and Design","Description":"If at all possible, use library calls rather than external processes to recreate the desired functionality."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00157","_id":"cwe_mitigation/cwe_mitigation_00157","_rev":"_dVfOTT---h","original_id":"77","name":"Improper Neutralization of Special Elements used in a Command ('Command Injection')","metadata":{"Phase":"Implementation","Description":"If possible, ensure that all external commands called from the program are statically created."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00158","_id":"cwe_mitigation/cwe_mitigation_00158","_rev":"_dVfOTT---i","original_id":"77","name":"Improper Neutralization of Special Elements used in a Command ('Command Injection')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00159","_id":"cwe_mitigation/cwe_mitigation_00159","_rev":"_dVfOTT---j","original_id":"77","name":"Improper Neutralization of Special Elements used in a Command ('Command Injection')","metadata":{"Phase":"Operation","Description":"Run time: Run time policy enforcement may be used in an allowlist fashion to prevent use of any non-sanctioned commands."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00160","_id":"cwe_mitigation/cwe_mitigation_00160","_rev":"_dVfOTT---k","original_id":"77","name":"Improper Neutralization of Special Elements used in a Command ('Command Injection')","metadata":{"Phase":"System Configuration","Description":"Assign permissions to the software system that prevents the user from accessing/opening privileged files."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00161","_id":"cwe_mitigation/cwe_mitigation_00161","_rev":"_dVfOTT---l","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Architecture and Design","Description":"If at all possible, use library calls rather than external processes to recreate the desired functionality."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00162","_id":"cwe_mitigation/cwe_mitigation_00162","_rev":"_dVfOTT---m","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run the code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.\n                  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00163","_id":"cwe_mitigation/cwe_mitigation_00163","_rev":"_dVfOTT---n","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Architecture and Design","Description":"For any data that will be used to generate a command to be executed, keep as much of that data out of external control as possible. For example, in web applications, this may require storing the data locally in the session's state instead of sending it out to the client in a hidden form field."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00164","_id":"cwe_mitigation/cwe_mitigation_00164","_rev":"_dVfOTT---o","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00165","_id":"cwe_mitigation/cwe_mitigation_00165","_rev":"_dVfOTT---p","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00166","_id":"cwe_mitigation/cwe_mitigation_00166","_rev":"_dVfOTT---q","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00167","_id":"cwe_mitigation/cwe_mitigation_00167","_rev":"_dVfOTT---r","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Implementation","Description":"If the program to be executed allows arguments to be specified within an input file or from standard input, then consider using that mode to pass arguments instead of the command line."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00168","_id":"cwe_mitigation/cwe_mitigation_00168","_rev":"_dVfOTT---s","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Architecture and Design","Description":"\n                  If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.\n                  Some languages offer multiple functions that can be used to invoke commands. Where possible, identify any function that invokes a command shell using a single string, and replace it with a function that requires individual arguments. These functions typically perform appropriate quoting and filtering of arguments. For example, in C, the system() function accepts a string that contains the entire command to be executed, whereas execl(), execve(), and others require an array of strings, one for each argument. In Windows, CreateProcess() only accepts one command at a time. In Perl, if system() is provided with an array of arguments, then it will quote each of the arguments.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00169","_id":"cwe_mitigation/cwe_mitigation_00169","_rev":"_dVfOTT---t","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When constructing OS command strings, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.\n                  Note that proper output encoding, escaping, and quoting is the most effective solution for preventing OS command injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent OS command injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, when invoking a mail program, you might need to allow the subject field to contain otherwise-dangerous inputs like \";\" and \">\" characters, which would need to be escaped or otherwise handled. In this case, stripping the character might reduce the risk of OS command injection, but it would produce incorrect behavior because the subject field would not be recorded as the user intended. This might seem to be a minor inconvenience, but it could be more important when the program relies on well-structured subject lines in order to pass messages to other components.\n                  Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00170","_id":"cwe_mitigation/cwe_mitigation_00170","_rev":"_dVfOTT---u","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Architecture and Design","Description":"When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00171","_id":"cwe_mitigation/cwe_mitigation_00171","_rev":"_dVfOTT---v","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Operation","Description":"Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's \"-T\" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00172","_id":"cwe_mitigation/cwe_mitigation_00172","_rev":"_dVfOTT---w","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Operation","Description":"Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's \"-T\" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00173","_id":"cwe_mitigation/cwe_mitigation_00173","_rev":"_dVfOTT---x","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Implementation","Description":"\n                  Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.\n                  If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.\n\t\t  Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.\n                  In the context of OS Command Injection, error information passed back to the user might reveal whether an OS command is being executed and possibly which command is being used.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00174","_id":"cwe_mitigation/cwe_mitigation_00174","_rev":"_dVfOTT---y","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Operation","Description":"Use runtime policy enforcement to create an allowlist of allowable commands, then prevent use of any command that does not appear in the allowlist. Technologies such as AppArmor are available to do this."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00175","_id":"cwe_mitigation/cwe_mitigation_00175","_rev":"_dVfOTT---z","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Operation","Description":"Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00176","_id":"cwe_mitigation/cwe_mitigation_00176","_rev":"_dVfOTT---0","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00177","_id":"cwe_mitigation/cwe_mitigation_00177","_rev":"_dVfOTT---1","original_id":"78","name":"Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","metadata":{"Phase":"Operation","Description":"When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00187","_id":"cwe_mitigation/cwe_mitigation_00187","_rev":"_dVfOTT---2","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00188","_id":"cwe_mitigation/cwe_mitigation_00188","_rev":"_dVfOTT---3","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Implementation","Description":"\n                  Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.\n                  For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.\n                  Parts of the same output document may require different encodings, which will vary depending on whether the output is in the:\n                  \n                     \n                        HTML body\n                        Element attributes (such as src=\"XYZ\")\n                        URIs\n                        JavaScript sections\n                        Cascading Style Sheets and style property\n                     \n                  \n                  etc. Note that HTML Entity Encoding is only appropriate for the HTML body.\n                  Consult the XSS Prevention Cheat Sheet [REF-724] for more details on the types of encoding and escaping that are needed.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00189","_id":"cwe_mitigation/cwe_mitigation_00189","_rev":"_dVfOTT---4","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Architecture and Design","Description":"Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00190","_id":"cwe_mitigation/cwe_mitigation_00190","_rev":"_dVfOTT---5","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00191","_id":"cwe_mitigation/cwe_mitigation_00191","_rev":"_dVfOTT---6","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Architecture and Design","Description":"If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00192","_id":"cwe_mitigation/cwe_mitigation_00192","_rev":"_dVfOTT---7","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Implementation","Description":"\n                  Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.\n                  The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00193","_id":"cwe_mitigation/cwe_mitigation_00193","_rev":"_dVfOTT---8","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Implementation","Description":"With Struts, write all data from form beans with the bean's filter attribute set to true."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00194","_id":"cwe_mitigation/cwe_mitigation_00194","_rev":"_dVfOTT---9","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Implementation","Description":"To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00195","_id":"cwe_mitigation/cwe_mitigation_00195","_rev":"_dVfOTT--_-","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When dynamically constructing web pages, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. All input should be validated and cleansed, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. It is common to see data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended.\n                  Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent XSS, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, in a chat application, the heart emoticon (\"<3\") would likely pass the validation step, since it is commonly used. However, it cannot be directly inserted into the web page because it contains the \"<\" character, which would need to be escaped or otherwise handled. In this case, stripping the \"<\" might reduce the risk of XSS, but it would produce incorrect behavior because the emoticon would not be recorded. This might seem to be a minor inconvenience, but it would be more important in a mathematical forum that wants to represent inequalities.\n                  Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.\n                  Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00196","_id":"cwe_mitigation/cwe_mitigation_00196","_rev":"_dVfOTT--__","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Architecture and Design","Description":"When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00197","_id":"cwe_mitigation/cwe_mitigation_00197","_rev":"_dVfOTT--_A","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Operation","Description":"Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00198","_id":"cwe_mitigation/cwe_mitigation_00198","_rev":"_dVfOTT--_B","original_id":"79","name":"Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')","metadata":{"Phase":"Operation","Description":"When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00201","_id":"cwe_mitigation/cwe_mitigation_00201","_rev":"_dVfOTT--_C","original_id":"80","name":"Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)","metadata":{"Phase":"Implementation","Description":"Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00202","_id":"cwe_mitigation/cwe_mitigation_00202","_rev":"_dVfOTT--_D","original_id":"80","name":"Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)","metadata":{"Phase":"Implementation","Description":"\n                  Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.\n                  The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00203","_id":"cwe_mitigation/cwe_mitigation_00203","_rev":"_dVfOTTC---","original_id":"80","name":"Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)","metadata":{"Phase":"Implementation","Description":"With Struts, write all data from form beans with the bean's filter attribute set to true."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00204","_id":"cwe_mitigation/cwe_mitigation_00204","_rev":"_dVfOTTC--_","original_id":"80","name":"Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)","metadata":{"Phase":"Implementation","Description":"To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00205","_id":"cwe_mitigation/cwe_mitigation_00205","_rev":"_dVfOTTC--A","original_id":"81","name":"Improper Neutralization of Script in an Error Message Web Page","metadata":{"Phase":"Implementation","Description":"Do not write user-controlled input to error pages."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00206","_id":"cwe_mitigation/cwe_mitigation_00206","_rev":"_dVfOTTC--B","original_id":"81","name":"Improper Neutralization of Script in an Error Message Web Page","metadata":{"Phase":"Implementation","Description":"Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00207","_id":"cwe_mitigation/cwe_mitigation_00207","_rev":"_dVfOTTC--C","original_id":"81","name":"Improper Neutralization of Script in an Error Message Web Page","metadata":{"Phase":"Implementation","Description":"\n                  Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.\n                  The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00208","_id":"cwe_mitigation/cwe_mitigation_00208","_rev":"_dVfOTTC--D","original_id":"81","name":"Improper Neutralization of Script in an Error Message Web Page","metadata":{"Phase":"Implementation","Description":"With Struts, write all data from form beans with the bean's filter attribute set to true."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00209","_id":"cwe_mitigation/cwe_mitigation_00209","_rev":"_dVfOTTC--E","original_id":"81","name":"Improper Neutralization of Script in an Error Message Web Page","metadata":{"Phase":"Implementation","Description":"To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00210","_id":"cwe_mitigation/cwe_mitigation_00210","_rev":"_dVfOTTC--F","original_id":"82","name":"Improper Neutralization of Script in Attributes of IMG Tags in a Web Page","metadata":{"Phase":"Implementation","Description":"\n                  Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.\n                  The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00211","_id":"cwe_mitigation/cwe_mitigation_00211","_rev":"_dVfOTTC--G","original_id":"82","name":"Improper Neutralization of Script in Attributes of IMG Tags in a Web Page","metadata":{"Phase":"Implementation","Description":"To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00212","_id":"cwe_mitigation/cwe_mitigation_00212","_rev":"_dVfOTTC--H","original_id":"83","name":"Improper Neutralization of Script in Attributes in a Web Page","metadata":{"Phase":"Implementation","Description":"Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00213","_id":"cwe_mitigation/cwe_mitigation_00213","_rev":"_dVfOTTC--I","original_id":"83","name":"Improper Neutralization of Script in Attributes in a Web Page","metadata":{"Phase":"Implementation","Description":"\n                  Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.\n                  The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00214","_id":"cwe_mitigation/cwe_mitigation_00214","_rev":"_dVfOTTC--J","original_id":"83","name":"Improper Neutralization of Script in Attributes in a Web Page","metadata":{"Phase":"Implementation","Description":"With Struts, write all data from form beans with the bean's filter attribute set to true."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00215","_id":"cwe_mitigation/cwe_mitigation_00215","_rev":"_dVfOTTC--K","original_id":"83","name":"Improper Neutralization of Script in Attributes in a Web Page","metadata":{"Phase":"Implementation","Description":"To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00216","_id":"cwe_mitigation/cwe_mitigation_00216","_rev":"_dVfOTTC--L","original_id":"84","name":"Improper Neutralization of Encoded URI Schemes in a Web Page","metadata":{"Phase":"Implementation","Description":"Resolve all URIs to absolute or canonical representations before processing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00217","_id":"cwe_mitigation/cwe_mitigation_00217","_rev":"_dVfOTTC--M","original_id":"84","name":"Improper Neutralization of Encoded URI Schemes in a Web Page","metadata":{"Phase":"Implementation","Description":"Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00218","_id":"cwe_mitigation/cwe_mitigation_00218","_rev":"_dVfOTTC--N","original_id":"84","name":"Improper Neutralization of Encoded URI Schemes in a Web Page","metadata":{"Phase":"Implementation","Description":"\n                  Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.\n                  The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00219","_id":"cwe_mitigation/cwe_mitigation_00219","_rev":"_dVfOTTC--O","original_id":"84","name":"Improper Neutralization of Encoded URI Schemes in a Web Page","metadata":{"Phase":"Implementation","Description":"With Struts, write all data from form beans with the bean's filter attribute set to true."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00220","_id":"cwe_mitigation/cwe_mitigation_00220","_rev":"_dVfOTTC--P","original_id":"84","name":"Improper Neutralization of Encoded URI Schemes in a Web Page","metadata":{"Phase":"Implementation","Description":"To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00221","_id":"cwe_mitigation/cwe_mitigation_00221","_rev":"_dVfOTTC--Q","original_id":"85","name":"Doubled Character XSS Manipulations","metadata":{"Phase":"Implementation","Description":"Resolve all filtered input to absolute or canonical representations before processing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00222","_id":"cwe_mitigation/cwe_mitigation_00222","_rev":"_dVfOTTC--R","original_id":"85","name":"Doubled Character XSS Manipulations","metadata":{"Phase":"Implementation","Description":"Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00223","_id":"cwe_mitigation/cwe_mitigation_00223","_rev":"_dVfOTTC--S","original_id":"85","name":"Doubled Character XSS Manipulations","metadata":{"Phase":"Implementation","Description":"\n                  Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.\n                  The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00224","_id":"cwe_mitigation/cwe_mitigation_00224","_rev":"_dVfOTTC--T","original_id":"85","name":"Doubled Character XSS Manipulations","metadata":{"Phase":"Implementation","Description":"With Struts, write all data from form beans with the bean's filter attribute set to true."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00225","_id":"cwe_mitigation/cwe_mitigation_00225","_rev":"_dVfOTTC--U","original_id":"85","name":"Doubled Character XSS Manipulations","metadata":{"Phase":"Implementation","Description":"To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00226","_id":"cwe_mitigation/cwe_mitigation_00226","_rev":"_dVfOTTC--V","original_id":"86","name":"Improper Neutralization of Invalid Characters in Identifiers in Web Pages","metadata":{"Phase":"Implementation","Description":"\n                  Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.\n                  The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00227","_id":"cwe_mitigation/cwe_mitigation_00227","_rev":"_dVfOTTC--W","original_id":"86","name":"Improper Neutralization of Invalid Characters in Identifiers in Web Pages","metadata":{"Phase":"Implementation","Description":"To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00228","_id":"cwe_mitigation/cwe_mitigation_00228","_rev":"_dVfOTTC--X","original_id":"87","name":"Improper Neutralization of Alternate XSS Syntax","metadata":{"Phase":"Implementation","Description":"Resolve all input to absolute or canonical representations before processing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00229","_id":"cwe_mitigation/cwe_mitigation_00229","_rev":"_dVfOTTC--Y","original_id":"87","name":"Improper Neutralization of Alternate XSS Syntax","metadata":{"Phase":"Implementation","Description":"Carefully check each input parameter against a rigorous positive specification (allowlist) defining the specific characters and format allowed. All input should be neutralized, not just parameters that the user is supposed to specify, but all data in the request, including tag attributes, hidden fields, cookies, headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to validate only fields that are expected to be redisplayed by the site. We often encounter data from the request that is reflected by the application server or the application that the development team did not anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore, validating ALL parts of the HTTP request is recommended."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00230","_id":"cwe_mitigation/cwe_mitigation_00230","_rev":"_dVfOTTC--Z","original_id":"87","name":"Improper Neutralization of Alternate XSS Syntax","metadata":{"Phase":"Implementation","Description":"\n                  Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.\n                  The problem of inconsistent output encodings often arises in web pages. If an encoding is not specified in an HTTP header, web browsers often guess about which encoding is being used. This can open up the browser to subtle XSS attacks.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00231","_id":"cwe_mitigation/cwe_mitigation_00231","_rev":"_dVfOTTC--a","original_id":"87","name":"Improper Neutralization of Alternate XSS Syntax","metadata":{"Phase":"Implementation","Description":"With Struts, write all data from form beans with the bean's filter attribute set to true."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00232","_id":"cwe_mitigation/cwe_mitigation_00232","_rev":"_dVfOTTC--b","original_id":"87","name":"Improper Neutralization of Alternate XSS Syntax","metadata":{"Phase":"Implementation","Description":"To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00233","_id":"cwe_mitigation/cwe_mitigation_00233","_rev":"_dVfOTTC--c","original_id":"88","name":"Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')","metadata":{"Phase":"Implementation","Description":"Where possible, avoid building a single string that contains the command and its arguments.  Some languages or frameworks have functions that support specifying independent arguments, e.g. as an array, which is used to automatically perform the appropriate quoting or escaping while building the command.  For example, in PHP, escapeshellarg() can be used to escape a single argument to system(), or exec() can be called with an array of arguments.  In C, code can often be refactored from using system() - which accepts a single string - to using exec(), which requires separate function arguments for each parameter."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00234","_id":"cwe_mitigation/cwe_mitigation_00234","_rev":"_dVfOTTC--d","original_id":"88","name":"Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')","metadata":{"Phase":"Architecture and Design","Description":"Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, request headers as well as content, URL components, e-mail, files, databases, and any external systems that provide data to the application. Perform input validation at well-defined interfaces."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00235","_id":"cwe_mitigation/cwe_mitigation_00235","_rev":"_dVfOTTC--e","original_id":"88","name":"Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00236","_id":"cwe_mitigation/cwe_mitigation_00236","_rev":"_dVfOTTC--f","original_id":"88","name":"Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')","metadata":{"Phase":"Implementation","Description":"Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00237","_id":"cwe_mitigation/cwe_mitigation_00237","_rev":"_dVfOTTC--g","original_id":"88","name":"Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')","metadata":{"Phase":"Implementation","Description":"\n                  Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.\n                  Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00238","_id":"cwe_mitigation/cwe_mitigation_00238","_rev":"_dVfOTTC--h","original_id":"88","name":"Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')","metadata":{"Phase":"Implementation","Description":"When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00239","_id":"cwe_mitigation/cwe_mitigation_00239","_rev":"_dVfOTTC--i","original_id":"88","name":"Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')","metadata":{"Phase":"Implementation","Description":"When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00240","_id":"cwe_mitigation/cwe_mitigation_00240","_rev":"_dVfOTTC--j","original_id":"88","name":"Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')","metadata":{"Phase":"Testing","Description":"Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00241","_id":"cwe_mitigation/cwe_mitigation_00241","_rev":"_dVfOTTC--k","original_id":"88","name":"Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')","metadata":{"Phase":"Testing","Description":"Use dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00242","_id":"cwe_mitigation/cwe_mitigation_00242","_rev":"_dVfOTTC--l","original_id":"89","name":"Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00243","_id":"cwe_mitigation/cwe_mitigation_00243","_rev":"_dVfOTTC--m","original_id":"89","name":"Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","metadata":{"Phase":"Architecture and Design","Description":"\n                  If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.\n                  Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using \"exec\" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00244","_id":"cwe_mitigation/cwe_mitigation_00244","_rev":"_dVfOTTC--n","original_id":"89","name":"Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","metadata":{"Phase":"Architecture and Design","Description":"\n                  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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.\n                  Specifically, follow the principle of least privilege when creating user accounts to a SQL database. The database users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data. Use the strictest permissions possible on all database objects, such as execute-only for stored procedures.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00245","_id":"cwe_mitigation/cwe_mitigation_00245","_rev":"_dVfOTTC--o","original_id":"89","name":"Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00246","_id":"cwe_mitigation/cwe_mitigation_00246","_rev":"_dVfOTTC--p","original_id":"89","name":"Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","metadata":{"Phase":"Implementation","Description":"\n                  While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).\n                  Instead of building a new implementation, such features may be available in the database or programming language. For example, the Oracle DBMS_ASSERT package can check or enforce that parameters have certain properties that make them less vulnerable to SQL injection. For MySQL, the mysql_real_escape_string() API function is available in both C and PHP.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00247","_id":"cwe_mitigation/cwe_mitigation_00247","_rev":"_dVfOTTC--q","original_id":"89","name":"Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When constructing SQL query strings, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.\n                  Note that proper output encoding, escaping, and quoting is the most effective solution for preventing SQL injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent SQL injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, 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 handled. 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.\n                  When feasible, it may be safest to disallow meta-characters entirely, instead of escaping them. This will provide some defense in depth. After the data is entered into the database, later processes may neglect to escape meta-characters before use, and you may not have control over those processes.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00248","_id":"cwe_mitigation/cwe_mitigation_00248","_rev":"_dVfOTTC--r","original_id":"89","name":"Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","metadata":{"Phase":"Architecture and Design","Description":"When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00249","_id":"cwe_mitigation/cwe_mitigation_00249","_rev":"_dVfOTTC--s","original_id":"89","name":"Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","metadata":{"Phase":"Implementation","Description":"\n                  Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.\n                  If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.\n\t\t  Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.\n                  In the context of SQL Injection, error messages revealing the structure of a SQL query can help attackers tailor successful attack strings.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00250","_id":"cwe_mitigation/cwe_mitigation_00250","_rev":"_dVfOTTC--t","original_id":"89","name":"Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","metadata":{"Phase":"Operation","Description":"Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00251","_id":"cwe_mitigation/cwe_mitigation_00251","_rev":"_dVfOTTC--u","original_id":"89","name":"Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","metadata":{"Phase":"Operation","Description":"When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00261","_id":"cwe_mitigation/cwe_mitigation_00261","_rev":"_dVfOTTC--v","original_id":"90","name":"Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00262","_id":"cwe_mitigation/cwe_mitigation_00262","_rev":"_dVfOTTC--w","original_id":"91","name":"XML Injection (aka Blind XPath Injection)","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00263","_id":"cwe_mitigation/cwe_mitigation_00263","_rev":"_dVfOTTC--x","original_id":"93","name":"Improper Neutralization of CRLF Sequences ('CRLF Injection')","metadata":{"Phase":"Implementation","Description":"Avoid using CRLF as a special sequence."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00264","_id":"cwe_mitigation/cwe_mitigation_00264","_rev":"_dVfOTTC--y","original_id":"93","name":"Improper Neutralization of CRLF Sequences ('CRLF Injection')","metadata":{"Phase":"Implementation","Description":"Appropriately filter or quote CRLF sequences in user-controlled input."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00265","_id":"cwe_mitigation/cwe_mitigation_00265","_rev":"_dVfOTTC--z","original_id":"94","name":"Improper Control of Generation of Code ('Code Injection')","metadata":{"Phase":"Architecture and Design","Description":"Refactor your program so that you do not have to dynamically generate code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00266","_id":"cwe_mitigation/cwe_mitigation_00266","_rev":"_dVfOTTC--0","original_id":"94","name":"Improper Control of Generation of Code ('Code Injection')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run your code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your software.\n                  Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00267","_id":"cwe_mitigation/cwe_mitigation_00267","_rev":"_dVfOTTC--1","original_id":"94","name":"Improper Control of Generation of Code ('Code Injection')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00268","_id":"cwe_mitigation/cwe_mitigation_00268","_rev":"_dVfOTTC--2","original_id":"94","name":"Improper Control of Generation of Code ('Code Injection')","metadata":{"Phase":"Testing","Description":"Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00269","_id":"cwe_mitigation/cwe_mitigation_00269","_rev":"_dVfOTTC--3","original_id":"94","name":"Improper Control of Generation of Code ('Code Injection')","metadata":{"Phase":"Testing","Description":"Use dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00270","_id":"cwe_mitigation/cwe_mitigation_00270","_rev":"_dVfOTTC--4","original_id":"94","name":"Improper Control of Generation of Code ('Code Injection')","metadata":{"Phase":"Operation","Description":"Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's \"-T\" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00271","_id":"cwe_mitigation/cwe_mitigation_00271","_rev":"_dVfOTTC--5","original_id":"94","name":"Improper Control of Generation of Code ('Code Injection')","metadata":{"Phase":"Operation","Description":"Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's \"-T\" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00272","_id":"cwe_mitigation/cwe_mitigation_00272","_rev":"_dVfOTTC--6","original_id":"95","name":"Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')","metadata":{"Phase":"Architecture and Design","Description":"If possible, refactor your code so that it does not need to use eval() at all."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00273","_id":"cwe_mitigation/cwe_mitigation_00273","_rev":"_dVfOTTC--7","original_id":"95","name":"Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00274","_id":"cwe_mitigation/cwe_mitigation_00274","_rev":"_dVfOTTC--8","original_id":"95","name":"Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')","metadata":{"Phase":"Implementation","Description":"\n                  Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.\n                  Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00275","_id":"cwe_mitigation/cwe_mitigation_00275","_rev":"_dVfOTTC--9","original_id":"96","name":"Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00276","_id":"cwe_mitigation/cwe_mitigation_00276","_rev":"_dVfOTTC-_-","original_id":"96","name":"Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection')","metadata":{"Phase":"Implementation","Description":"Perform proper output validation and escaping to neutralize all code syntax from data written to code files."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00277","_id":"cwe_mitigation/cwe_mitigation_00277","_rev":"_dVfOTTG---","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Architecture and Design","Description":"Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00278","_id":"cwe_mitigation/cwe_mitigation_00278","_rev":"_dVfOTTG--_","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Architecture and Design","Description":"\n                  When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.\n                  For example, ID 1 could map to \"inbox.txt\" and ID 2 could map to \"profile.txt\". Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00279","_id":"cwe_mitigation/cwe_mitigation_00279","_rev":"_dVfOTTG--A","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00280","_id":"cwe_mitigation/cwe_mitigation_00280","_rev":"_dVfOTTG--B","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run the code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.\n                  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00281","_id":"cwe_mitigation/cwe_mitigation_00281","_rev":"_dVfOTTG--C","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00282","_id":"cwe_mitigation/cwe_mitigation_00282","_rev":"_dVfOTTG--D","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent lists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00283","_id":"cwe_mitigation/cwe_mitigation_00283","_rev":"_dVfOTTG--E","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.\n                  This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00284","_id":"cwe_mitigation/cwe_mitigation_00284","_rev":"_dVfOTTG--F","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.\n                  Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00285","_id":"cwe_mitigation/cwe_mitigation_00285","_rev":"_dVfOTTG--G","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Operation","Description":"Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00286","_id":"cwe_mitigation/cwe_mitigation_00286","_rev":"_dVfOTTG--H","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Operation","Description":"Develop and run your code in the most recent versions of PHP available, preferably PHP 6 or later. Many of the highly risky features in earlier PHP interpreters have been removed, restricted, or disabled by default."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00287","_id":"cwe_mitigation/cwe_mitigation_00287","_rev":"_dVfOTTG--I","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Operation","Description":"\n                  When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.\n                  Often, programmers do not protect direct access to files intended only to be included by core programs. These include files may assume that critical variables have already been initialized by the calling program. As a result, the use of register_globals combined with the ability to directly access the include file may allow attackers to conduct file inclusion attacks. This remains an extremely common pattern as of 2009.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00288","_id":"cwe_mitigation/cwe_mitigation_00288","_rev":"_dVfOTTG--J","original_id":"98","name":"Improper Control of Filename for Include/Require Statement in PHP Program ('PHP Remote File Inclusion')","metadata":{"Phase":"Operation","Description":"Set allow_url_fopen to false, which limits the ability to include files from remote locations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00291","_id":"cwe_mitigation/cwe_mitigation_00291","_rev":"_dVfOTTG--K","original_id":"99","name":"Improper Control of Resource Identifiers ('Resource Injection')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, it can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00292","_id":"cwe_mitigation/cwe_mitigation_00292","_rev":"_dVfOTTG--L","original_id":"102","name":"Struts: Duplicate Validation Forms","metadata":{"Phase":"Implementation","Description":"The DTD or schema validation will not catch the duplicate occurrence of the same form name. To find the issue in the implementation, manual checks or automated static analysis could be applied to the xml configuration files."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00293","_id":"cwe_mitigation/cwe_mitigation_00293","_rev":"_dVfOTTG--M","original_id":"103","name":"Struts: Incomplete validate() Method Definition","metadata":{"Phase":"Implementation","Description":"Implement the validate() method and call super.validate() within that method."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00294","_id":"cwe_mitigation/cwe_mitigation_00294","_rev":"_dVfOTTG--N","original_id":"104","name":"Struts: Form Bean Does Not Extend Validation Class","metadata":{"Phase":"Implementation","Description":"Ensure that all forms extend one of the Validation Classes."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00295","_id":"cwe_mitigation/cwe_mitigation_00295","_rev":"_dVfOTTG--O","original_id":"105","name":"Struts: Form Field Without Validator","metadata":{"Phase":"Implementation","Description":"Validate all form fields. If a field is unused, it is still important to constrain it so that it is empty or undefined."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00296","_id":"cwe_mitigation/cwe_mitigation_00296","_rev":"_dVfOTTG--P","original_id":"106","name":"Struts: Plug-in Framework not in Use","metadata":{"Phase":"Architecture and Design","Description":"Use an input validation framework such as Struts."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00297","_id":"cwe_mitigation/cwe_mitigation_00297","_rev":"_dVfOTTG--Q","original_id":"106","name":"Struts: Plug-in Framework not in Use","metadata":{"Phase":"Architecture and Design","Description":"Use an input validation framework such as Struts."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00298","_id":"cwe_mitigation/cwe_mitigation_00298","_rev":"_dVfOTTG--R","original_id":"106","name":"Struts: Plug-in Framework not in Use","metadata":{"Phase":"Implementation","Description":"\n                  Use the Struts Validator to validate all program input before it is processed by the application. Ensure that there are no holes in the configuration of the Struts Validator. Example uses of the validator include checking to ensure that:\n                  \n                     \n                        Phone number fields contain only valid characters in phone numbers\n                        Boolean values are only \"T\" or \"F\"\n                        Free-form strings are of a reasonable length and composition\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00299","_id":"cwe_mitigation/cwe_mitigation_00299","_rev":"_dVfOTTG--S","original_id":"106","name":"Struts: Plug-in Framework not in Use","metadata":{"Phase":"Implementation","Description":"\n                  Use the Struts Validator to validate all program input before it is processed by the application. Ensure that there are no holes in the configuration of the Struts Validator. Example uses of the validator include checking to ensure that:\n                  \n                     \n                        Phone number fields contain only valid characters in phone numbers\n                        Boolean values are only \"T\" or \"F\"\n                        Free-form strings are of a reasonable length and composition\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00300","_id":"cwe_mitigation/cwe_mitigation_00300","_rev":"_dVfOTTG--T","original_id":"107","name":"Struts: Unused Validation Form","metadata":{"Phase":"Implementation","Description":"Remove the unused Validation Form from the validation.xml file."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00301","_id":"cwe_mitigation/cwe_mitigation_00301","_rev":"_dVfOTTG--U","original_id":"108","name":"Struts: Unvalidated Action Form","metadata":{"Phase":"Implementation","Description":"\n                  Map every Action Form to a corresponding validation form.\n                  An action or a form may perform validation in other ways, but the Struts Validator provides an excellent way to verify that all input receives at least a basic level of validation. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00302","_id":"cwe_mitigation/cwe_mitigation_00302","_rev":"_dVfOTTG--V","original_id":"109","name":"Struts: Validator Turned Off","metadata":{"Phase":"Implementation","Description":"Ensure that an action form mapping enables validation. Set the validate field to true."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00305","_id":"cwe_mitigation/cwe_mitigation_00305","_rev":"_dVfOTTG--W","original_id":"111","name":"Direct Use of Unsafe JNI","metadata":{"Phase":"Implementation","Description":"Implement error handling around the JNI call."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00306","_id":"cwe_mitigation/cwe_mitigation_00306","_rev":"_dVfOTTG--X","original_id":"111","name":"Direct Use of Unsafe JNI","metadata":{"Phase":"Implementation","Description":"Do not use JNI calls if you don't trust the native library."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00307","_id":"cwe_mitigation/cwe_mitigation_00307","_rev":"_dVfOTTG--Y","original_id":"111","name":"Direct Use of Unsafe JNI","metadata":{"Phase":"Implementation","Description":"Be reluctant to use JNI calls. A Java API equivalent may exist."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00308","_id":"cwe_mitigation/cwe_mitigation_00308","_rev":"_dVfOTTG--Z","original_id":"112","name":"Missing XML Validation","metadata":{"Phase":"Architecture and Design","Description":"\n                  Always validate XML input against a known XML Schema or DTD.\n                  It is not possible for an XML parser to validate all aspects of a document's content because a parser cannot understand the complete semantics of the data. However, a parser can do a complete and thorough job of checking the document's structure and therefore guarantee to the code that processes the document that the content is well-formed.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00309","_id":"cwe_mitigation/cwe_mitigation_00309","_rev":"_dVfOTTG--a","original_id":"113","name":"Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')","metadata":{"Phase":"Implementation","Description":"Construct HTTP headers very carefully, avoiding the use of non-validated input data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00310","_id":"cwe_mitigation/cwe_mitigation_00310","_rev":"_dVfOTTG--b","original_id":"113","name":"Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00311","_id":"cwe_mitigation/cwe_mitigation_00311","_rev":"_dVfOTTG--c","original_id":"113","name":"Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')","metadata":{"Phase":"Implementation","Description":"Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00312","_id":"cwe_mitigation/cwe_mitigation_00312","_rev":"_dVfOTTG--d","original_id":"113","name":"Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00313","_id":"cwe_mitigation/cwe_mitigation_00313","_rev":"_dVfOTTG--e","original_id":"114","name":"Process Control","metadata":{"Phase":"Architecture and Design","Description":"Libraries that are loaded should be well understood and come from a trusted source. The application can execute code contained in the native libraries, which often contain calls that are susceptible to other security problems, such as buffer overflows or command injection. All native libraries should be validated to determine if the application requires the use of the library. It is very difficult to determine what these native libraries actually do, and the potential for malicious code is high. In addition, the potential for an inadvertent mistake in these native libraries is also high, as many are written in C or C++ and may be susceptible to buffer overflow or race condition problems. To help prevent buffer overflow attacks, validate all input to native calls for content and length. If the native library does not come from a trusted source, review the source code of the library. The library should be built from the reviewed source before using it."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00314","_id":"cwe_mitigation/cwe_mitigation_00314","_rev":"_dVfOTTG--f","original_id":"116","name":"Improper Encoding or Escaping of Output","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.\n                  Alternately, use built-in functions, but consider using wrappers in case those functions are discovered to have a vulnerability.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00315","_id":"cwe_mitigation/cwe_mitigation_00315","_rev":"_dVfOTTG--g","original_id":"116","name":"Improper Encoding or Escaping of Output","metadata":{"Phase":"Architecture and Design","Description":"\n                  If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.\n                  For example, stored procedures can enforce database query structure and reduce the likelihood of SQL injection.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00316","_id":"cwe_mitigation/cwe_mitigation_00316","_rev":"_dVfOTTG--h","original_id":"116","name":"Improper Encoding or Escaping of Output","metadata":{"Phase":"Architecture and Design","Description":"Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00317","_id":"cwe_mitigation/cwe_mitigation_00317","_rev":"_dVfOTTG--i","original_id":"116","name":"Improper Encoding or Escaping of Output","metadata":{"Phase":"Architecture and Design","Description":"In some cases, input validation may be an important strategy when output encoding is not a complete solution. For example, you may be providing the same output that will be processed by multiple consumers that use different encodings or representations. In other cases, you may be required to allow user-supplied input to contain control information, such as limited HTML tags that support formatting in a wiki or bulletin board. When this type of requirement must be met, use an extremely strict allowlist to limit which control sequences can be used. Verify that the resulting syntactic structure is what you expect. Use your normal encoding methods for the remainder of the input."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00318","_id":"cwe_mitigation/cwe_mitigation_00318","_rev":"_dVfOTTG--j","original_id":"116","name":"Improper Encoding or Escaping of Output","metadata":{"Phase":"Architecture and Design","Description":"Use input validation as a defense-in-depth measure to reduce the likelihood of output encoding errors (see CWE-20)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00319","_id":"cwe_mitigation/cwe_mitigation_00319","_rev":"_dVfOTTG--k","original_id":"116","name":"Improper Encoding or Escaping of Output","metadata":{"Phase":"Requirements","Description":"Fully specify which encodings are required by components that will be communicating with each other."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00320","_id":"cwe_mitigation/cwe_mitigation_00320","_rev":"_dVfOTTG--l","original_id":"116","name":"Improper Encoding or Escaping of Output","metadata":{"Phase":"Implementation","Description":"When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00323","_id":"cwe_mitigation/cwe_mitigation_00323","_rev":"_dVfOTTG--m","original_id":"117","name":"Improper Output Neutralization for Logs","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00324","_id":"cwe_mitigation/cwe_mitigation_00324","_rev":"_dVfOTTG--n","original_id":"117","name":"Improper Output Neutralization for Logs","metadata":{"Phase":"Implementation","Description":"Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00325","_id":"cwe_mitigation/cwe_mitigation_00325","_rev":"_dVfOTTG--o","original_id":"117","name":"Improper Output Neutralization for Logs","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00326","_id":"cwe_mitigation/cwe_mitigation_00326","_rev":"_dVfOTTG--p","original_id":"119","name":"Improper Restriction of Operations within the Bounds of a Memory Buffer","metadata":{"Phase":"Requirements","Description":"\n                  Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.\n                  Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00327","_id":"cwe_mitigation/cwe_mitigation_00327","_rev":"_dVfOTTG--q","original_id":"119","name":"Improper Restriction of Operations within the Bounds of a Memory Buffer","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00328","_id":"cwe_mitigation/cwe_mitigation_00328","_rev":"_dVfOTTG--r","original_id":"119","name":"Improper Restriction of Operations within the Bounds of a Memory Buffer","metadata":{"Phase":"Build and Compilation","Description":"\n                  Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.\n                  For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00329","_id":"cwe_mitigation/cwe_mitigation_00329","_rev":"_dVfOTTG--s","original_id":"119","name":"Improper Restriction of Operations within the Bounds of a Memory Buffer","metadata":{"Phase":"Implementation","Description":"\n                  Consider adhering to the following rules when allocating and managing an application's memory:\n                  \n                     \n                        Double check that the buffer is as large as specified.\n                        When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.\n                        Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.\n                        If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00330","_id":"cwe_mitigation/cwe_mitigation_00330","_rev":"_dVfOTTG--t","original_id":"119","name":"Improper Restriction of Operations within the Bounds of a Memory Buffer","metadata":{"Phase":"Operation","Description":"\n                  Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.\n                  Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64].\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00331","_id":"cwe_mitigation/cwe_mitigation_00331","_rev":"_dVfOTTG--u","original_id":"119","name":"Improper Restriction of Operations within the Bounds of a Memory Buffer","metadata":{"Phase":"Operation","Description":"Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-60] [REF-61]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00332","_id":"cwe_mitigation/cwe_mitigation_00332","_rev":"_dVfOTTG--v","original_id":"119","name":"Improper Restriction of Operations within the Bounds of a Memory Buffer","metadata":{"Phase":"Implementation","Description":"Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00342","_id":"cwe_mitigation/cwe_mitigation_00342","_rev":"_dVfOTTG--w","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Requirements","Description":"\n                  Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.\n                  Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00343","_id":"cwe_mitigation/cwe_mitigation_00343","_rev":"_dVfOTTG--x","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00344","_id":"cwe_mitigation/cwe_mitigation_00344","_rev":"_dVfOTTG--y","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Build and Compilation","Description":"\n                  Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.\n                  For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00345","_id":"cwe_mitigation/cwe_mitigation_00345","_rev":"_dVfOTTG--z","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Implementation","Description":"\n                  Consider adhering to the following rules when allocating and managing an application's memory:\n                  \n                     \n                        Double check that your buffer is as large as you specify.\n                        When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.\n                        Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.\n                        If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00346","_id":"cwe_mitigation/cwe_mitigation_00346","_rev":"_dVfOTTG--0","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00347","_id":"cwe_mitigation/cwe_mitigation_00347","_rev":"_dVfOTTG--1","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00348","_id":"cwe_mitigation/cwe_mitigation_00348","_rev":"_dVfOTTG--2","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Operation","Description":"\n                  Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.\n                  Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64].\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00349","_id":"cwe_mitigation/cwe_mitigation_00349","_rev":"_dVfOTTG--3","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Operation","Description":"Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-60] [REF-61]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00350","_id":"cwe_mitigation/cwe_mitigation_00350","_rev":"_dVfOTTG--4","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Build and Compilation","Description":"Most mitigating technologies at the compiler or OS level to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is good practice to implement strategies to increase the workload of an attacker, such as leaving the attacker to guess an unknown value that changes every program execution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00351","_id":"cwe_mitigation/cwe_mitigation_00351","_rev":"_dVfOTTG--5","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Implementation","Description":"Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00352","_id":"cwe_mitigation/cwe_mitigation_00352","_rev":"_dVfOTTG--6","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Architecture and Design","Description":"When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00353","_id":"cwe_mitigation/cwe_mitigation_00353","_rev":"_dVfOTTG--7","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00354","_id":"cwe_mitigation/cwe_mitigation_00354","_rev":"_dVfOTTG--8","original_id":"120","name":"Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run the code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.\n                  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00365","_id":"cwe_mitigation/cwe_mitigation_00365","_rev":"_dVfOTTG--9","original_id":"121","name":"Stack-based Buffer Overflow","metadata":{"Phase":"Build and Compilation","Description":"\n                  Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.\n                  For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00366","_id":"cwe_mitigation/cwe_mitigation_00366","_rev":"_dVfOTTG-_-","original_id":"121","name":"Stack-based Buffer Overflow","metadata":{"Phase":"Architecture and Design","Description":"Use an abstraction library to abstract away risky APIs. Not a complete solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00367","_id":"cwe_mitigation/cwe_mitigation_00367","_rev":"_dVfOTTG-__","original_id":"121","name":"Stack-based Buffer Overflow","metadata":{"Phase":"Build and Compilation","Description":"Compiler-based canary mechanisms such as StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. Unless this provides automatic bounds checking, it is not a complete solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00368","_id":"cwe_mitigation/cwe_mitigation_00368","_rev":"_dVfOTTG-_A","original_id":"121","name":"Stack-based Buffer Overflow","metadata":{"Phase":"Implementation","Description":"Implement and perform bounds checking on input."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00369","_id":"cwe_mitigation/cwe_mitigation_00369","_rev":"_dVfOTTG-_B","original_id":"121","name":"Stack-based Buffer Overflow","metadata":{"Phase":"Implementation","Description":"Do not use dangerous functions such as gets. Use safer, equivalent functions which check for boundary errors."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00370","_id":"cwe_mitigation/cwe_mitigation_00370","_rev":"_dVfOTTG-_C","original_id":"121","name":"Stack-based Buffer Overflow","metadata":{"Phase":"Operation","Description":"Use OS-level preventative functionality, such as ASLR. This is not a complete solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00371","_id":"cwe_mitigation/cwe_mitigation_00371","_rev":"_dVfOTTG-_D","original_id":"122","name":"Heap-based Buffer Overflow","metadata":{"Phase":"NA","Description":"Pre-design: Use a language or compiler that performs automatic bounds checking."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00372","_id":"cwe_mitigation/cwe_mitigation_00372","_rev":"_dVfOTTK---","original_id":"122","name":"Heap-based Buffer Overflow","metadata":{"Phase":"Architecture and Design","Description":"Use an abstraction library to abstract away risky APIs. Not a complete solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00373","_id":"cwe_mitigation/cwe_mitigation_00373","_rev":"_dVfOTTK--_","original_id":"122","name":"Heap-based Buffer Overflow","metadata":{"Phase":"Build and Compilation","Description":"Pre-design through Build: Canary style bounds checking, library changes which ensure the validity of chunk data, and other such fixes are possible, but should not be relied upon."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00374","_id":"cwe_mitigation/cwe_mitigation_00374","_rev":"_dVfOTTK--A","original_id":"122","name":"Heap-based Buffer Overflow","metadata":{"Phase":"Implementation","Description":"Implement and perform bounds checking on input."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00375","_id":"cwe_mitigation/cwe_mitigation_00375","_rev":"_dVfOTTK--B","original_id":"122","name":"Heap-based Buffer Overflow","metadata":{"Phase":"Implementation","Description":"Do not use dangerous functions such as gets. Look for their safe equivalent, which checks for the boundary."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00376","_id":"cwe_mitigation/cwe_mitigation_00376","_rev":"_dVfOTTK--C","original_id":"122","name":"Heap-based Buffer Overflow","metadata":{"Phase":"Operation","Description":"Use OS-level preventative functionality. This is not a complete solution, but it provides some defense in depth."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00377","_id":"cwe_mitigation/cwe_mitigation_00377","_rev":"_dVfOTTK--D","original_id":"123","name":"Write-what-where Condition","metadata":{"Phase":"Architecture and Design","Description":"Use a language that provides appropriate memory abstractions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00378","_id":"cwe_mitigation/cwe_mitigation_00378","_rev":"_dVfOTTK--E","original_id":"123","name":"Write-what-where Condition","metadata":{"Phase":"Operation","Description":"Use OS-level preventative functionality integrated after the fact. Not a complete solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00379","_id":"cwe_mitigation/cwe_mitigation_00379","_rev":"_dVfOTTK--F","original_id":"124","name":"Buffer Underwrite ('Buffer Underflow')","metadata":{"Phase":"Requirements","Description":"Choose a language that is not susceptible to these issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00380","_id":"cwe_mitigation/cwe_mitigation_00380","_rev":"_dVfOTTK--G","original_id":"124","name":"Buffer Underwrite ('Buffer Underflow')","metadata":{"Phase":"Implementation","Description":"All calculated values that are used as index or for pointer arithmetic should be validated to ensure that they are within an expected range."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00381","_id":"cwe_mitigation/cwe_mitigation_00381","_rev":"_dVfOTTK--H","original_id":"125","name":"Out-of-bounds Read","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00382","_id":"cwe_mitigation/cwe_mitigation_00382","_rev":"_dVfOTTK--I","original_id":"125","name":"Out-of-bounds Read","metadata":{"Phase":"Architecture and Design","Description":"Use a language that provides appropriate memory abstractions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00383","_id":"cwe_mitigation/cwe_mitigation_00383","_rev":"_dVfOTTK--J","original_id":"128","name":"Wrap-around Error","metadata":{"Phase":"NA","Description":"Requirements specification: The choice could be made to use a language that is not susceptible to these issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00384","_id":"cwe_mitigation/cwe_mitigation_00384","_rev":"_dVfOTTK--K","original_id":"128","name":"Wrap-around Error","metadata":{"Phase":"Architecture and Design","Description":"Provide clear upper and lower bounds on the scale of any protocols designed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00385","_id":"cwe_mitigation/cwe_mitigation_00385","_rev":"_dVfOTTK--L","original_id":"128","name":"Wrap-around Error","metadata":{"Phase":"Implementation","Description":"Perform validation on all incremented variables to ensure that they remain within reasonable bounds."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00386","_id":"cwe_mitigation/cwe_mitigation_00386","_rev":"_dVfOTTK--M","original_id":"129","name":"Improper Validation of Array Index","metadata":{"Phase":"Architecture and Design","Description":"Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00387","_id":"cwe_mitigation/cwe_mitigation_00387","_rev":"_dVfOTTK--N","original_id":"129","name":"Improper Validation of Array Index","metadata":{"Phase":"Architecture and Design","Description":"\n                  For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.\n                  Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00388","_id":"cwe_mitigation/cwe_mitigation_00388","_rev":"_dVfOTTK--O","original_id":"129","name":"Improper Validation of Array Index","metadata":{"Phase":"Requirements","Description":"\n                  Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, Ada allows the programmer to constrain the values of a variable and languages such as Java and Ruby will allow the programmer to handle exceptions when an out-of-bounds index is accessed.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00389","_id":"cwe_mitigation/cwe_mitigation_00389","_rev":"_dVfOTTK--P","original_id":"129","name":"Improper Validation of Array Index","metadata":{"Phase":"Operation","Description":"\n                  Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.\n                  Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64].\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00390","_id":"cwe_mitigation/cwe_mitigation_00390","_rev":"_dVfOTTK--Q","original_id":"129","name":"Improper Validation of Array Index","metadata":{"Phase":"Operation","Description":"Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-60] [REF-61]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00391","_id":"cwe_mitigation/cwe_mitigation_00391","_rev":"_dVfOTTK--R","original_id":"129","name":"Improper Validation of Array Index","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When accessing a user-controlled array index, use a stringent range of values that are within the target array. Make sure that you do not allow negative values to be used. That is, verify the minimum as well as the maximum of the range of acceptable values.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00392","_id":"cwe_mitigation/cwe_mitigation_00392","_rev":"_dVfOTTK--S","original_id":"129","name":"Improper Validation of Array Index","metadata":{"Phase":"Implementation","Description":"Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00393","_id":"cwe_mitigation/cwe_mitigation_00393","_rev":"_dVfOTTK--T","original_id":"129","name":"Improper Validation of Array Index","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00394","_id":"cwe_mitigation/cwe_mitigation_00394","_rev":"_dVfOTTK--U","original_id":"129","name":"Improper Validation of Array Index","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run the code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.\n                  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00398","_id":"cwe_mitigation/cwe_mitigation_00398","_rev":"_dVfOTTK--V","original_id":"130","name":"Improper Handling of Length Parameter Inconsistency","metadata":{"Phase":"Implementation","Description":"When processing structured incoming data containing a size field followed by raw data, ensure that you identify and resolve any inconsistencies between the size field and the actual size of the data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00399","_id":"cwe_mitigation/cwe_mitigation_00399","_rev":"_dVfOTTK--W","original_id":"130","name":"Improper Handling of Length Parameter Inconsistency","metadata":{"Phase":"Implementation","Description":"Do not let the user control the size of the buffer."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00400","_id":"cwe_mitigation/cwe_mitigation_00400","_rev":"_dVfOTTK--X","original_id":"130","name":"Improper Handling of Length Parameter Inconsistency","metadata":{"Phase":"Implementation","Description":"Validate that the length of the user-supplied data is consistent with the buffer size."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00401","_id":"cwe_mitigation/cwe_mitigation_00401","_rev":"_dVfOTTK--Y","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Implementation","Description":"When allocating a buffer for the purpose of transforming, converting, or encoding an input, allocate enough memory to handle the largest possible encoding. For example, in a routine that converts \"&\" characters to \"&amp;\" for HTML entity encoding, the output buffer needs to be at least 5 times as large as the input buffer."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00402","_id":"cwe_mitigation/cwe_mitigation_00402","_rev":"_dVfOTTK--Z","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Implementation","Description":"\n                  Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, \"not-a-number\" calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]\n                  Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00403","_id":"cwe_mitigation/cwe_mitigation_00403","_rev":"_dVfOTTK--a","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Implementation","Description":"Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00404","_id":"cwe_mitigation/cwe_mitigation_00404","_rev":"_dVfOTTK--b","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00405","_id":"cwe_mitigation/cwe_mitigation_00405","_rev":"_dVfOTTK--c","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Implementation","Description":"When processing structured incoming data containing a size field followed by raw data, identify and resolve any inconsistencies between the size field and the actual size of the data (CWE-130)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00406","_id":"cwe_mitigation/cwe_mitigation_00406","_rev":"_dVfOTTK--d","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Implementation","Description":"When allocating memory that uses sentinels to mark the end of a data structure - such as NUL bytes in strings - make sure you also include the sentinel in your calculation of the total amount of memory that must be allocated."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00407","_id":"cwe_mitigation/cwe_mitigation_00407","_rev":"_dVfOTTK--e","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Implementation","Description":"Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00408","_id":"cwe_mitigation/cwe_mitigation_00408","_rev":"_dVfOTTK--f","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Implementation","Description":"Use sizeof() on the appropriate data type to avoid CWE-467."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00409","_id":"cwe_mitigation/cwe_mitigation_00409","_rev":"_dVfOTTK--g","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Implementation","Description":"Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity. This will simplify validation and will reduce surprises related to unexpected casting."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00410","_id":"cwe_mitigation/cwe_mitigation_00410","_rev":"_dVfOTTK--h","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  Use libraries or frameworks that make it easier to handle numbers without unexpected consequences, or buffer allocation routines that automatically track buffer size.\n                  Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00411","_id":"cwe_mitigation/cwe_mitigation_00411","_rev":"_dVfOTTK--i","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Build and Compilation","Description":"\n                  Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.\n                  For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00412","_id":"cwe_mitigation/cwe_mitigation_00412","_rev":"_dVfOTTK--j","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Operation","Description":"\n                  Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.\n                  Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64].\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00413","_id":"cwe_mitigation/cwe_mitigation_00413","_rev":"_dVfOTTK--k","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Operation","Description":"Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-61] [REF-60]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00414","_id":"cwe_mitigation/cwe_mitigation_00414","_rev":"_dVfOTTK--l","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Implementation","Description":"Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00415","_id":"cwe_mitigation/cwe_mitigation_00415","_rev":"_dVfOTTK--m","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00416","_id":"cwe_mitigation/cwe_mitigation_00416","_rev":"_dVfOTTK--n","original_id":"131","name":"Incorrect Calculation of Buffer Size","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run the code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.\n                  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00426","_id":"cwe_mitigation/cwe_mitigation_00426","_rev":"_dVfOTTK--o","original_id":"134","name":"Use of Externally-Controlled Format String","metadata":{"Phase":"Requirements","Description":"Choose a language that is not subject to this flaw."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00427","_id":"cwe_mitigation/cwe_mitigation_00427","_rev":"_dVfOTTK--p","original_id":"134","name":"Use of Externally-Controlled Format String","metadata":{"Phase":"Implementation","Description":"Ensure that all format string functions are passed a static string which cannot be controlled by the user, and that the proper number of arguments are always sent to that function as well. If at all possible, use functions that do not support the %n operator in format strings. [REF-116] [REF-117]"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00428","_id":"cwe_mitigation/cwe_mitigation_00428","_rev":"_dVfOTTK--q","original_id":"134","name":"Use of Externally-Controlled Format String","metadata":{"Phase":"Build and Compilation","Description":"Run compilers and linkers with high warning levels, since they may detect incorrect usage."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00438","_id":"cwe_mitigation/cwe_mitigation_00438","_rev":"_dVfOTTK--r","original_id":"135","name":"Incorrect Calculation of Multi-Byte String Length","metadata":{"Phase":"Implementation","Description":"Always verify the length of the string unit character."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00439","_id":"cwe_mitigation/cwe_mitigation_00439","_rev":"_dVfOTTK--s","original_id":"135","name":"Incorrect Calculation of Multi-Byte String Length","metadata":{"Phase":"Implementation","Description":"Use length computing functions (e.g. strlen, wcslen, etc.) appropriately with their equivalent type (e.g.: byte, wchar_t, etc.)"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00440","_id":"cwe_mitigation/cwe_mitigation_00440","_rev":"_dVfOTTK--t","original_id":"138","name":"Improper Neutralization of Special Elements","metadata":{"Phase":"Implementation","Description":"Developers should anticipate that special elements (e.g. delimiters, symbols) will be injected into input vectors of their software system. One defense is to create an allowlist (e.g. a regular expression) that defines valid input according to the requirements specifications. Strictly filter any input that does not match against the allowlist. Properly encode your output, and quote any elements that have special meaning to the component with which you are communicating."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00441","_id":"cwe_mitigation/cwe_mitigation_00441","_rev":"_dVfOTTK--u","original_id":"138","name":"Improper Neutralization of Special Elements","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00442","_id":"cwe_mitigation/cwe_mitigation_00442","_rev":"_dVfOTTK--v","original_id":"138","name":"Improper Neutralization of Special Elements","metadata":{"Phase":"Implementation","Description":"Use and specify an appropriate output encoding to ensure that the special elements are well-defined. A normal byte sequence in one encoding could be a special element in another."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00443","_id":"cwe_mitigation/cwe_mitigation_00443","_rev":"_dVfOTTK--w","original_id":"138","name":"Improper Neutralization of Special Elements","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00444","_id":"cwe_mitigation/cwe_mitigation_00444","_rev":"_dVfOTTK--x","original_id":"138","name":"Improper Neutralization of Special Elements","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00445","_id":"cwe_mitigation/cwe_mitigation_00445","_rev":"_dVfOTTK--y","original_id":"140","name":"Improper Neutralization of Delimiters","metadata":{"Phase":"Implementation","Description":"Developers should anticipate that delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00446","_id":"cwe_mitigation/cwe_mitigation_00446","_rev":"_dVfOTTK--z","original_id":"140","name":"Improper Neutralization of Delimiters","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00447","_id":"cwe_mitigation/cwe_mitigation_00447","_rev":"_dVfOTTK--0","original_id":"140","name":"Improper Neutralization of Delimiters","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00448","_id":"cwe_mitigation/cwe_mitigation_00448","_rev":"_dVfOTTK--1","original_id":"140","name":"Improper Neutralization of Delimiters","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00449","_id":"cwe_mitigation/cwe_mitigation_00449","_rev":"_dVfOTTK--2","original_id":"141","name":"Improper Neutralization of Parameter/Argument Delimiters","metadata":{"Phase":"NA","Description":"Developers should anticipate that parameter/argument delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00450","_id":"cwe_mitigation/cwe_mitigation_00450","_rev":"_dVfOTTK--3","original_id":"141","name":"Improper Neutralization of Parameter/Argument Delimiters","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00451","_id":"cwe_mitigation/cwe_mitigation_00451","_rev":"_dVfOTTK--4","original_id":"141","name":"Improper Neutralization of Parameter/Argument Delimiters","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00452","_id":"cwe_mitigation/cwe_mitigation_00452","_rev":"_dVfOTTK--5","original_id":"141","name":"Improper Neutralization of Parameter/Argument Delimiters","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00453","_id":"cwe_mitigation/cwe_mitigation_00453","_rev":"_dVfOTTK--6","original_id":"142","name":"Improper Neutralization of Value Delimiters","metadata":{"Phase":"NA","Description":"Developers should anticipate that value delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00454","_id":"cwe_mitigation/cwe_mitigation_00454","_rev":"_dVfOTTK--7","original_id":"142","name":"Improper Neutralization of Value Delimiters","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00455","_id":"cwe_mitigation/cwe_mitigation_00455","_rev":"_dVfOTTK--8","original_id":"142","name":"Improper Neutralization of Value Delimiters","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00456","_id":"cwe_mitigation/cwe_mitigation_00456","_rev":"_dVfOTTK--9","original_id":"142","name":"Improper Neutralization of Value Delimiters","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00457","_id":"cwe_mitigation/cwe_mitigation_00457","_rev":"_dVfOTTK-_-","original_id":"143","name":"Improper Neutralization of Record Delimiters","metadata":{"Phase":"NA","Description":"Developers should anticipate that record delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00458","_id":"cwe_mitigation/cwe_mitigation_00458","_rev":"_dVfOTTK-__","original_id":"143","name":"Improper Neutralization of Record Delimiters","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00459","_id":"cwe_mitigation/cwe_mitigation_00459","_rev":"_dVfOTTK-_A","original_id":"143","name":"Improper Neutralization of Record Delimiters","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00460","_id":"cwe_mitigation/cwe_mitigation_00460","_rev":"_dVfOTTO---","original_id":"143","name":"Improper Neutralization of Record Delimiters","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00461","_id":"cwe_mitigation/cwe_mitigation_00461","_rev":"_dVfOTTO--_","original_id":"144","name":"Improper Neutralization of Line Delimiters","metadata":{"Phase":"NA","Description":"Developers should anticipate that line delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00462","_id":"cwe_mitigation/cwe_mitigation_00462","_rev":"_dVfOTTO--A","original_id":"144","name":"Improper Neutralization of Line Delimiters","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00463","_id":"cwe_mitigation/cwe_mitigation_00463","_rev":"_dVfOTTO--B","original_id":"144","name":"Improper Neutralization of Line Delimiters","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00464","_id":"cwe_mitigation/cwe_mitigation_00464","_rev":"_dVfOTTO--C","original_id":"144","name":"Improper Neutralization of Line Delimiters","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00465","_id":"cwe_mitigation/cwe_mitigation_00465","_rev":"_dVfOTTO--D","original_id":"145","name":"Improper Neutralization of Section Delimiters","metadata":{"Phase":"NA","Description":"Developers should anticipate that section delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00466","_id":"cwe_mitigation/cwe_mitigation_00466","_rev":"_dVfOTTO--E","original_id":"145","name":"Improper Neutralization of Section Delimiters","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00467","_id":"cwe_mitigation/cwe_mitigation_00467","_rev":"_dVfOTTO--F","original_id":"145","name":"Improper Neutralization of Section Delimiters","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00468","_id":"cwe_mitigation/cwe_mitigation_00468","_rev":"_dVfOTTO--G","original_id":"145","name":"Improper Neutralization of Section Delimiters","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00469","_id":"cwe_mitigation/cwe_mitigation_00469","_rev":"_dVfOTTO--H","original_id":"146","name":"Improper Neutralization of Expression/Command Delimiters","metadata":{"Phase":"NA","Description":"Developers should anticipate that inter-expression and inter-command delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00470","_id":"cwe_mitigation/cwe_mitigation_00470","_rev":"_dVfOTTO--I","original_id":"146","name":"Improper Neutralization of Expression/Command Delimiters","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00471","_id":"cwe_mitigation/cwe_mitigation_00471","_rev":"_dVfOTTO--J","original_id":"146","name":"Improper Neutralization of Expression/Command Delimiters","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00472","_id":"cwe_mitigation/cwe_mitigation_00472","_rev":"_dVfOTTO--K","original_id":"146","name":"Improper Neutralization of Expression/Command Delimiters","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00473","_id":"cwe_mitigation/cwe_mitigation_00473","_rev":"_dVfOTTO--L","original_id":"147","name":"Improper Neutralization of Input Terminators","metadata":{"Phase":"NA","Description":"Developers should anticipate that terminators will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00474","_id":"cwe_mitigation/cwe_mitigation_00474","_rev":"_dVfOTTO--M","original_id":"147","name":"Improper Neutralization of Input Terminators","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00475","_id":"cwe_mitigation/cwe_mitigation_00475","_rev":"_dVfOTTO--N","original_id":"147","name":"Improper Neutralization of Input Terminators","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00476","_id":"cwe_mitigation/cwe_mitigation_00476","_rev":"_dVfOTTO--O","original_id":"147","name":"Improper Neutralization of Input Terminators","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00477","_id":"cwe_mitigation/cwe_mitigation_00477","_rev":"_dVfOTTO--P","original_id":"148","name":"Improper Neutralization of Input Leaders","metadata":{"Phase":"NA","Description":"Developers should anticipate that leading characters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00478","_id":"cwe_mitigation/cwe_mitigation_00478","_rev":"_dVfOTTO--Q","original_id":"148","name":"Improper Neutralization of Input Leaders","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00479","_id":"cwe_mitigation/cwe_mitigation_00479","_rev":"_dVfOTTO--R","original_id":"148","name":"Improper Neutralization of Input Leaders","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00480","_id":"cwe_mitigation/cwe_mitigation_00480","_rev":"_dVfOTTO--S","original_id":"148","name":"Improper Neutralization of Input Leaders","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00481","_id":"cwe_mitigation/cwe_mitigation_00481","_rev":"_dVfOTTO--T","original_id":"149","name":"Improper Neutralization of Quoting Syntax","metadata":{"Phase":"NA","Description":"Developers should anticipate that quotes will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00482","_id":"cwe_mitigation/cwe_mitigation_00482","_rev":"_dVfOTTO--U","original_id":"149","name":"Improper Neutralization of Quoting Syntax","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00483","_id":"cwe_mitigation/cwe_mitigation_00483","_rev":"_dVfOTTO--V","original_id":"149","name":"Improper Neutralization of Quoting Syntax","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00484","_id":"cwe_mitigation/cwe_mitigation_00484","_rev":"_dVfOTTO--W","original_id":"149","name":"Improper Neutralization of Quoting Syntax","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00485","_id":"cwe_mitigation/cwe_mitigation_00485","_rev":"_dVfOTTO--X","original_id":"150","name":"Improper Neutralization of Escape, Meta, or Control Sequences","metadata":{"Phase":"NA","Description":"Developers should anticipate that escape, meta and control characters/sequences will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00486","_id":"cwe_mitigation/cwe_mitigation_00486","_rev":"_dVfOTTO--Y","original_id":"150","name":"Improper Neutralization of Escape, Meta, or Control Sequences","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00487","_id":"cwe_mitigation/cwe_mitigation_00487","_rev":"_dVfOTTO--Z","original_id":"150","name":"Improper Neutralization of Escape, Meta, or Control Sequences","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00488","_id":"cwe_mitigation/cwe_mitigation_00488","_rev":"_dVfOTTO--a","original_id":"150","name":"Improper Neutralization of Escape, Meta, or Control Sequences","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00489","_id":"cwe_mitigation/cwe_mitigation_00489","_rev":"_dVfOTTO--b","original_id":"151","name":"Improper Neutralization of Comment Delimiters","metadata":{"Phase":"NA","Description":"Developers should anticipate that comments will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00490","_id":"cwe_mitigation/cwe_mitigation_00490","_rev":"_dVfOTTO--c","original_id":"151","name":"Improper Neutralization of Comment Delimiters","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00491","_id":"cwe_mitigation/cwe_mitigation_00491","_rev":"_dVfOTTO--d","original_id":"151","name":"Improper Neutralization of Comment Delimiters","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00492","_id":"cwe_mitigation/cwe_mitigation_00492","_rev":"_dVfOTTO--e","original_id":"151","name":"Improper Neutralization of Comment Delimiters","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00493","_id":"cwe_mitigation/cwe_mitigation_00493","_rev":"_dVfOTTO--f","original_id":"152","name":"Improper Neutralization of Macro Symbols","metadata":{"Phase":"Implementation","Description":"Developers should anticipate that macro symbols will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00494","_id":"cwe_mitigation/cwe_mitigation_00494","_rev":"_dVfOTTO--g","original_id":"152","name":"Improper Neutralization of Macro Symbols","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00495","_id":"cwe_mitigation/cwe_mitigation_00495","_rev":"_dVfOTTO--h","original_id":"152","name":"Improper Neutralization of Macro Symbols","metadata":{"Phase":"Implementation","Description":"Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00496","_id":"cwe_mitigation/cwe_mitigation_00496","_rev":"_dVfOTTO--i","original_id":"152","name":"Improper Neutralization of Macro Symbols","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00497","_id":"cwe_mitigation/cwe_mitigation_00497","_rev":"_dVfOTTO--j","original_id":"153","name":"Improper Neutralization of Substitution Characters","metadata":{"Phase":"NA","Description":"Developers should anticipate that substitution characters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00498","_id":"cwe_mitigation/cwe_mitigation_00498","_rev":"_dVfOTTO--k","original_id":"153","name":"Improper Neutralization of Substitution Characters","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00499","_id":"cwe_mitigation/cwe_mitigation_00499","_rev":"_dVfOTTO--l","original_id":"153","name":"Improper Neutralization of Substitution Characters","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00500","_id":"cwe_mitigation/cwe_mitigation_00500","_rev":"_dVfOTTO--m","original_id":"153","name":"Improper Neutralization of Substitution Characters","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00501","_id":"cwe_mitigation/cwe_mitigation_00501","_rev":"_dVfOTTO--n","original_id":"154","name":"Improper Neutralization of Variable Name Delimiters","metadata":{"Phase":"NA","Description":"Developers should anticipate that variable name delimiters will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00502","_id":"cwe_mitigation/cwe_mitigation_00502","_rev":"_dVfOTTO--o","original_id":"154","name":"Improper Neutralization of Variable Name Delimiters","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00503","_id":"cwe_mitigation/cwe_mitigation_00503","_rev":"_dVfOTTO--p","original_id":"154","name":"Improper Neutralization of Variable Name Delimiters","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00504","_id":"cwe_mitigation/cwe_mitigation_00504","_rev":"_dVfOTTO--q","original_id":"154","name":"Improper Neutralization of Variable Name Delimiters","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00505","_id":"cwe_mitigation/cwe_mitigation_00505","_rev":"_dVfOTTO--r","original_id":"155","name":"Improper Neutralization of Wildcards or Matching Symbols","metadata":{"Phase":"NA","Description":"Developers should anticipate that wildcard or matching elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00506","_id":"cwe_mitigation/cwe_mitigation_00506","_rev":"_dVfOTTO--s","original_id":"155","name":"Improper Neutralization of Wildcards or Matching Symbols","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00507","_id":"cwe_mitigation/cwe_mitigation_00507","_rev":"_dVfOTTO--t","original_id":"155","name":"Improper Neutralization of Wildcards or Matching Symbols","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00508","_id":"cwe_mitigation/cwe_mitigation_00508","_rev":"_dVfOTTO--u","original_id":"155","name":"Improper Neutralization of Wildcards or Matching Symbols","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00509","_id":"cwe_mitigation/cwe_mitigation_00509","_rev":"_dVfOTTO--v","original_id":"156","name":"Improper Neutralization of Whitespace","metadata":{"Phase":"NA","Description":"Developers should anticipate that whitespace will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00510","_id":"cwe_mitigation/cwe_mitigation_00510","_rev":"_dVfOTTO--w","original_id":"156","name":"Improper Neutralization of Whitespace","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00511","_id":"cwe_mitigation/cwe_mitigation_00511","_rev":"_dVfOTTO--x","original_id":"156","name":"Improper Neutralization of Whitespace","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00512","_id":"cwe_mitigation/cwe_mitigation_00512","_rev":"_dVfOTTO--y","original_id":"156","name":"Improper Neutralization of Whitespace","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00513","_id":"cwe_mitigation/cwe_mitigation_00513","_rev":"_dVfOTTO--z","original_id":"157","name":"Failure to Sanitize Paired Delimiters","metadata":{"Phase":"NA","Description":"Developers should anticipate that grouping elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00514","_id":"cwe_mitigation/cwe_mitigation_00514","_rev":"_dVfOTTO--0","original_id":"157","name":"Failure to Sanitize Paired Delimiters","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00515","_id":"cwe_mitigation/cwe_mitigation_00515","_rev":"_dVfOTTO--1","original_id":"157","name":"Failure to Sanitize Paired Delimiters","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00516","_id":"cwe_mitigation/cwe_mitigation_00516","_rev":"_dVfOTTO--2","original_id":"157","name":"Failure to Sanitize Paired Delimiters","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00517","_id":"cwe_mitigation/cwe_mitigation_00517","_rev":"_dVfOTTO--3","original_id":"158","name":"Improper Neutralization of Null Byte or NUL Character","metadata":{"Phase":"NA","Description":"Developers should anticipate that null characters or null bytes will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00518","_id":"cwe_mitigation/cwe_mitigation_00518","_rev":"_dVfOTTO--4","original_id":"158","name":"Improper Neutralization of Null Byte or NUL Character","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00519","_id":"cwe_mitigation/cwe_mitigation_00519","_rev":"_dVfOTTO--5","original_id":"158","name":"Improper Neutralization of Null Byte or NUL Character","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00520","_id":"cwe_mitigation/cwe_mitigation_00520","_rev":"_dVfOTTO--6","original_id":"159","name":"Improper Handling of Invalid Use of Special Elements","metadata":{"Phase":"NA","Description":"Developers should anticipate that special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00521","_id":"cwe_mitigation/cwe_mitigation_00521","_rev":"_dVfOTTO--7","original_id":"159","name":"Improper Handling of Invalid Use of Special Elements","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00522","_id":"cwe_mitigation/cwe_mitigation_00522","_rev":"_dVfOTTO--8","original_id":"159","name":"Improper Handling of Invalid Use of Special Elements","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00523","_id":"cwe_mitigation/cwe_mitigation_00523","_rev":"_dVfOTTO--9","original_id":"159","name":"Improper Handling of Invalid Use of Special Elements","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00524","_id":"cwe_mitigation/cwe_mitigation_00524","_rev":"_dVfOTTO-_-","original_id":"160","name":"Improper Neutralization of Leading Special Elements","metadata":{"Phase":"NA","Description":"Developers should anticipate that leading special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00525","_id":"cwe_mitigation/cwe_mitigation_00525","_rev":"_dVfOTTO-__","original_id":"160","name":"Improper Neutralization of Leading Special Elements","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00526","_id":"cwe_mitigation/cwe_mitigation_00526","_rev":"_dVfOTTS---","original_id":"160","name":"Improper Neutralization of Leading Special Elements","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00527","_id":"cwe_mitigation/cwe_mitigation_00527","_rev":"_dVfOTTS--_","original_id":"160","name":"Improper Neutralization of Leading Special Elements","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00528","_id":"cwe_mitigation/cwe_mitigation_00528","_rev":"_dVfOTTS--A","original_id":"161","name":"Improper Neutralization of Multiple Leading Special Elements","metadata":{"Phase":"NA","Description":"Developers should anticipate that multiple leading special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00529","_id":"cwe_mitigation/cwe_mitigation_00529","_rev":"_dVfOTTS--B","original_id":"161","name":"Improper Neutralization of Multiple Leading Special Elements","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00530","_id":"cwe_mitigation/cwe_mitigation_00530","_rev":"_dVfOTTS--C","original_id":"161","name":"Improper Neutralization of Multiple Leading Special Elements","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00531","_id":"cwe_mitigation/cwe_mitigation_00531","_rev":"_dVfOTTS--D","original_id":"161","name":"Improper Neutralization of Multiple Leading Special Elements","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00532","_id":"cwe_mitigation/cwe_mitigation_00532","_rev":"_dVfOTTS--E","original_id":"162","name":"Improper Neutralization of Trailing Special Elements","metadata":{"Phase":"NA","Description":"Developers should anticipate that trailing special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00533","_id":"cwe_mitigation/cwe_mitigation_00533","_rev":"_dVfOTTS--F","original_id":"162","name":"Improper Neutralization of Trailing Special Elements","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00534","_id":"cwe_mitigation/cwe_mitigation_00534","_rev":"_dVfOTTS--G","original_id":"162","name":"Improper Neutralization of Trailing Special Elements","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00535","_id":"cwe_mitigation/cwe_mitigation_00535","_rev":"_dVfOTTS--H","original_id":"162","name":"Improper Neutralization of Trailing Special Elements","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00536","_id":"cwe_mitigation/cwe_mitigation_00536","_rev":"_dVfOTTS--I","original_id":"163","name":"Improper Neutralization of Multiple Trailing Special Elements","metadata":{"Phase":"NA","Description":"Developers should anticipate that multiple trailing special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00537","_id":"cwe_mitigation/cwe_mitigation_00537","_rev":"_dVfOTTS--J","original_id":"163","name":"Improper Neutralization of Multiple Trailing Special Elements","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00538","_id":"cwe_mitigation/cwe_mitigation_00538","_rev":"_dVfOTTS--K","original_id":"163","name":"Improper Neutralization of Multiple Trailing Special Elements","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00539","_id":"cwe_mitigation/cwe_mitigation_00539","_rev":"_dVfOTTS--L","original_id":"163","name":"Improper Neutralization of Multiple Trailing Special Elements","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00540","_id":"cwe_mitigation/cwe_mitigation_00540","_rev":"_dVfOTTS--M","original_id":"164","name":"Improper Neutralization of Internal Special Elements","metadata":{"Phase":"NA","Description":"Developers should anticipate that internal special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00541","_id":"cwe_mitigation/cwe_mitigation_00541","_rev":"_dVfOTTS--N","original_id":"164","name":"Improper Neutralization of Internal Special Elements","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00542","_id":"cwe_mitigation/cwe_mitigation_00542","_rev":"_dVfOTTS--O","original_id":"164","name":"Improper Neutralization of Internal Special Elements","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00543","_id":"cwe_mitigation/cwe_mitigation_00543","_rev":"_dVfOTTS--P","original_id":"164","name":"Improper Neutralization of Internal Special Elements","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00544","_id":"cwe_mitigation/cwe_mitigation_00544","_rev":"_dVfOTTS--Q","original_id":"165","name":"Improper Neutralization of Multiple Internal Special Elements","metadata":{"Phase":"NA","Description":"Developers should anticipate that multiple internal special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00545","_id":"cwe_mitigation/cwe_mitigation_00545","_rev":"_dVfOTTS--R","original_id":"165","name":"Improper Neutralization of Multiple Internal Special Elements","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00546","_id":"cwe_mitigation/cwe_mitigation_00546","_rev":"_dVfOTTS--S","original_id":"165","name":"Improper Neutralization of Multiple Internal Special Elements","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00547","_id":"cwe_mitigation/cwe_mitigation_00547","_rev":"_dVfOTTS--T","original_id":"165","name":"Improper Neutralization of Multiple Internal Special Elements","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00548","_id":"cwe_mitigation/cwe_mitigation_00548","_rev":"_dVfOTTS--U","original_id":"166","name":"Improper Handling of Missing Special Element","metadata":{"Phase":"NA","Description":"Developers should anticipate that special elements will be removed in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00549","_id":"cwe_mitigation/cwe_mitigation_00549","_rev":"_dVfOTTS--V","original_id":"166","name":"Improper Handling of Missing Special Element","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00550","_id":"cwe_mitigation/cwe_mitigation_00550","_rev":"_dVfOTTS--W","original_id":"166","name":"Improper Handling of Missing Special Element","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00551","_id":"cwe_mitigation/cwe_mitigation_00551","_rev":"_dVfOTTS--X","original_id":"167","name":"Improper Handling of Additional Special Element","metadata":{"Phase":"NA","Description":"Developers should anticipate that extra special elements will be injected in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00552","_id":"cwe_mitigation/cwe_mitigation_00552","_rev":"_dVfOTTS--Y","original_id":"167","name":"Improper Handling of Additional Special Element","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00553","_id":"cwe_mitigation/cwe_mitigation_00553","_rev":"_dVfOTTS--Z","original_id":"167","name":"Improper Handling of Additional Special Element","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00554","_id":"cwe_mitigation/cwe_mitigation_00554","_rev":"_dVfOTTS--a","original_id":"167","name":"Improper Handling of Additional Special Element","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00555","_id":"cwe_mitigation/cwe_mitigation_00555","_rev":"_dVfOTTS--b","original_id":"168","name":"Improper Handling of Inconsistent Special Elements","metadata":{"Phase":"NA","Description":"Developers should anticipate that inconsistent special elements will be injected/manipulated in the input vectors of their software system. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00556","_id":"cwe_mitigation/cwe_mitigation_00556","_rev":"_dVfOTTS--c","original_id":"168","name":"Improper Handling of Inconsistent Special Elements","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00557","_id":"cwe_mitigation/cwe_mitigation_00557","_rev":"_dVfOTTS--d","original_id":"168","name":"Improper Handling of Inconsistent Special Elements","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00558","_id":"cwe_mitigation/cwe_mitigation_00558","_rev":"_dVfOTTS--e","original_id":"170","name":"Improper Null Termination","metadata":{"Phase":"Requirements","Description":"Use a language that is not susceptible to these issues. However, be careful of null byte interaction errors (CWE-626) with lower-level constructs that may be written in a language that is susceptible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00559","_id":"cwe_mitigation/cwe_mitigation_00559","_rev":"_dVfOTTS--f","original_id":"170","name":"Improper Null Termination","metadata":{"Phase":"Implementation","Description":"Ensure that all string functions used are understood fully as to how they append null characters. Also, be wary of off-by-one errors when appending nulls to the end of strings."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00560","_id":"cwe_mitigation/cwe_mitigation_00560","_rev":"_dVfOTTS--g","original_id":"170","name":"Improper Null Termination","metadata":{"Phase":"Implementation","Description":"If performance constraints permit, special code can be added that validates null-termination of string buffers, this is a rather naive and error-prone solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00561","_id":"cwe_mitigation/cwe_mitigation_00561","_rev":"_dVfOTTS--h","original_id":"170","name":"Improper Null Termination","metadata":{"Phase":"Implementation","Description":"Switch to bounded string manipulation functions. Inspect buffer lengths involved in the buffer overrun trace reported with the defect."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00562","_id":"cwe_mitigation/cwe_mitigation_00562","_rev":"_dVfOTTS--i","original_id":"170","name":"Improper Null Termination","metadata":{"Phase":"Implementation","Description":"Add code that fills buffers with nulls (however, the length of buffers still needs to be inspected, to ensure that the non null-terminated string is not written at the physical end of the buffer)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00563","_id":"cwe_mitigation/cwe_mitigation_00563","_rev":"_dVfOTTS--j","original_id":"172","name":"Encoding Error","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00564","_id":"cwe_mitigation/cwe_mitigation_00564","_rev":"_dVfOTTS--k","original_id":"172","name":"Encoding Error","metadata":{"Phase":"Implementation","Description":"While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00565","_id":"cwe_mitigation/cwe_mitigation_00565","_rev":"_dVfOTTS--l","original_id":"172","name":"Encoding Error","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00566","_id":"cwe_mitigation/cwe_mitigation_00566","_rev":"_dVfOTTS--m","original_id":"173","name":"Improper Handling of Alternate Encoding","metadata":{"Phase":"Architecture and Design","Description":"Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00567","_id":"cwe_mitigation/cwe_mitigation_00567","_rev":"_dVfOTTS--n","original_id":"173","name":"Improper Handling of Alternate Encoding","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00568","_id":"cwe_mitigation/cwe_mitigation_00568","_rev":"_dVfOTTS--o","original_id":"173","name":"Improper Handling of Alternate Encoding","metadata":{"Phase":"Implementation","Description":"Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00569","_id":"cwe_mitigation/cwe_mitigation_00569","_rev":"_dVfOTTS--p","original_id":"173","name":"Improper Handling of Alternate Encoding","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00570","_id":"cwe_mitigation/cwe_mitigation_00570","_rev":"_dVfOTTS--q","original_id":"174","name":"Double Decoding of the Same Data","metadata":{"Phase":"Architecture and Design","Description":"Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00571","_id":"cwe_mitigation/cwe_mitigation_00571","_rev":"_dVfOTTS--r","original_id":"174","name":"Double Decoding of the Same Data","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00572","_id":"cwe_mitigation/cwe_mitigation_00572","_rev":"_dVfOTTS--s","original_id":"174","name":"Double Decoding of the Same Data","metadata":{"Phase":"Implementation","Description":"Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00573","_id":"cwe_mitigation/cwe_mitigation_00573","_rev":"_dVfOTTS--t","original_id":"174","name":"Double Decoding of the Same Data","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00574","_id":"cwe_mitigation/cwe_mitigation_00574","_rev":"_dVfOTTS--u","original_id":"175","name":"Improper Handling of Mixed Encoding","metadata":{"Phase":"Architecture and Design","Description":"Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00575","_id":"cwe_mitigation/cwe_mitigation_00575","_rev":"_dVfOTTS--v","original_id":"175","name":"Improper Handling of Mixed Encoding","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00576","_id":"cwe_mitigation/cwe_mitigation_00576","_rev":"_dVfOTTS--w","original_id":"175","name":"Improper Handling of Mixed Encoding","metadata":{"Phase":"Implementation","Description":"Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00577","_id":"cwe_mitigation/cwe_mitigation_00577","_rev":"_dVfOTTS--x","original_id":"175","name":"Improper Handling of Mixed Encoding","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00578","_id":"cwe_mitigation/cwe_mitigation_00578","_rev":"_dVfOTTS--y","original_id":"176","name":"Improper Handling of Unicode Encoding","metadata":{"Phase":"Architecture and Design","Description":"Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00579","_id":"cwe_mitigation/cwe_mitigation_00579","_rev":"_dVfOTTS--z","original_id":"176","name":"Improper Handling of Unicode Encoding","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00580","_id":"cwe_mitigation/cwe_mitigation_00580","_rev":"_dVfOTTS--0","original_id":"176","name":"Improper Handling of Unicode Encoding","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00581","_id":"cwe_mitigation/cwe_mitigation_00581","_rev":"_dVfOTTS--1","original_id":"177","name":"Improper Handling of URL Encoding (Hex Encoding)","metadata":{"Phase":"Architecture and Design","Description":"Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00582","_id":"cwe_mitigation/cwe_mitigation_00582","_rev":"_dVfOTTS--2","original_id":"177","name":"Improper Handling of URL Encoding (Hex Encoding)","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00583","_id":"cwe_mitigation/cwe_mitigation_00583","_rev":"_dVfOTTS--3","original_id":"177","name":"Improper Handling of URL Encoding (Hex Encoding)","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00584","_id":"cwe_mitigation/cwe_mitigation_00584","_rev":"_dVfOTTS--4","original_id":"178","name":"Improper Handling of Case Sensitivity","metadata":{"Phase":"Architecture and Design","Description":"Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00585","_id":"cwe_mitigation/cwe_mitigation_00585","_rev":"_dVfOTTS--5","original_id":"178","name":"Improper Handling of Case Sensitivity","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00586","_id":"cwe_mitigation/cwe_mitigation_00586","_rev":"_dVfOTTS--6","original_id":"178","name":"Improper Handling of Case Sensitivity","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00587","_id":"cwe_mitigation/cwe_mitigation_00587","_rev":"_dVfOTTS--7","original_id":"179","name":"Incorrect Behavior Order: Early Validation","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00588","_id":"cwe_mitigation/cwe_mitigation_00588","_rev":"_dVfOTTS--8","original_id":"180","name":"Incorrect Behavior Order: Validate Before Canonicalize","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00589","_id":"cwe_mitigation/cwe_mitigation_00589","_rev":"_dVfOTTS--9","original_id":"181","name":"Incorrect Behavior Order: Validate Before Filter","metadata":{"Phase":"Implementation","Description":"Inputs should be decoded and canonicalized to the application's current internal representation before being filtered."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00590","_id":"cwe_mitigation/cwe_mitigation_00590","_rev":"_dVfOTTS-_-","original_id":"182","name":"Collapse of Data into Unsafe Value","metadata":{"Phase":"Architecture and Design","Description":"Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00591","_id":"cwe_mitigation/cwe_mitigation_00591","_rev":"_dVfOTTS-__","original_id":"182","name":"Collapse of Data into Unsafe Value","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00592","_id":"cwe_mitigation/cwe_mitigation_00592","_rev":"_dVfOTTS-_A","original_id":"182","name":"Collapse of Data into Unsafe Value","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00593","_id":"cwe_mitigation/cwe_mitigation_00593","_rev":"_dVfOTTS-_B","original_id":"182","name":"Collapse of Data into Unsafe Value","metadata":{"Phase":"NA","Description":"Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00594","_id":"cwe_mitigation/cwe_mitigation_00594","_rev":"_dVfOTTS-_C","original_id":"184","name":"Incomplete List of Disallowed Inputs","metadata":{"Phase":"Implementation","Description":"Do not rely exclusively on detecting disallowed inputs.  There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants.  Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify \"good\" input - such as lists of allowed inputs - and ensure that you are properly encoding your outputs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00596","_id":"cwe_mitigation/cwe_mitigation_00596","_rev":"_dVfOTTS-_D","original_id":"185","name":"Incorrect Regular Expression","metadata":{"Phase":"Architecture and Design","Description":"Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplify one large regular expression. Also, subject the regular expression to thorough testing techniques such as equivalence partitioning, boundary value analysis, and robustness. After testing and a reasonable confidence level is achieved, a regular expression may not be foolproof. If an exploit is allowed to slip through, then record the exploit and refactor the regular expression."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00597","_id":"cwe_mitigation/cwe_mitigation_00597","_rev":"_dVfOTTS-_E","original_id":"186","name":"Overly Restrictive Regular Expression","metadata":{"Phase":"Implementation","Description":"Regular expressions can become error prone when defining a complex language even for those experienced in writing grammars. Determine if several smaller regular expressions simplify one large regular expression. Also, subject your regular expression to thorough testing techniques such as equivalence partitioning, boundary value analysis, and robustness. After testing and a reasonable confidence level is achieved, a regular expression may not be foolproof. If an exploit is allowed to slip through, then record the exploit and refactor your regular expression."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00598","_id":"cwe_mitigation/cwe_mitigation_00598","_rev":"_dVfOTTS-_F","original_id":"187","name":"Partial String Comparison","metadata":{"Phase":"Testing","Description":"Thoroughly test the comparison scheme before deploying code into production. Perform positive testing as well as negative testing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00599","_id":"cwe_mitigation/cwe_mitigation_00599","_rev":"_dVfOTTW---","original_id":"188","name":"Reliance on Data/Memory Layout","metadata":{"Phase":"Implementation","Description":"In flat address space situations, never allow computing memory addresses as offsets from another memory address."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00600","_id":"cwe_mitigation/cwe_mitigation_00600","_rev":"_dVfOTTW--_","original_id":"188","name":"Reliance on Data/Memory Layout","metadata":{"Phase":"Architecture and Design","Description":"Fully specify protocol layout unambiguously, providing a structured grammar (e.g., a compilable yacc grammar)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00601","_id":"cwe_mitigation/cwe_mitigation_00601","_rev":"_dVfOTTW--A","original_id":"188","name":"Reliance on Data/Memory Layout","metadata":{"Phase":"Testing","Description":"Testing: Test that the implementation properly handles each case in the protocol grammar."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00602","_id":"cwe_mitigation/cwe_mitigation_00602","_rev":"_dVfOTTW--B","original_id":"190","name":"Integer Overflow or Wraparound","metadata":{"Phase":"Requirements","Description":"Ensure that all protocols are strictly defined, such that all out-of-bounds behavior can be identified simply, and require strict conformance to the protocol."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00603","_id":"cwe_mitigation/cwe_mitigation_00603","_rev":"_dVfOTTW--C","original_id":"190","name":"Integer Overflow or Wraparound","metadata":{"Phase":"Requirements","Description":"\n                  Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  If possible, choose a language or compiler that performs automatic bounds checking.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00604","_id":"cwe_mitigation/cwe_mitigation_00604","_rev":"_dVfOTTW--D","original_id":"190","name":"Integer Overflow or Wraparound","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  Use libraries or frameworks that make it easier to handle numbers without unexpected consequences.\n                  Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00605","_id":"cwe_mitigation/cwe_mitigation_00605","_rev":"_dVfOTTW--E","original_id":"190","name":"Integer Overflow or Wraparound","metadata":{"Phase":"Implementation","Description":"\n                  Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.\n                  Use unsigned integers where possible. This makes it easier to perform validation for integer overflows. When signed integers are required, ensure that the range check includes minimum values as well as maximum values.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00606","_id":"cwe_mitigation/cwe_mitigation_00606","_rev":"_dVfOTTW--F","original_id":"190","name":"Integer Overflow or Wraparound","metadata":{"Phase":"Implementation","Description":"\n                  Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, \"not-a-number\" calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]\n                  Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00607","_id":"cwe_mitigation/cwe_mitigation_00607","_rev":"_dVfOTTW--G","original_id":"190","name":"Integer Overflow or Wraparound","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00608","_id":"cwe_mitigation/cwe_mitigation_00608","_rev":"_dVfOTTW--H","original_id":"190","name":"Integer Overflow or Wraparound","metadata":{"Phase":"Implementation","Description":"Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00617","_id":"cwe_mitigation/cwe_mitigation_00617","_rev":"_dVfOTTW--I","original_id":"192","name":"Integer Coercion Error","metadata":{"Phase":"Requirements","Description":"A language which throws exceptions on ambiguous data casts might be chosen."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00618","_id":"cwe_mitigation/cwe_mitigation_00618","_rev":"_dVfOTTW--J","original_id":"192","name":"Integer Coercion Error","metadata":{"Phase":"Architecture and Design","Description":"Design objects and program flow such that multiple or complex casts are unnecessary"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00619","_id":"cwe_mitigation/cwe_mitigation_00619","_rev":"_dVfOTTW--K","original_id":"192","name":"Integer Coercion Error","metadata":{"Phase":"Implementation","Description":"Ensure that any data type casting that you must used is entirely understood in order to reduce the plausibility of error in use."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00620","_id":"cwe_mitigation/cwe_mitigation_00620","_rev":"_dVfOTTW--L","original_id":"193","name":"Off-by-one Error","metadata":{"Phase":"Implementation","Description":"When copying character arrays or using character manipulation methods, the correct size parameter must be used to account for the null terminator that needs to be added at the end of the array. Some examples of functions susceptible to this weakness in C include strcpy(), strncpy(), strcat(), strncat(), printf(), sprintf(), scanf() and sscanf()."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00621","_id":"cwe_mitigation/cwe_mitigation_00621","_rev":"_dVfOTTW--M","original_id":"194","name":"Unexpected Sign Extension","metadata":{"Phase":"Implementation","Description":"Avoid using signed variables if you don't need to represent negative values. When negative values are needed, perform validation after you save those values to larger data types, or before passing them to functions that are expecting unsigned values."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00622","_id":"cwe_mitigation/cwe_mitigation_00622","_rev":"_dVfOTTW--N","original_id":"196","name":"Unsigned to Signed Conversion Error","metadata":{"Phase":"Requirements","Description":"Choose a language which is not subject to these casting flaws."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00623","_id":"cwe_mitigation/cwe_mitigation_00623","_rev":"_dVfOTTW--O","original_id":"196","name":"Unsigned to Signed Conversion Error","metadata":{"Phase":"Architecture and Design","Description":"Design object accessor functions to implicitly check values for valid sizes. Ensure that all functions which will be used as a size are checked previous to use as a size. If the language permits, throw exceptions rather than using in-band errors."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00624","_id":"cwe_mitigation/cwe_mitigation_00624","_rev":"_dVfOTTW--P","original_id":"196","name":"Unsigned to Signed Conversion Error","metadata":{"Phase":"Implementation","Description":"Error check the return values of all functions. Be aware of implicit casts made, and use unsigned variables for sizes if at all possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00625","_id":"cwe_mitigation/cwe_mitigation_00625","_rev":"_dVfOTTW--Q","original_id":"197","name":"Numeric Truncation Error","metadata":{"Phase":"Implementation","Description":"Ensure that no casts, implicit or explicit, take place that move from a larger size primitive or a smaller size primitive."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00627","_id":"cwe_mitigation/cwe_mitigation_00627","_rev":"_dVfOTTW--R","original_id":"200","name":"Exposure of Sensitive Information to an Unauthorized Actor","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00634","_id":"cwe_mitigation/cwe_mitigation_00634","_rev":"_dVfOTTW--S","original_id":"201","name":"Insertion of Sensitive Information Into Sent Data","metadata":{"Phase":"Requirements","Description":"Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00635","_id":"cwe_mitigation/cwe_mitigation_00635","_rev":"_dVfOTTW--T","original_id":"201","name":"Insertion of Sensitive Information Into Sent Data","metadata":{"Phase":"Implementation","Description":"Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00636","_id":"cwe_mitigation/cwe_mitigation_00636","_rev":"_dVfOTTW--U","original_id":"201","name":"Insertion of Sensitive Information Into Sent Data","metadata":{"Phase":"System Configuration","Description":"Setup default error messages so that unexpected errors do not disclose sensitive information."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00637","_id":"cwe_mitigation/cwe_mitigation_00637","_rev":"_dVfOTTW--V","original_id":"201","name":"Insertion of Sensitive Information Into Sent Data","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00638","_id":"cwe_mitigation/cwe_mitigation_00638","_rev":"_dVfOTTW--W","original_id":"202","name":"Exposure of Sensitive Information Through Data Queries","metadata":{"Phase":"Architecture and Design","Description":"This is a complex topic. See the book Translucent Databases for a good discussion of best practices."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00639","_id":"cwe_mitigation/cwe_mitigation_00639","_rev":"_dVfOTTW--X","original_id":"203","name":"Observable Discrepancy","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00640","_id":"cwe_mitigation/cwe_mitigation_00640","_rev":"_dVfOTTW--Y","original_id":"203","name":"Observable Discrepancy","metadata":{"Phase":"Implementation","Description":"\n                  Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.\n                  If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.\n\t\t  Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00641","_id":"cwe_mitigation/cwe_mitigation_00641","_rev":"_dVfOTTW--Z","original_id":"204","name":"Observable Response Discrepancy","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00642","_id":"cwe_mitigation/cwe_mitigation_00642","_rev":"_dVfOTTW--a","original_id":"204","name":"Observable Response Discrepancy","metadata":{"Phase":"Implementation","Description":"\n                  Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.\n                  If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.\n\t\t  Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00643","_id":"cwe_mitigation/cwe_mitigation_00643","_rev":"_dVfOTTW--b","original_id":"206","name":"Observable Internal Behavioral Discrepancy","metadata":{"Phase":"NA","Description":"Setup generic response pages for error conditions. The error page should not disclose information about the success or failure of a sensitive operation. For instance, the login page should not confirm that the login is correct and the password incorrect. The attacker who tries random account name may be able to guess some of them. Confirming that the account exists would make the login page more susceptible to brute force attack."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00644","_id":"cwe_mitigation/cwe_mitigation_00644","_rev":"_dVfOTTW--c","original_id":"209","name":"Generation of Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"\n                  Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.\n                  If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.\n\t\t  Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00645","_id":"cwe_mitigation/cwe_mitigation_00645","_rev":"_dVfOTTW--d","original_id":"209","name":"Generation of Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"Handle exceptions internally and do not display errors containing potentially sensitive information to a user."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00646","_id":"cwe_mitigation/cwe_mitigation_00646","_rev":"_dVfOTTW--e","original_id":"209","name":"Generation of Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00647","_id":"cwe_mitigation/cwe_mitigation_00647","_rev":"_dVfOTTW--f","original_id":"209","name":"Generation of Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"Debugging information should not make its way into a production release."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00648","_id":"cwe_mitigation/cwe_mitigation_00648","_rev":"_dVfOTTW--g","original_id":"209","name":"Generation of Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"Debugging information should not make its way into a production release."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00649","_id":"cwe_mitigation/cwe_mitigation_00649","_rev":"_dVfOTTW--h","original_id":"209","name":"Generation of Error Message Containing Sensitive Information","metadata":{"Phase":"System Configuration","Description":"Where available, configure the environment to use less verbose error messages. For example, in PHP, disable the display_errors setting during configuration, or at runtime using the error_reporting() function."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00650","_id":"cwe_mitigation/cwe_mitigation_00650","_rev":"_dVfOTTW--i","original_id":"209","name":"Generation of Error Message Containing Sensitive Information","metadata":{"Phase":"System Configuration","Description":"Create default error pages or messages that do not leak any information."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00655","_id":"cwe_mitigation/cwe_mitigation_00655","_rev":"_dVfOTTW--j","original_id":"210","name":"Self-generated Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"Debugging information should not make its way into a production release."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00656","_id":"cwe_mitigation/cwe_mitigation_00656","_rev":"_dVfOTTW--k","original_id":"210","name":"Self-generated Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"Debugging information should not make its way into a production release."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00657","_id":"cwe_mitigation/cwe_mitigation_00657","_rev":"_dVfOTTW--l","original_id":"211","name":"Externally-Generated Error Message Containing Sensitive Information","metadata":{"Phase":"System Configuration","Description":"Configure the application's environment in a way that prevents errors from being generated. For example, in PHP, disable display_errors."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00658","_id":"cwe_mitigation/cwe_mitigation_00658","_rev":"_dVfOTTW--m","original_id":"211","name":"Externally-Generated Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"Debugging information should not make its way into a production release."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00659","_id":"cwe_mitigation/cwe_mitigation_00659","_rev":"_dVfOTTW--n","original_id":"211","name":"Externally-Generated Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"Debugging information should not make its way into a production release."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00660","_id":"cwe_mitigation/cwe_mitigation_00660","_rev":"_dVfOTTW--o","original_id":"211","name":"Externally-Generated Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"Handle exceptions internally and do not display errors containing potentially sensitive information to a user. Create default error pages if necessary."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00661","_id":"cwe_mitigation/cwe_mitigation_00661","_rev":"_dVfOTTW--p","original_id":"211","name":"Externally-Generated Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"The best way to prevent this weakness during implementation is to avoid any bugs that could trigger the external error message. This typically happens when the program encounters fatal errors, such as a divide-by-zero. You will not always be able to control the use of error pages, and you might not be using a language that handles exceptions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00662","_id":"cwe_mitigation/cwe_mitigation_00662","_rev":"_dVfOTTW--q","original_id":"212","name":"Improper Removal of Sensitive Information Before Storage or Transfer","metadata":{"Phase":"Requirements","Description":"Clearly specify which information should be regarded as private or sensitive, and require that the product offers functionality that allows the user to cleanse the sensitive information from the resource before it is published or exported to other parties."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00663","_id":"cwe_mitigation/cwe_mitigation_00663","_rev":"_dVfOTTW--r","original_id":"212","name":"Improper Removal of Sensitive Information Before Storage or Transfer","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00664","_id":"cwe_mitigation/cwe_mitigation_00664","_rev":"_dVfOTTW--s","original_id":"212","name":"Improper Removal of Sensitive Information Before Storage or Transfer","metadata":{"Phase":"Implementation","Description":"Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00665","_id":"cwe_mitigation/cwe_mitigation_00665","_rev":"_dVfOTTW--t","original_id":"212","name":"Improper Removal of Sensitive Information Before Storage or Transfer","metadata":{"Phase":"Implementation","Description":"Avoid errors related to improper resource shutdown or release (CWE-404), which may leave the sensitive data within the resource if it is in an incomplete state."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00666","_id":"cwe_mitigation/cwe_mitigation_00666","_rev":"_dVfOTTW--u","original_id":"215","name":"Insertion of Sensitive Information Into Debugging Code","metadata":{"Phase":"Implementation","Description":"Do not leave debug statements that could be executed in the source code. Ensure that all debug information is eradicated before releasing the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00667","_id":"cwe_mitigation/cwe_mitigation_00667","_rev":"_dVfOTTW--v","original_id":"215","name":"Insertion of Sensitive Information Into Debugging Code","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00668","_id":"cwe_mitigation/cwe_mitigation_00668","_rev":"_dVfOTTW--w","original_id":"219","name":"Storage of File with Sensitive Data Under Web Root","metadata":{"Phase":"Implementation","Description":"Avoid storing information under the web root directory."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00669","_id":"cwe_mitigation/cwe_mitigation_00669","_rev":"_dVfOTTW--x","original_id":"219","name":"Storage of File with Sensitive Data Under Web Root","metadata":{"Phase":"System Configuration","Description":"Access control permissions should be set to prevent reading/writing of sensitive files inside/outside of the web directory."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00670","_id":"cwe_mitigation/cwe_mitigation_00670","_rev":"_dVfOTTW--y","original_id":"220","name":"Storage of File With Sensitive Data Under FTP Root","metadata":{"Phase":"Implementation","Description":"Avoid storing information under the FTP root directory."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00671","_id":"cwe_mitigation/cwe_mitigation_00671","_rev":"_dVfOTTW--z","original_id":"220","name":"Storage of File With Sensitive Data Under FTP Root","metadata":{"Phase":"System Configuration","Description":"Access control permissions should be set to prevent reading/writing of sensitive files inside/outside of the FTP directory."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00672","_id":"cwe_mitigation/cwe_mitigation_00672","_rev":"_dVfOTTW--0","original_id":"226","name":"Sensitive Information in Resource Not Removed Before Reuse","metadata":{"Phase":"Architecture and Design","Description":"During critical state transitions, information not needed in the next state should be removed or overwritten with fixed patterns (such as all 0's) or random data, before the transition to the next state."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00673","_id":"cwe_mitigation/cwe_mitigation_00673","_rev":"_dVfOTTW--1","original_id":"226","name":"Sensitive Information in Resource Not Removed Before Reuse","metadata":{"Phase":"Architecture and Design","Description":"When releasing, de-allocating, or deleting a resource, overwrite its data and relevant metadata with fixed patterns or random data. Be cautious about complex resource types whose underlying representation might be non-contiguous or change at a low level, such as how a file might be split into different chunks on a file system, even though \"logical\" file positions are contiguous at the application layer. Such resource types might require invocation of special modes or APIs to tell the underlying operating system to perform the necessary clearing, such as SDelete (Secure Delete) on Windows, although the appropriate functionality might not be available at the application layer."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00675","_id":"cwe_mitigation/cwe_mitigation_00675","_rev":"_dVfOTTW--2","original_id":"234","name":"Failure to Handle Missing Parameter","metadata":{"Phase":"Build and Compilation","Description":"This issue can be simply combated with the use of proper build process."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00676","_id":"cwe_mitigation/cwe_mitigation_00676","_rev":"_dVfOTTW--3","original_id":"234","name":"Failure to Handle Missing Parameter","metadata":{"Phase":"Implementation","Description":"Forward declare all functions. This is the recommended solution. Properly forward declaration of all used functions will result in a compiler error if too few arguments are sent to a function."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00677","_id":"cwe_mitigation/cwe_mitigation_00677","_rev":"_dVfOTTW--4","original_id":"241","name":"Improper Handling of Unexpected Data Type","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00678","_id":"cwe_mitigation/cwe_mitigation_00678","_rev":"_dVfOTTW--5","original_id":"241","name":"Improper Handling of Unexpected Data Type","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00679","_id":"cwe_mitigation/cwe_mitigation_00679","_rev":"_dVfOTTW--6","original_id":"242","name":"Use of Inherently Dangerous Function","metadata":{"Phase":"Implementation","Description":"Ban the use of dangerous functions. Use their safe equivalent."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00680","_id":"cwe_mitigation/cwe_mitigation_00680","_rev":"_dVfOTTW--7","original_id":"242","name":"Use of Inherently Dangerous Function","metadata":{"Phase":"Testing","Description":"Use grep or static analysis tools to spot usage of dangerous functions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00681","_id":"cwe_mitigation/cwe_mitigation_00681","_rev":"_dVfOTTW--8","original_id":"246","name":"J2EE Bad Practices: Direct Use of Sockets","metadata":{"Phase":"Architecture and Design","Description":"Use framework method calls instead of using sockets directly."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00682","_id":"cwe_mitigation/cwe_mitigation_00682","_rev":"_dVfOTTW--9","original_id":"250","name":"Execution with Unnecessary Privileges","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00683","_id":"cwe_mitigation/cwe_mitigation_00683","_rev":"_dVfOTTW-_-","original_id":"250","name":"Execution with Unnecessary Privileges","metadata":{"Phase":"Architecture and Design","Description":"Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00684","_id":"cwe_mitigation/cwe_mitigation_00684","_rev":"_dVfOTTW-__","original_id":"250","name":"Execution with Unnecessary Privileges","metadata":{"Phase":"Architecture and Design","Description":"Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00685","_id":"cwe_mitigation/cwe_mitigation_00685","_rev":"_dVfOTTW-_A","original_id":"250","name":"Execution with Unnecessary Privileges","metadata":{"Phase":"Implementation","Description":"Perform extensive input validation for any privileged code that must be exposed to the user and reject anything that does not fit your strict requirements."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00686","_id":"cwe_mitigation/cwe_mitigation_00686","_rev":"_dVfOTTW-_B","original_id":"250","name":"Execution with Unnecessary Privileges","metadata":{"Phase":"Implementation","Description":"When dropping privileges, ensure that they have been dropped successfully to avoid CWE-273. As protection mechanisms in the environment get stronger, privilege-dropping calls may fail even if it seems like they would always succeed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00687","_id":"cwe_mitigation/cwe_mitigation_00687","_rev":"_dVfOTTW-_C","original_id":"250","name":"Execution with Unnecessary Privileges","metadata":{"Phase":"Implementation","Description":"If circumstances force you to run with extra privileges, then determine the minimum access level necessary. First identify the different permissions that the software and its users will need to perform their actions, such as file read and write permissions, network socket permissions, and so forth. Then explicitly allow those actions while denying all else [REF-76]. Perform extensive input validation and canonicalization to minimize the chances of introducing a separate vulnerability. This mitigation is much more prone to error than dropping the privileges in the first place."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00688","_id":"cwe_mitigation/cwe_mitigation_00688","_rev":"_dVfOTTW-_D","original_id":"250","name":"Execution with Unnecessary Privileges","metadata":{"Phase":"Operation","Description":"Ensure that the software runs properly under the Federal Desktop Core Configuration (FDCC) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00699","_id":"cwe_mitigation/cwe_mitigation_00699","_rev":"_dVfOTTW-_E","original_id":"252","name":"Unchecked Return Value","metadata":{"Phase":"Implementation","Description":"Check the results of all functions that return a value and verify that the value is expected."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00700","_id":"cwe_mitigation/cwe_mitigation_00700","_rev":"_dVfOTTW-_F","original_id":"252","name":"Unchecked Return Value","metadata":{"Phase":"Implementation","Description":"Ensure that you account for all possible return values from the function."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00701","_id":"cwe_mitigation/cwe_mitigation_00701","_rev":"_dVfOTTW-_G","original_id":"252","name":"Unchecked Return Value","metadata":{"Phase":"Implementation","Description":"When designing a function, make sure you return a value or throw an exception in case of an error."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00702","_id":"cwe_mitigation/cwe_mitigation_00702","_rev":"_dVfOTTW-_H","original_id":"253","name":"Incorrect Check of Function Return Value","metadata":{"Phase":"Architecture and Design","Description":"Use a language or compiler that uses exceptions and requires the catching of those exceptions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00703","_id":"cwe_mitigation/cwe_mitigation_00703","_rev":"_dVfOTTW-_I","original_id":"253","name":"Incorrect Check of Function Return Value","metadata":{"Phase":"Implementation","Description":"Properly check all functions which return a value."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00704","_id":"cwe_mitigation/cwe_mitigation_00704","_rev":"_dVfOTTW-_J","original_id":"253","name":"Incorrect Check of Function Return Value","metadata":{"Phase":"Implementation","Description":"When designing any function make sure you return a value or throw an exception in case of an error."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00705","_id":"cwe_mitigation/cwe_mitigation_00705","_rev":"_dVfOTTW-_K","original_id":"256","name":"Plaintext Storage of a Password","metadata":{"Phase":"Architecture and Design","Description":"Avoid storing passwords in easily accessible locations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00706","_id":"cwe_mitigation/cwe_mitigation_00706","_rev":"_dVfOTTW-_L","original_id":"256","name":"Plaintext Storage of a Password","metadata":{"Phase":"Architecture and Design","Description":"Consider storing cryptographic hashes of passwords as an alternative to storing in plaintext."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00707","_id":"cwe_mitigation/cwe_mitigation_00707","_rev":"_dVfOTTW-_M","original_id":"256","name":"Plaintext Storage of a Password","metadata":{"Phase":"NA","Description":"A programmer might attempt to remedy the password management problem by obscuring the password with an encoding function, such as base 64 encoding, but this effort does not adequately protect the password because the encoding can be detected and decoded easily."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00708","_id":"cwe_mitigation/cwe_mitigation_00708","_rev":"_dVfOTTW-_N","original_id":"257","name":"Storing Passwords in a Recoverable Format","metadata":{"Phase":"Architecture and Design","Description":"Use strong, non-reversible encryption to protect stored passwords."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00709","_id":"cwe_mitigation/cwe_mitigation_00709","_rev":"_dVfOTTW-_O","original_id":"258","name":"Empty Password in Configuration File","metadata":{"Phase":"System Configuration","Description":"Passwords should be at least eight characters long -- the longer the better. Avoid passwords that are in any way similar to other passwords you have. Avoid using words that may be found in a dictionary, names book, on a map, etc. Consider incorporating numbers and/or punctuation into your password. If you do use common words, consider replacing letters in that word with numbers and punctuation. However, do not use \"similar-looking\" punctuation. For example, it is not a good idea to change cat to c@t, ca+, (@+, or anything similar. Finally, it is never appropriate to use an empty string as a password."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00710","_id":"cwe_mitigation/cwe_mitigation_00710","_rev":"_dVfOTTW-_P","original_id":"259","name":"Use of Hard-coded Password","metadata":{"Phase":"Architecture and Design","Description":"For outbound authentication: store passwords outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders, including other local users on the same system. Properly protect the key (CWE-320). If you cannot use encryption to protect the file, then make sure that the permissions are as restrictive as possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00711","_id":"cwe_mitigation/cwe_mitigation_00711","_rev":"_dVfOTTa---","original_id":"259","name":"Use of Hard-coded Password","metadata":{"Phase":"Architecture and Design","Description":"For inbound authentication: Rather than hard-code a default username and password for first time logins, utilize a \"first login\" mode that requires the user to enter a unique strong password."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00712","_id":"cwe_mitigation/cwe_mitigation_00712","_rev":"_dVfOTTa--_","original_id":"259","name":"Use of Hard-coded Password","metadata":{"Phase":"Architecture and Design","Description":"Perform access control checks and limit which entities can access the feature that requires the hard-coded password. For example, a feature might only be enabled through the system console instead of through a network connection."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00713","_id":"cwe_mitigation/cwe_mitigation_00713","_rev":"_dVfOTTa--A","original_id":"259","name":"Use of Hard-coded Password","metadata":{"Phase":"Architecture and Design","Description":"\n                  For inbound authentication: apply strong one-way hashes to your passwords and store those hashes in a configuration file or database with appropriate access control. That way, theft of the file/database still requires the attacker to try to crack the password. When receiving an incoming password during authentication, take the hash of the password and compare it to the hash that you have saved.\n                  Use randomly assigned salts for each separate hash that you generate. This increases the amount of computation that an attacker needs to conduct a brute-force attack, possibly limiting the effectiveness of the rainbow table method.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00714","_id":"cwe_mitigation/cwe_mitigation_00714","_rev":"_dVfOTTe---","original_id":"259","name":"Use of Hard-coded Password","metadata":{"Phase":"Architecture and Design","Description":"\n                  For front-end to back-end connections: Three solutions are possible, although none are complete.\n                  \n                     The first suggestion involves the use of generated passwords which are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals.\n                     Next, the passwords used should be limited at the back end to only performing actions valid for the front end, as opposed to having full access.\n                     Finally, the messages sent should be tagged and checksummed with time sensitive values so as to prevent replay style attacks.\n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00717","_id":"cwe_mitigation/cwe_mitigation_00717","_rev":"_dVfOTTe--_","original_id":"260","name":"Password in Configuration File","metadata":{"Phase":"Architecture and Design","Description":"Avoid storing passwords in easily accessible locations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00718","_id":"cwe_mitigation/cwe_mitigation_00718","_rev":"_dVfOTTe--A","original_id":"260","name":"Password in Configuration File","metadata":{"Phase":"Architecture and Design","Description":"Consider storing cryptographic hashes of passwords as an alternative to storing in plaintext."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00719","_id":"cwe_mitigation/cwe_mitigation_00719","_rev":"_dVfOTTe--B","original_id":"261","name":"Weak Encoding for Password","metadata":{"Phase":"NA","Description":"Passwords should be encrypted with keys that are at least 128 bits in length for adequate security."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00720","_id":"cwe_mitigation/cwe_mitigation_00720","_rev":"_dVfOTTe--C","original_id":"262","name":"Not Using Password Aging","metadata":{"Phase":"Architecture and Design","Description":"As part of a product's design, require users to change their passwords regularly and avoid reusing previous passwords."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00721","_id":"cwe_mitigation/cwe_mitigation_00721","_rev":"_dVfOTTe--D","original_id":"263","name":"Password Aging with Long Expiration","metadata":{"Phase":"Architecture and Design","Description":"Ensure that password aging is limited so that there is a defined maximum age for passwords and so that the user is notified several times leading up to the password expiration."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00722","_id":"cwe_mitigation/cwe_mitigation_00722","_rev":"_dVfOTTe--E","original_id":"266","name":"Incorrect Privilege Assignment","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00723","_id":"cwe_mitigation/cwe_mitigation_00723","_rev":"_dVfOTTe--F","original_id":"266","name":"Incorrect Privilege Assignment","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00724","_id":"cwe_mitigation/cwe_mitigation_00724","_rev":"_dVfOTTe--G","original_id":"267","name":"Privilege Defined With Unsafe Actions","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00725","_id":"cwe_mitigation/cwe_mitigation_00725","_rev":"_dVfOTTe--H","original_id":"267","name":"Privilege Defined With Unsafe Actions","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00726","_id":"cwe_mitigation/cwe_mitigation_00726","_rev":"_dVfOTTe--I","original_id":"268","name":"Privilege Chaining","metadata":{"Phase":"Architecture and Design","Description":"Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00727","_id":"cwe_mitigation/cwe_mitigation_00727","_rev":"_dVfOTTe--J","original_id":"268","name":"Privilege Chaining","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00728","_id":"cwe_mitigation/cwe_mitigation_00728","_rev":"_dVfOTTe--K","original_id":"268","name":"Privilege Chaining","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00729","_id":"cwe_mitigation/cwe_mitigation_00729","_rev":"_dVfOTTe--L","original_id":"269","name":"Improper Privilege Management","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00730","_id":"cwe_mitigation/cwe_mitigation_00730","_rev":"_dVfOTTe--M","original_id":"269","name":"Improper Privilege Management","metadata":{"Phase":"Architecture and Design","Description":"Follow the principle of least privilege when assigning access rights to entities in a software system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00731","_id":"cwe_mitigation/cwe_mitigation_00731","_rev":"_dVfOTTe--N","original_id":"269","name":"Improper Privilege Management","metadata":{"Phase":"Architecture and Design","Description":"Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00732","_id":"cwe_mitigation/cwe_mitigation_00732","_rev":"_dVfOTTe--O","original_id":"270","name":"Privilege Context Switching Error","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00733","_id":"cwe_mitigation/cwe_mitigation_00733","_rev":"_dVfOTTe--P","original_id":"270","name":"Privilege Context Switching Error","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00734","_id":"cwe_mitigation/cwe_mitigation_00734","_rev":"_dVfOTTe--Q","original_id":"270","name":"Privilege Context Switching Error","metadata":{"Phase":"Architecture and Design","Description":"Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00735","_id":"cwe_mitigation/cwe_mitigation_00735","_rev":"_dVfOTTi---","original_id":"271","name":"Privilege Dropping / Lowering Errors","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00736","_id":"cwe_mitigation/cwe_mitigation_00736","_rev":"_dVfOTTi--_","original_id":"271","name":"Privilege Dropping / Lowering Errors","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00737","_id":"cwe_mitigation/cwe_mitigation_00737","_rev":"_dVfOTTi--A","original_id":"271","name":"Privilege Dropping / Lowering Errors","metadata":{"Phase":"Architecture and Design","Description":"Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00738","_id":"cwe_mitigation/cwe_mitigation_00738","_rev":"_dVfOTTi--B","original_id":"272","name":"Least Privilege Violation","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00739","_id":"cwe_mitigation/cwe_mitigation_00739","_rev":"_dVfOTTi--C","original_id":"272","name":"Least Privilege Violation","metadata":{"Phase":"Architecture and Design","Description":"Follow the principle of least privilege when assigning access rights to entities in a software system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00740","_id":"cwe_mitigation/cwe_mitigation_00740","_rev":"_dVfOTTi--D","original_id":"272","name":"Least Privilege Violation","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00747","_id":"cwe_mitigation/cwe_mitigation_00747","_rev":"_dVfOTTi--E","original_id":"273","name":"Improper Check for Dropped Privileges","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00748","_id":"cwe_mitigation/cwe_mitigation_00748","_rev":"_dVfOTTi--F","original_id":"273","name":"Improper Check for Dropped Privileges","metadata":{"Phase":"Implementation","Description":"Check the results of all functions that return a value and verify that the value is expected."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00749","_id":"cwe_mitigation/cwe_mitigation_00749","_rev":"_dVfOTTi--G","original_id":"273","name":"Improper Check for Dropped Privileges","metadata":{"Phase":"Implementation","Description":"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."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00750","_id":"cwe_mitigation/cwe_mitigation_00750","_rev":"_dVfOTTi--H","original_id":"276","name":"Incorrect Default Permissions","metadata":{"Phase":"Architecture and Design","Description":"The architecture needs to access and modification attributes for files to only those users who actually require those actions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00751","_id":"cwe_mitigation/cwe_mitigation_00751","_rev":"_dVfOTTi--I","original_id":"276","name":"Incorrect Default Permissions","metadata":{"Phase":"Architecture and Design","Description":"\n          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.\n          Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n        "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00760","_id":"cwe_mitigation/cwe_mitigation_00760","_rev":"_dVfOTTi--J","original_id":"277","name":"Insecure Inherited Permissions","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00761","_id":"cwe_mitigation/cwe_mitigation_00761","_rev":"_dVfOTTi--K","original_id":"277","name":"Insecure Inherited Permissions","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00762","_id":"cwe_mitigation/cwe_mitigation_00762","_rev":"_dVfOTTi--L","original_id":"278","name":"Insecure Preserved Inherited Permissions","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00763","_id":"cwe_mitigation/cwe_mitigation_00763","_rev":"_dVfOTTi--M","original_id":"278","name":"Insecure Preserved Inherited Permissions","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00764","_id":"cwe_mitigation/cwe_mitigation_00764","_rev":"_dVfOTTi--N","original_id":"279","name":"Incorrect Execution-Assigned Permissions","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00765","_id":"cwe_mitigation/cwe_mitigation_00765","_rev":"_dVfOTTi--O","original_id":"279","name":"Incorrect Execution-Assigned Permissions","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00766","_id":"cwe_mitigation/cwe_mitigation_00766","_rev":"_dVfOTTi--P","original_id":"280","name":"Improper Handling of Insufficient Permissions or Privileges ","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00767","_id":"cwe_mitigation/cwe_mitigation_00767","_rev":"_dVfOTTi--Q","original_id":"280","name":"Improper Handling of Insufficient Permissions or Privileges ","metadata":{"Phase":"Implementation","Description":"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, environments with highly granular permissions/privilege models, such as Windows or Linux capabilities, can cause unexpected failures."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00768","_id":"cwe_mitigation/cwe_mitigation_00768","_rev":"_dVfOTTi--R","original_id":"282","name":"Improper Ownership Management","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00769","_id":"cwe_mitigation/cwe_mitigation_00769","_rev":"_dVfOTTi--S","original_id":"283","name":"Unverified Ownership","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00770","_id":"cwe_mitigation/cwe_mitigation_00770","_rev":"_dVfOTTi--T","original_id":"283","name":"Unverified Ownership","metadata":{"Phase":"Architecture and Design","Description":"Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00771","_id":"cwe_mitigation/cwe_mitigation_00771","_rev":"_dVfOTTi--U","original_id":"284","name":"Improper Access Control","metadata":{"Phase":"Architecture and Design","Description":"Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00772","_id":"cwe_mitigation/cwe_mitigation_00772","_rev":"_dVfOTTi--V","original_id":"284","name":"Improper Access Control","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00773","_id":"cwe_mitigation/cwe_mitigation_00773","_rev":"_dVfOTTi--W","original_id":"285","name":"Improper Authorization","metadata":{"Phase":"Architecture and Design","Description":"\n                  Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.\n                  Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00774","_id":"cwe_mitigation/cwe_mitigation_00774","_rev":"_dVfOTTi--X","original_id":"285","name":"Improper Authorization","metadata":{"Phase":"Architecture and Design","Description":"Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00775","_id":"cwe_mitigation/cwe_mitigation_00775","_rev":"_dVfOTTi--Y","original_id":"285","name":"Improper Authorization","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00776","_id":"cwe_mitigation/cwe_mitigation_00776","_rev":"_dVfOTTi--Z","original_id":"285","name":"Improper Authorization","metadata":{"Phase":"Architecture and Design","Description":"\n                  For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.\n                  One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00777","_id":"cwe_mitigation/cwe_mitigation_00777","_rev":"_dVfOTTi--a","original_id":"285","name":"Improper Authorization","metadata":{"Phase":"System Configuration","Description":"Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a \"default deny\" policy when defining these ACLs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00787","_id":"cwe_mitigation/cwe_mitigation_00787","_rev":"_dVfOTTi--b","original_id":"287","name":"Improper Authentication","metadata":{"Phase":"Architecture and Design","Description":"Use an authentication framework or library such as the OWASP ESAPI Authentication feature."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00797","_id":"cwe_mitigation/cwe_mitigation_00797","_rev":"_dVfOTTi--c","original_id":"288","name":"Authentication Bypass Using an Alternate Path or Channel","metadata":{"Phase":"Architecture and Design","Description":"Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00798","_id":"cwe_mitigation/cwe_mitigation_00798","_rev":"_dVfOTTi--d","original_id":"289","name":"Authentication Bypass by Alternate Name","metadata":{"Phase":"Architecture and Design","Description":"Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00799","_id":"cwe_mitigation/cwe_mitigation_00799","_rev":"_dVfOTTi--e","original_id":"289","name":"Authentication Bypass by Alternate Name","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00800","_id":"cwe_mitigation/cwe_mitigation_00800","_rev":"_dVfOTTi--f","original_id":"289","name":"Authentication Bypass by Alternate Name","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00801","_id":"cwe_mitigation/cwe_mitigation_00801","_rev":"_dVfOTTi--g","original_id":"291","name":"Reliance on IP Address for Authentication","metadata":{"Phase":"Architecture and Design","Description":"Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00802","_id":"cwe_mitigation/cwe_mitigation_00802","_rev":"_dVfOTTi--h","original_id":"293","name":"Using Referer Field for Authentication","metadata":{"Phase":"Architecture and Design","Description":"In order to usefully check if a given action is authorized, some means of strong authentication and method protection must be used. Use other means of authorization that cannot be simply spoofed. Possibilities include a username/password or certificate."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00803","_id":"cwe_mitigation/cwe_mitigation_00803","_rev":"_dVfOTTi--i","original_id":"294","name":"Authentication Bypass by Capture-replay","metadata":{"Phase":"Architecture and Design","Description":"Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00804","_id":"cwe_mitigation/cwe_mitigation_00804","_rev":"_dVfOTTi--j","original_id":"294","name":"Authentication Bypass by Capture-replay","metadata":{"Phase":"Architecture and Design","Description":"Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00805","_id":"cwe_mitigation/cwe_mitigation_00805","_rev":"_dVfOTTi--k","original_id":"295","name":"Improper Certificate Validation","metadata":{"Phase":"Architecture and Design","Description":"Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00806","_id":"cwe_mitigation/cwe_mitigation_00806","_rev":"_dVfOTTi--l","original_id":"295","name":"Improper Certificate Validation","metadata":{"Phase":"Implementation","Description":"If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00814","_id":"cwe_mitigation/cwe_mitigation_00814","_rev":"_dVfOTTi--m","original_id":"296","name":"Improper Following of a Certificate's Chain of Trust","metadata":{"Phase":"Architecture and Design","Description":"Ensure that proper certificate checking is included in the system design."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00815","_id":"cwe_mitigation/cwe_mitigation_00815","_rev":"_dVfOTTi--n","original_id":"296","name":"Improper Following of a Certificate's Chain of Trust","metadata":{"Phase":"Implementation","Description":"Understand, and properly implement all checks necessary to ensure the integrity of certificate trust integrity."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00816","_id":"cwe_mitigation/cwe_mitigation_00816","_rev":"_dVfOTTi--o","original_id":"296","name":"Improper Following of a Certificate's Chain of Trust","metadata":{"Phase":"Implementation","Description":"If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the full chain of trust."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00817","_id":"cwe_mitigation/cwe_mitigation_00817","_rev":"_dVfOTTi--p","original_id":"297","name":"Improper Validation of Certificate with Host Mismatch","metadata":{"Phase":"Architecture and Design","Description":"Fully check the hostname of the certificate and provide the user with adequate information about the nature of the problem and how to proceed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00818","_id":"cwe_mitigation/cwe_mitigation_00818","_rev":"_dVfOTTi--q","original_id":"297","name":"Improper Validation of Certificate with Host Mismatch","metadata":{"Phase":"Implementation","Description":"If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00821","_id":"cwe_mitigation/cwe_mitigation_00821","_rev":"_dVfOTTi--r","original_id":"298","name":"Improper Validation of Certificate Expiration","metadata":{"Phase":"Architecture and Design","Description":"Check for expired certificates and provide the user with adequate information about the nature of the problem and how to proceed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00822","_id":"cwe_mitigation/cwe_mitigation_00822","_rev":"_dVfOTTi--s","original_id":"298","name":"Improper Validation of Certificate Expiration","metadata":{"Phase":"Implementation","Description":"If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the expiration."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00823","_id":"cwe_mitigation/cwe_mitigation_00823","_rev":"_dVfOTTi--t","original_id":"299","name":"Improper Check for Certificate Revocation","metadata":{"Phase":"Architecture and Design","Description":"Ensure that certificates are checked for revoked status."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00824","_id":"cwe_mitigation/cwe_mitigation_00824","_rev":"_dVfOTTi--u","original_id":"299","name":"Improper Check for Certificate Revocation","metadata":{"Phase":"Implementation","Description":"If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the revoked status."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00825","_id":"cwe_mitigation/cwe_mitigation_00825","_rev":"_dVfOTTi--v","original_id":"300","name":"Channel Accessible by Non-Endpoint","metadata":{"Phase":"Implementation","Description":"Always fully authenticate both ends of any communications channel."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00826","_id":"cwe_mitigation/cwe_mitigation_00826","_rev":"_dVfOTTi--w","original_id":"300","name":"Channel Accessible by Non-Endpoint","metadata":{"Phase":"Architecture and Design","Description":"Adhere to the principle of complete mediation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00827","_id":"cwe_mitigation/cwe_mitigation_00827","_rev":"_dVfOTTi--x","original_id":"300","name":"Channel Accessible by Non-Endpoint","metadata":{"Phase":"Implementation","Description":"A certificate binds an identity to a cryptographic key to authenticate a communicating party. Often, the certificate takes the encrypted form of the hash of the identity of the subject, the public key, and information such as time of issue or expiration using the issuer's private key. The certificate can be validated by deciphering the certificate with the issuer's public key. See also X.509 certificate signature chains and the PGP certification structure."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00828","_id":"cwe_mitigation/cwe_mitigation_00828","_rev":"_dVfOTTi--y","original_id":"301","name":"Reflection Attack in an Authentication Protocol","metadata":{"Phase":"Architecture and Design","Description":"Use different keys for the initiator and responder or of a different type of challenge for the initiator and responder."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00829","_id":"cwe_mitigation/cwe_mitigation_00829","_rev":"_dVfOTTi--z","original_id":"301","name":"Reflection Attack in an Authentication Protocol","metadata":{"Phase":"Architecture and Design","Description":"Let the initiator prove its identity before proceeding."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00830","_id":"cwe_mitigation/cwe_mitigation_00830","_rev":"_dVfOTTi--0","original_id":"302","name":"Authentication Bypass by Assumed-Immutable Data","metadata":{"Phase":"Architecture and Design","Description":"Implement proper protection for immutable data (e.g. environment variable, hidden form fields, etc.)"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00831","_id":"cwe_mitigation/cwe_mitigation_00831","_rev":"_dVfOTTi--1","original_id":"306","name":"Missing Authentication for Critical Function","metadata":{"Phase":"Architecture and Design","Description":"\n                  Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.\n                  Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.\n                  In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00832","_id":"cwe_mitigation/cwe_mitigation_00832","_rev":"_dVfOTTi--2","original_id":"306","name":"Missing Authentication for Critical Function","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00833","_id":"cwe_mitigation/cwe_mitigation_00833","_rev":"_dVfOTTi--3","original_id":"306","name":"Missing Authentication for Critical Function","metadata":{"Phase":"Architecture and Design","Description":"\n                  Where possible, avoid implementing custom authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These may make it easier to provide a clear separation between authentication tasks and authorization tasks.\n                  In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00834","_id":"cwe_mitigation/cwe_mitigation_00834","_rev":"_dVfOTTi--4","original_id":"306","name":"Missing Authentication for Critical Function","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00843","_id":"cwe_mitigation/cwe_mitigation_00843","_rev":"_dVfOTTi--5","original_id":"307","name":"Improper Restriction of Excessive Authentication Attempts","metadata":{"Phase":"Architecture and Design","Description":"\n                  Common protection mechanisms include:\n                  \n                     \n                        Disconnecting the user after a small number of failed attempts\n                        Implementing a timeout\n                        Locking out a targeted account\n                        Requiring a computational task on the user's part.\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00844","_id":"cwe_mitigation/cwe_mitigation_00844","_rev":"_dVfOTTi--6","original_id":"307","name":"Improper Restriction of Excessive Authentication Attempts","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  Consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator. [REF-45]\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00851","_id":"cwe_mitigation/cwe_mitigation_00851","_rev":"_dVfOTTi--7","original_id":"308","name":"Use of Single-factor Authentication","metadata":{"Phase":"Architecture and Design","Description":"Use multiple independent authentication schemes, which ensures that -- if one of the methods is compromised -- the system itself is still likely safe from compromise."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00852","_id":"cwe_mitigation/cwe_mitigation_00852","_rev":"_dVfOTTi--8","original_id":"309","name":"Use of Password System for Primary Authentication","metadata":{"Phase":"Architecture and Design","Description":"\n                  In order to protect password systems from compromise, the following should be noted:\n                  \n                     \n                        Passwords should be stored safely to prevent insider attack and to ensure that -- if a system is compromised -- the passwords are not retrievable. Due to password reuse, this information may be useful in the compromise of other systems these users work with. In order to protect these passwords, they should be stored encrypted, in a non-reversible state, such that the original text password cannot be extracted from the stored value.\n                        Password aging should be strictly enforced to ensure that passwords do not remain unchanged for long periods of time. The longer a password remains in use, the higher the probability that it has been compromised. For this reason, passwords should require refreshing periodically, and users should be informed of the risk of passwords which remain in use for too long.\n                        Password strength should be enforced intelligently. Rather than restrict passwords to specific content, or specific length, users should be encouraged to use upper and lower case letters, numbers, and symbols in their passwords. The system should also ensure that no passwords are derived from dictionary words.\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00853","_id":"cwe_mitigation/cwe_mitigation_00853","_rev":"_dVfOTTi--9","original_id":"309","name":"Use of Password System for Primary Authentication","metadata":{"Phase":"Architecture and Design","Description":"Use a zero-knowledge password protocol, such as SRP."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00854","_id":"cwe_mitigation/cwe_mitigation_00854","_rev":"_dVfOTTm---","original_id":"309","name":"Use of Password System for Primary Authentication","metadata":{"Phase":"Architecture and Design","Description":"Ensure that passwords are stored safely and are not reversible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00855","_id":"cwe_mitigation/cwe_mitigation_00855","_rev":"_dVfOTTm--_","original_id":"309","name":"Use of Password System for Primary Authentication","metadata":{"Phase":"Architecture and Design","Description":"Implement password aging functionality that requires passwords be changed after a certain point."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00856","_id":"cwe_mitigation/cwe_mitigation_00856","_rev":"_dVfOTTm--A","original_id":"309","name":"Use of Password System for Primary Authentication","metadata":{"Phase":"Architecture and Design","Description":"Use a mechanism for determining the strength of a password and notify the user of weak password use."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00857","_id":"cwe_mitigation/cwe_mitigation_00857","_rev":"_dVfOTTm--B","original_id":"309","name":"Use of Password System for Primary Authentication","metadata":{"Phase":"Architecture and Design","Description":"Inform the user of why password protections are in place, how they work to protect data integrity, and why it is important to heed their warnings."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00858","_id":"cwe_mitigation/cwe_mitigation_00858","_rev":"_dVfOTTm--C","original_id":"311","name":"Missing Encryption of Sensitive Data","metadata":{"Phase":"Requirements","Description":"Clearly specify which data or resources are valuable enough that they should be protected by encryption. Require that any transmission or storage of this data/resource should use well-vetted encryption algorithms."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00859","_id":"cwe_mitigation/cwe_mitigation_00859","_rev":"_dVfOTTm--D","original_id":"311","name":"Missing Encryption of Sensitive Data","metadata":{"Phase":"Architecture and Design","Description":"\n                  Ensure that encryption is properly integrated into the system design, including but not necessarily limited to:\n                  \n                     \n                        Encryption that is needed to store or transmit private data of the users of the system\n                        Encryption that is needed to protect the system itself from unauthorized disclosure or tampering\n                     \n                  \n                  Identify the separate needs and contexts for encryption:\n                  \n                     \n                        One-way (i.e., only the user or recipient needs to have the key). This can be achieved using public key cryptography, or other techniques in which the encrypting party (i.e., the software) does not need to have access to a private key.\n                        Two-way (i.e., the encryption can be automatically performed on behalf of a user, but the key must be available so that the plaintext can be automatically recoverable by that user). This requires storage of the private key in a format that is recoverable only by the user (or perhaps by the operating system) in a way that cannot be recovered by others.\n                     \n                  \n                  Using threat modeling or other techniques, assume that data can be compromised through a separate vulnerability or weakness, and determine where encryption will be most effective. Ensure that data that should be private is not being inadvertently exposed using weaknesses such as insecure permissions (CWE-732). [REF-7]\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00860","_id":"cwe_mitigation/cwe_mitigation_00860","_rev":"_dVfOTTm--E","original_id":"311","name":"Missing Encryption of Sensitive Data","metadata":{"Phase":"Architecture and Design","Description":"\n                  When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.\n                  For example, US government systems require FIPS 140-2 certification.\n                  Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak.\n                  Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267]\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00861","_id":"cwe_mitigation/cwe_mitigation_00861","_rev":"_dVfOTTm--F","original_id":"311","name":"Missing Encryption of Sensitive Data","metadata":{"Phase":"Architecture and Design","Description":"\n                  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.\n                  Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00862","_id":"cwe_mitigation/cwe_mitigation_00862","_rev":"_dVfOTTm--G","original_id":"311","name":"Missing Encryption of Sensitive Data","metadata":{"Phase":"Implementation","Description":"When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00863","_id":"cwe_mitigation/cwe_mitigation_00863","_rev":"_dVfOTTm--H","original_id":"311","name":"Missing Encryption of Sensitive Data","metadata":{"Phase":"Implementation","Description":"Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00872","_id":"cwe_mitigation/cwe_mitigation_00872","_rev":"_dVfOTTm--I","original_id":"319","name":"Cleartext Transmission of Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"Encrypt the data with a reliable encryption scheme before transmitting."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00873","_id":"cwe_mitigation/cwe_mitigation_00873","_rev":"_dVfOTTm--J","original_id":"319","name":"Cleartext Transmission of Sensitive Information","metadata":{"Phase":"Implementation","Description":"When using web applications with SSL, use SSL for the entire session from login to logout, not just for the initial login page."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00874","_id":"cwe_mitigation/cwe_mitigation_00874","_rev":"_dVfOTTm--K","original_id":"319","name":"Cleartext Transmission of Sensitive Information","metadata":{"Phase":"Testing","Description":"Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00875","_id":"cwe_mitigation/cwe_mitigation_00875","_rev":"_dVfOTTm--L","original_id":"319","name":"Cleartext Transmission of Sensitive Information","metadata":{"Phase":"Operation","Description":"Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00877","_id":"cwe_mitigation/cwe_mitigation_00877","_rev":"_dVfOTTm--M","original_id":"321","name":"Use of Hard-coded Cryptographic Key","metadata":{"Phase":"Architecture and Design","Description":"Prevention schemes mirror that of hard-coded password storage."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00878","_id":"cwe_mitigation/cwe_mitigation_00878","_rev":"_dVfOTTm--N","original_id":"322","name":"Key Exchange without Entity Authentication","metadata":{"Phase":"Architecture and Design","Description":"Ensure that proper authentication is included in the system design."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00879","_id":"cwe_mitigation/cwe_mitigation_00879","_rev":"_dVfOTTm--O","original_id":"322","name":"Key Exchange without Entity Authentication","metadata":{"Phase":"Implementation","Description":"Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00880","_id":"cwe_mitigation/cwe_mitigation_00880","_rev":"_dVfOTTm--P","original_id":"323","name":"Reusing a Nonce, Key Pair in Encryption","metadata":{"Phase":"Implementation","Description":"Refuse to reuse nonce values."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00881","_id":"cwe_mitigation/cwe_mitigation_00881","_rev":"_dVfOTTm--Q","original_id":"323","name":"Reusing a Nonce, Key Pair in Encryption","metadata":{"Phase":"Implementation","Description":"Use techniques such as requiring incrementing, time based and/or challenge response to assure uniqueness of nonces."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00882","_id":"cwe_mitigation/cwe_mitigation_00882","_rev":"_dVfOTTm--R","original_id":"324","name":"Use of a Key Past its Expiration Date","metadata":{"Phase":"Architecture and Design","Description":"Adequate consideration should be put in to the user interface in order to notify users previous to the key's expiration, to explain the importance of new key generation and to walk users through the process as painlessly as possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00883","_id":"cwe_mitigation/cwe_mitigation_00883","_rev":"_dVfOTTm--S","original_id":"326","name":"Inadequate Encryption Strength","metadata":{"Phase":"Architecture and Design","Description":"Use an encryption scheme that is currently considered to be strong by experts in the field."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00884","_id":"cwe_mitigation/cwe_mitigation_00884","_rev":"_dVfOTTm--T","original_id":"327","name":"Use of a Broken or Risky Cryptographic Algorithm","metadata":{"Phase":"Architecture and Design","Description":"\n                  When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis.\n                  For example, US government systems require FIPS 140-2 certification.\n                  Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak.\n                  Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267]\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00885","_id":"cwe_mitigation/cwe_mitigation_00885","_rev":"_dVfOTTm--U","original_id":"327","name":"Use of a Broken or Risky Cryptographic Algorithm","metadata":{"Phase":"Architecture and Design","Description":"Ensure that the design allows one cryptographic algorithm can be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00886","_id":"cwe_mitigation/cwe_mitigation_00886","_rev":"_dVfOTTm--V","original_id":"327","name":"Use of a Broken or Risky Cryptographic Algorithm","metadata":{"Phase":"Architecture and Design","Description":"Carefully manage and protect cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography itself is irrelevant."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00887","_id":"cwe_mitigation/cwe_mitigation_00887","_rev":"_dVfOTTm--W","original_id":"327","name":"Use of a Broken or Risky Cryptographic Algorithm","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  Industry-standard implementations will save development time and may be more likely to avoid errors that can occur during implementation of cryptographic algorithms. Consider the ESAPI Encryption feature.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00888","_id":"cwe_mitigation/cwe_mitigation_00888","_rev":"_dVfOTTm--X","original_id":"327","name":"Use of a Broken or Risky Cryptographic Algorithm","metadata":{"Phase":"Implementation","Description":"When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00899","_id":"cwe_mitigation/cwe_mitigation_00899","_rev":"_dVfOTTm--Y","original_id":"328","name":"Use of Weak Hash","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations (\"stretching\") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use.\n                  Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead.\n                  Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00900","_id":"cwe_mitigation/cwe_mitigation_00900","_rev":"_dVfOTTm--Z","original_id":"329","name":"Generation of Predictable IV with CBC Mode","metadata":{"Phase":"Implementation","Description":"NIST recommends two methods of generating unpredictable IVs for CBC mode [REF-1172]. The first is to generate the IV randomly. The second method is to encrypt a nonce with the same key and cipher to be used to encrypt the plaintext. In this case the nonce must be unique but can be predictable, since the block cipher will act as a pseudo random permutation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00901","_id":"cwe_mitigation/cwe_mitigation_00901","_rev":"_dVfOTTm--a","original_id":"330","name":"Use of Insufficiently Random Values","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a well-vetted algorithm that is currently considered to be strong by experts in the field, and select well-tested implementations with adequate length seeds.\n                  In general, if a pseudo-random number generator is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts.\n                  Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a \"random enough\" number.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00902","_id":"cwe_mitigation/cwe_mitigation_00902","_rev":"_dVfOTTm--b","original_id":"330","name":"Use of Insufficiently Random Values","metadata":{"Phase":"Implementation","Description":"Consider a PRNG that re-seeds itself as needed from high quality pseudo-random output sources, such as hardware devices."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00903","_id":"cwe_mitigation/cwe_mitigation_00903","_rev":"_dVfOTTm--c","original_id":"330","name":"Use of Insufficiently Random Values","metadata":{"Phase":"Testing","Description":"Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00904","_id":"cwe_mitigation/cwe_mitigation_00904","_rev":"_dVfOTTm--d","original_id":"330","name":"Use of Insufficiently Random Values","metadata":{"Phase":"Architecture and Design","Description":"Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C (\"Approved Random Number Generators\")."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00905","_id":"cwe_mitigation/cwe_mitigation_00905","_rev":"_dVfOTTm--e","original_id":"330","name":"Use of Insufficiently Random Values","metadata":{"Phase":"Testing","Description":"Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00913","_id":"cwe_mitigation/cwe_mitigation_00913","_rev":"_dVfOTTm--f","original_id":"331","name":"Insufficient Entropy","metadata":{"Phase":"Implementation","Description":"Determine the necessary entropy to adequately provide for randomness and predictability. This can be achieved by increasing the number of bits of objects such as keys and seeds."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00914","_id":"cwe_mitigation/cwe_mitigation_00914","_rev":"_dVfOTTm--g","original_id":"332","name":"Insufficient Entropy in PRNG","metadata":{"Phase":"Architecture and Design","Description":"Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C (\"Approved Random Number Generators\")."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00915","_id":"cwe_mitigation/cwe_mitigation_00915","_rev":"_dVfOTTm--h","original_id":"332","name":"Insufficient Entropy in PRNG","metadata":{"Phase":"Implementation","Description":"Consider a PRNG that re-seeds itself as needed from high-quality pseudo-random output, such as hardware devices."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00916","_id":"cwe_mitigation/cwe_mitigation_00916","_rev":"_dVfOTTm--i","original_id":"332","name":"Insufficient Entropy in PRNG","metadata":{"Phase":"Architecture and Design","Description":"When deciding which PRNG to use, look at its sources of entropy. Depending on what your security needs are, you may need to use a random number generator that always uses strong random data -- i.e., a random number generator that attempts to be strong but will fail in a weak way or will always provide some middle ground of protection through techniques like re-seeding. Generally, something that always provides a predictable amount of strength is preferable."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00917","_id":"cwe_mitigation/cwe_mitigation_00917","_rev":"_dVfOTTm--j","original_id":"333","name":"Improper Handling of Insufficient Entropy in TRNG","metadata":{"Phase":"Implementation","Description":"Rather than failing on a lack of random numbers, it is often preferable to wait for more numbers to be created."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00918","_id":"cwe_mitigation/cwe_mitigation_00918","_rev":"_dVfOTTm--k","original_id":"334","name":"Small Space of Random Values","metadata":{"Phase":"Architecture and Design","Description":"Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C (\"Approved Random Number Generators\")."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00919","_id":"cwe_mitigation/cwe_mitigation_00919","_rev":"_dVfOTTm--l","original_id":"336","name":"Same Seed in Pseudo-Random Number Generator (PRNG)","metadata":{"Phase":"Architecture and Design","Description":"Do not reuse PRNG seeds. Consider a PRNG that periodically re-seeds itself as needed from a high quality pseudo-random output, such as hardware devices."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00920","_id":"cwe_mitigation/cwe_mitigation_00920","_rev":"_dVfOTTm--m","original_id":"336","name":"Same Seed in Pseudo-Random Number Generator (PRNG)","metadata":{"Phase":"Architecture and Design","Description":"Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems, or use the more recent FIPS 140-3 [REF-1192] if possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00921","_id":"cwe_mitigation/cwe_mitigation_00921","_rev":"_dVfOTTm--n","original_id":"337","name":"Predictable Seed in Pseudo-Random Number Generator (PRNG)","metadata":{"Phase":"NA","Description":"Use non-predictable inputs for seed generation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00922","_id":"cwe_mitigation/cwe_mitigation_00922","_rev":"_dVfOTTm--o","original_id":"337","name":"Predictable Seed in Pseudo-Random Number Generator (PRNG)","metadata":{"Phase":"Architecture and Design","Description":"Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems, or use the more recent FIPS 140-3 [REF-1192] if possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00923","_id":"cwe_mitigation/cwe_mitigation_00923","_rev":"_dVfOTTm--p","original_id":"337","name":"Predictable Seed in Pseudo-Random Number Generator (PRNG)","metadata":{"Phase":"Implementation","Description":"Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00924","_id":"cwe_mitigation/cwe_mitigation_00924","_rev":"_dVfOTTm--q","original_id":"338","name":"Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)","metadata":{"Phase":"Implementation","Description":"Use functions or hardware which use a hardware-based random number generation for all crypto. This is the recommended solution. Use CyptGenRandom on Windows, or hw_rand() on Linux."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00925","_id":"cwe_mitigation/cwe_mitigation_00925","_rev":"_dVfOTTm--r","original_id":"339","name":"Small Seed Space in PRNG","metadata":{"Phase":"Architecture and Design","Description":"Use well vetted pseudo-random number generating algorithms with adequate length seeds. Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a \"random enough\" number."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00926","_id":"cwe_mitigation/cwe_mitigation_00926","_rev":"_dVfOTTm--s","original_id":"339","name":"Small Seed Space in PRNG","metadata":{"Phase":"Architecture and Design","Description":"Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems, or use the more recent FIPS 140-3 [REF-1192] if possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00927","_id":"cwe_mitigation/cwe_mitigation_00927","_rev":"_dVfOTTm--t","original_id":"341","name":"Predictable from Observable State","metadata":{"Phase":"Implementation","Description":"Increase the entropy used to seed a PRNG."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00928","_id":"cwe_mitigation/cwe_mitigation_00928","_rev":"_dVfOTTm--u","original_id":"341","name":"Predictable from Observable State","metadata":{"Phase":"Architecture and Design","Description":"Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C (\"Approved Random Number Generators\")."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00929","_id":"cwe_mitigation/cwe_mitigation_00929","_rev":"_dVfOTTm--v","original_id":"341","name":"Predictable from Observable State","metadata":{"Phase":"Implementation","Description":"Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00930","_id":"cwe_mitigation/cwe_mitigation_00930","_rev":"_dVfOTTm--w","original_id":"342","name":"Predictable Exact Value from Previous Values","metadata":{"Phase":"NA","Description":"Increase the entropy used to seed a PRNG."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00931","_id":"cwe_mitigation/cwe_mitigation_00931","_rev":"_dVfOTTm--x","original_id":"342","name":"Predictable Exact Value from Previous Values","metadata":{"Phase":"Architecture and Design","Description":"Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C (\"Approved Random Number Generators\")."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00932","_id":"cwe_mitigation/cwe_mitigation_00932","_rev":"_dVfOTTm--y","original_id":"342","name":"Predictable Exact Value from Previous Values","metadata":{"Phase":"Implementation","Description":"Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00933","_id":"cwe_mitigation/cwe_mitigation_00933","_rev":"_dVfOTTm--z","original_id":"343","name":"Predictable Value Range from Previous Values","metadata":{"Phase":"NA","Description":"Increase the entropy used to seed a PRNG."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00934","_id":"cwe_mitigation/cwe_mitigation_00934","_rev":"_dVfOTTm--0","original_id":"343","name":"Predictable Value Range from Previous Values","metadata":{"Phase":"Architecture and Design","Description":"Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C (\"Approved Random Number Generators\")."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00935","_id":"cwe_mitigation/cwe_mitigation_00935","_rev":"_dVfOTTm--1","original_id":"343","name":"Predictable Value Range from Previous Values","metadata":{"Phase":"Implementation","Description":"Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00936","_id":"cwe_mitigation/cwe_mitigation_00936","_rev":"_dVfOTTm--2","original_id":"350","name":"Reliance on Reverse DNS Resolution for a Security-Critical Action","metadata":{"Phase":"Architecture and Design","Description":"Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00937","_id":"cwe_mitigation/cwe_mitigation_00937","_rev":"_dVfOTTm--3","original_id":"350","name":"Reliance on Reverse DNS Resolution for a Security-Critical Action","metadata":{"Phase":"Implementation","Description":"Perform proper forward and reverse DNS lookups to detect DNS spoofing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00938","_id":"cwe_mitigation/cwe_mitigation_00938","_rev":"_dVfOTTm--4","original_id":"352","name":"Cross-Site Request Forgery (CSRF)","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, use anti-CSRF packages such as the OWASP CSRFGuard. [REF-330]\n                  Another example is the ESAPI Session Management control, which includes a component for CSRF. [REF-45]\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00939","_id":"cwe_mitigation/cwe_mitigation_00939","_rev":"_dVfOTTm--5","original_id":"352","name":"Cross-Site Request Forgery (CSRF)","metadata":{"Phase":"Implementation","Description":"Ensure that the application is free of cross-site scripting issues (CWE-79), because most CSRF defenses can be bypassed using attacker-controlled script."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00940","_id":"cwe_mitigation/cwe_mitigation_00940","_rev":"_dVfOTTm--6","original_id":"352","name":"Cross-Site Request Forgery (CSRF)","metadata":{"Phase":"Architecture and Design","Description":"Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330). [REF-332]"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00941","_id":"cwe_mitigation/cwe_mitigation_00941","_rev":"_dVfOTTm--7","original_id":"352","name":"Cross-Site Request Forgery (CSRF)","metadata":{"Phase":"Architecture and Design","Description":"Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00942","_id":"cwe_mitigation/cwe_mitigation_00942","_rev":"_dVfOTTm--8","original_id":"352","name":"Cross-Site Request Forgery (CSRF)","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use the \"double-submitted cookie\" method as described by Felten and Zeller:\n                  When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user's machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same.\n                  Because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult.\n                  This technique requires Javascript, so it may not work for browsers that have Javascript disabled. [REF-331]\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00943","_id":"cwe_mitigation/cwe_mitigation_00943","_rev":"_dVfOTTm--9","original_id":"352","name":"Cross-Site Request Forgery (CSRF)","metadata":{"Phase":"Architecture and Design","Description":"Do not use the GET method for any request that triggers a state change."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00944","_id":"cwe_mitigation/cwe_mitigation_00944","_rev":"_dVfOTTm-_-","original_id":"352","name":"Cross-Site Request Forgery (CSRF)","metadata":{"Phase":"Implementation","Description":"Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00954","_id":"cwe_mitigation/cwe_mitigation_00954","_rev":"_dVfOTTm-__","original_id":"353","name":"Missing Support for Integrity Check","metadata":{"Phase":"Architecture and Design","Description":"Add an appropriately sized checksum to the protocol, ensuring that data received may be simply validated before it is parsed and used."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00955","_id":"cwe_mitigation/cwe_mitigation_00955","_rev":"_dVfOTTm-_A","original_id":"353","name":"Missing Support for Integrity Check","metadata":{"Phase":"Implementation","Description":"Ensure that the checksums present in the protocol design are properly implemented and added to each message before it is sent."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00956","_id":"cwe_mitigation/cwe_mitigation_00956","_rev":"_dVfOTTm-_B","original_id":"354","name":"Improper Validation of Integrity Check Value","metadata":{"Phase":"Implementation","Description":"Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00957","_id":"cwe_mitigation/cwe_mitigation_00957","_rev":"_dVfOTTm-_C","original_id":"359","name":"Exposure of Private Personal Information to an Unauthorized Actor","metadata":{"Phase":"Requirements","Description":"\n            Identify and consult all relevant regulations for personal privacy.  An organization may be required to comply with certain federal and state regulations, depending on its location, the type of business it conducts, and the nature of any private data it handles.  Regulations may include Safe Harbor Privacy Framework [REF-340], Gramm-Leach Bliley Act (GLBA) [REF-341], Health Insurance Portability and Accountability Act (HIPAA) [REF-342], General Data Protection Regulation (GDPR) [REF-1047], California Consumer Privacy Act (CCPA) [REF-1048], and others.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00958","_id":"cwe_mitigation/cwe_mitigation_00958","_rev":"_dVfOTTm-_D","original_id":"359","name":"Exposure of Private Personal Information to an Unauthorized Actor","metadata":{"Phase":"Architecture and Design","Description":"\n            Carefully evaluate how secure design may interfere with privacy, and vice versa.  Security and privacy concerns often seem to compete with each other. From a security perspective, all important operations should be recorded so that any anomalous activity can later be identified. However, when private data is involved, this practice can in fact create risk. Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, this does not guarantee that the individuals who do have access can be trusted.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00960","_id":"cwe_mitigation/cwe_mitigation_00960","_rev":"_dVfOTTm-_E","original_id":"360","name":"Trust of System Event Data","metadata":{"Phase":"Architecture and Design","Description":"Never trust or rely any of the information in an Event for security."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00961","_id":"cwe_mitigation/cwe_mitigation_00961","_rev":"_dVfOTTq---","original_id":"362","name":"Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')","metadata":{"Phase":"Architecture and Design","Description":"In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00962","_id":"cwe_mitigation/cwe_mitigation_00962","_rev":"_dVfOTTq--_","original_id":"362","name":"Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')","metadata":{"Phase":"Architecture and Design","Description":"Use thread-safe capabilities such as the data access abstraction in Spring."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00963","_id":"cwe_mitigation/cwe_mitigation_00963","_rev":"_dVfOTTq--A","original_id":"362","name":"Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring.\n                  Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00964","_id":"cwe_mitigation/cwe_mitigation_00964","_rev":"_dVfOTTq--B","original_id":"362","name":"Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')","metadata":{"Phase":"Implementation","Description":"When using multithreading and operating on shared variables, only use thread-safe functions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00965","_id":"cwe_mitigation/cwe_mitigation_00965","_rev":"_dVfOTTq--C","original_id":"362","name":"Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')","metadata":{"Phase":"Implementation","Description":"Use atomic operations on shared variables. Be wary of innocent-looking constructs such as \"x++\". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00966","_id":"cwe_mitigation/cwe_mitigation_00966","_rev":"_dVfOTTq--D","original_id":"362","name":"Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')","metadata":{"Phase":"Implementation","Description":"Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00967","_id":"cwe_mitigation/cwe_mitigation_00967","_rev":"_dVfOTTq--E","original_id":"362","name":"Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')","metadata":{"Phase":"Implementation","Description":"Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00968","_id":"cwe_mitigation/cwe_mitigation_00968","_rev":"_dVfOTTq--F","original_id":"362","name":"Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')","metadata":{"Phase":"Implementation","Description":"Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00969","_id":"cwe_mitigation/cwe_mitigation_00969","_rev":"_dVfOTTq--G","original_id":"362","name":"Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')","metadata":{"Phase":"Implementation","Description":"Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00970","_id":"cwe_mitigation/cwe_mitigation_00970","_rev":"_dVfOTTq--H","original_id":"362","name":"Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00980","_id":"cwe_mitigation/cwe_mitigation_00980","_rev":"_dVfOTTq--I","original_id":"364","name":"Signal Handler Race Condition","metadata":{"Phase":"Requirements","Description":"Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00981","_id":"cwe_mitigation/cwe_mitigation_00981","_rev":"_dVfOTTq--J","original_id":"364","name":"Signal Handler Race Condition","metadata":{"Phase":"Architecture and Design","Description":"Design signal handlers to only set flags, rather than perform complex functionality. These flags can then be checked and acted upon within the main program loop."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00982","_id":"cwe_mitigation/cwe_mitigation_00982","_rev":"_dVfOTTq--K","original_id":"364","name":"Signal Handler Race Condition","metadata":{"Phase":"Implementation","Description":"Only use reentrant functions within signal handlers. Also, use validation to ensure that state is consistent while performing asynchronous actions that affect the state of execution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00983","_id":"cwe_mitigation/cwe_mitigation_00983","_rev":"_dVfOTTq--L","original_id":"365","name":"Race Condition in Switch","metadata":{"Phase":"Implementation","Description":"Variables that may be subject to race conditions should be locked before the switch statement starts and only unlocked after the statement ends."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00984","_id":"cwe_mitigation/cwe_mitigation_00984","_rev":"_dVfOTTq--M","original_id":"366","name":"Race Condition within a Thread","metadata":{"Phase":"Architecture and Design","Description":"Use locking functionality. This is the recommended solution. Implement some form of locking mechanism around code which alters or reads persistent data in a multithreaded environment."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00985","_id":"cwe_mitigation/cwe_mitigation_00985","_rev":"_dVfOTTq--N","original_id":"366","name":"Race Condition within a Thread","metadata":{"Phase":"Architecture and Design","Description":"Create resource-locking validation checks. If no inherent locking mechanisms exist, use flags and signals to enforce your own blocking scheme when resources are being used by other threads of execution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00986","_id":"cwe_mitigation/cwe_mitigation_00986","_rev":"_dVfOTTq--O","original_id":"367","name":"Time-of-check Time-of-use (TOCTOU) Race Condition","metadata":{"Phase":"Implementation","Description":"The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00987","_id":"cwe_mitigation/cwe_mitigation_00987","_rev":"_dVfOTTq--P","original_id":"367","name":"Time-of-check Time-of-use (TOCTOU) Race Condition","metadata":{"Phase":"Implementation","Description":"When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00988","_id":"cwe_mitigation/cwe_mitigation_00988","_rev":"_dVfOTTq--Q","original_id":"367","name":"Time-of-check Time-of-use (TOCTOU) Race Condition","metadata":{"Phase":"Architecture and Design","Description":"Limit the interleaving of operations on files from multiple processes."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00989","_id":"cwe_mitigation/cwe_mitigation_00989","_rev":"_dVfOTTq--R","original_id":"367","name":"Time-of-check Time-of-use (TOCTOU) Race Condition","metadata":{"Phase":"Implementation","Description":"If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00990","_id":"cwe_mitigation/cwe_mitigation_00990","_rev":"_dVfOTTq--S","original_id":"367","name":"Time-of-check Time-of-use (TOCTOU) Race Condition","metadata":{"Phase":"Implementation","Description":"Recheck the resource after the use call to verify that the action was taken appropriately."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00991","_id":"cwe_mitigation/cwe_mitigation_00991","_rev":"_dVfOTTq--T","original_id":"367","name":"Time-of-check Time-of-use (TOCTOU) Race Condition","metadata":{"Phase":"Architecture and Design","Description":"Ensure that some environmental locking mechanism can be used to protect resources effectively."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00992","_id":"cwe_mitigation/cwe_mitigation_00992","_rev":"_dVfOTTq--U","original_id":"367","name":"Time-of-check Time-of-use (TOCTOU) Race Condition","metadata":{"Phase":"Implementation","Description":"Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00993","_id":"cwe_mitigation/cwe_mitigation_00993","_rev":"_dVfOTTq--V","original_id":"370","name":"Missing Check for Certificate Revocation after Initial Check","metadata":{"Phase":"Architecture and Design","Description":"Ensure that certificates are checked for revoked status before each use of a protected resource. If the certificate is checked before each access of a protected resource, the delay subject to a possible race condition becomes almost negligible and significantly reduces the risk associated with this issue."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00994","_id":"cwe_mitigation/cwe_mitigation_00994","_rev":"_dVfOTTq--W","original_id":"374","name":"Passing Mutable Objects to an Untrusted Method","metadata":{"Phase":"Implementation","Description":"Pass in data which should not be altered as constant or immutable."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00995","_id":"cwe_mitigation/cwe_mitigation_00995","_rev":"_dVfOTTq--X","original_id":"374","name":"Passing Mutable Objects to an Untrusted Method","metadata":{"Phase":"Implementation","Description":"Clone all mutable data before passing it into an external function . This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00996","_id":"cwe_mitigation/cwe_mitigation_00996","_rev":"_dVfOTTq--Y","original_id":"375","name":"Returning a Mutable Object to an Untrusted Caller","metadata":{"Phase":"Implementation","Description":"Declare returned data which should not be altered as constant or immutable."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00997","_id":"cwe_mitigation/cwe_mitigation_00997","_rev":"_dVfOTTq--Z","original_id":"375","name":"Returning a Mutable Object to an Untrusted Caller","metadata":{"Phase":"Implementation","Description":"Clone all mutable data before returning references to it. This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00998","_id":"cwe_mitigation/cwe_mitigation_00998","_rev":"_dVfOTTq--a","original_id":"378","name":"Creation of Temporary File With Insecure Permissions","metadata":{"Phase":"Requirements","Description":"Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_00999","_id":"cwe_mitigation/cwe_mitigation_00999","_rev":"_dVfOTTq--b","original_id":"378","name":"Creation of Temporary File With Insecure Permissions","metadata":{"Phase":"Implementation","Description":"Ensure that you use proper file permissions. This can be achieved by using a safe temp file function. Temporary files should be writable and readable only by the process that owns the file."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01000","_id":"cwe_mitigation/cwe_mitigation_01000","_rev":"_dVfOTTq--c","original_id":"378","name":"Creation of Temporary File With Insecure Permissions","metadata":{"Phase":"Implementation","Description":"Randomize temporary file names. This can also be achieved by using a safe temp-file function. This will ensure that temporary files will not be created in predictable places."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01001","_id":"cwe_mitigation/cwe_mitigation_01001","_rev":"_dVfOTTq--d","original_id":"379","name":"Creation of Temporary File in Directory with Insecure Permissions","metadata":{"Phase":"Requirements","Description":"Many contemporary languages have functions which properly handle this condition. Older C temp file functions are especially susceptible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01002","_id":"cwe_mitigation/cwe_mitigation_01002","_rev":"_dVfOTTq--e","original_id":"379","name":"Creation of Temporary File in Directory with Insecure Permissions","metadata":{"Phase":"Implementation","Description":"Try to store sensitive tempfiles in a directory which is not world readable -- i.e., per-user directories."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01003","_id":"cwe_mitigation/cwe_mitigation_01003","_rev":"_dVfOTTq--f","original_id":"379","name":"Creation of Temporary File in Directory with Insecure Permissions","metadata":{"Phase":"Implementation","Description":"Avoid using vulnerable temp file functions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01004","_id":"cwe_mitigation/cwe_mitigation_01004","_rev":"_dVfOTTq--g","original_id":"382","name":"J2EE Bad Practices: Use of System.exit()","metadata":{"Phase":"Architecture and Design","Description":"The shutdown function should be a privileged function available only to a properly authorized administrative user"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01005","_id":"cwe_mitigation/cwe_mitigation_01005","_rev":"_dVfOTTq--h","original_id":"382","name":"J2EE Bad Practices: Use of System.exit()","metadata":{"Phase":"Implementation","Description":"Web applications should not call methods that cause the virtual machine to exit, such as System.exit()"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01006","_id":"cwe_mitigation/cwe_mitigation_01006","_rev":"_dVfOTTq--i","original_id":"382","name":"J2EE Bad Practices: Use of System.exit()","metadata":{"Phase":"Implementation","Description":"Web applications should also not throw any Throwables to the application server as this may adversely affect the container."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01007","_id":"cwe_mitigation/cwe_mitigation_01007","_rev":"_dVfOTTq--j","original_id":"382","name":"J2EE Bad Practices: Use of System.exit()","metadata":{"Phase":"Implementation","Description":"Non-web applications may have a main() method that contains a System.exit(), but generally should not call System.exit() from other locations in the code"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01008","_id":"cwe_mitigation/cwe_mitigation_01008","_rev":"_dVfOTTq--k","original_id":"383","name":"J2EE Bad Practices: Direct Use of Threads","metadata":{"Phase":"Architecture and Design","Description":"For EJB, use framework approaches for parallel execution, instead of using threads."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01009","_id":"cwe_mitigation/cwe_mitigation_01009","_rev":"_dVfOTTq--l","original_id":"384","name":"Session Fixation","metadata":{"Phase":"Architecture and Design","Description":"Invalidate any existing session identifiers prior to authorizing a new user session."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01010","_id":"cwe_mitigation/cwe_mitigation_01010","_rev":"_dVfOTTq--m","original_id":"384","name":"Session Fixation","metadata":{"Phase":"Architecture and Design","Description":"For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01011","_id":"cwe_mitigation/cwe_mitigation_01011","_rev":"_dVfOTTq--n","original_id":"385","name":"Covert Timing Channel","metadata":{"Phase":"Architecture and Design","Description":"Whenever possible, specify implementation strategies that do not introduce time variances in operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01012","_id":"cwe_mitigation/cwe_mitigation_01012","_rev":"_dVfOTTq--o","original_id":"385","name":"Covert Timing Channel","metadata":{"Phase":"Implementation","Description":"Often one can artificially manipulate the time which operations take or -- when operations occur -- can remove information from the attacker."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01013","_id":"cwe_mitigation/cwe_mitigation_01013","_rev":"_dVfOTTq--p","original_id":"385","name":"Covert Timing Channel","metadata":{"Phase":"Implementation","Description":"It is reasonable to add artificial or random delays so that the amount of CPU time consumed is independent of the action being taken by the application."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01014","_id":"cwe_mitigation/cwe_mitigation_01014","_rev":"_dVfOTTq--q","original_id":"390","name":"Detection of Error Condition Without Action","metadata":{"Phase":"Implementation","Description":"Properly handle each exception. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01015","_id":"cwe_mitigation/cwe_mitigation_01015","_rev":"_dVfOTTq--r","original_id":"390","name":"Detection of Error Condition Without Action","metadata":{"Phase":"Implementation","Description":"If a function returns an error, it is important to either fix the problem and try again, alert the user that an error has happened and let the program continue, or alert the user and close and cleanup the program."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01016","_id":"cwe_mitigation/cwe_mitigation_01016","_rev":"_dVfOTTq--s","original_id":"390","name":"Detection of Error Condition Without Action","metadata":{"Phase":"Testing","Description":"Subject the software to extensive testing to discover some of the possible instances of where/how errors or return values are not handled. Consider testing techniques such as ad hoc, equivalence partitioning, robustness and fault tolerance, mutation, and fuzzing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01017","_id":"cwe_mitigation/cwe_mitigation_01017","_rev":"_dVfOTTq--t","original_id":"391","name":"Unchecked Error Condition","metadata":{"Phase":"Requirements","Description":"The choice between a language which has named or unnamed exceptions needs to be done. While unnamed exceptions exacerbate the chance of not properly dealing with an exception, named exceptions suffer from the up call version of the weak base class problem."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01018","_id":"cwe_mitigation/cwe_mitigation_01018","_rev":"_dVfOTTq--u","original_id":"391","name":"Unchecked Error Condition","metadata":{"Phase":"Requirements","Description":"A language can be used which requires, at compile time, to catch all serious exceptions. However, one must make sure to use the most current version of the API as new exceptions could be added."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01019","_id":"cwe_mitigation/cwe_mitigation_01019","_rev":"_dVfOTTq--v","original_id":"391","name":"Unchecked Error Condition","metadata":{"Phase":"Implementation","Description":"Catch all relevant exceptions. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01020","_id":"cwe_mitigation/cwe_mitigation_01020","_rev":"_dVfOTTq--w","original_id":"395","name":"Use of NullPointerException Catch to Detect NULL Pointer Dereference","metadata":{"Phase":"Architecture and Design","Description":"Do not extensively rely on catching exceptions (especially for validating user input) to handle errors. Handling exceptions can decrease the performance of an application."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01026","_id":"cwe_mitigation/cwe_mitigation_01026","_rev":"_dVfOTTq--x","original_id":"400","name":"Uncontrolled Resource Consumption","metadata":{"Phase":"Architecture and Design","Description":"Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01027","_id":"cwe_mitigation/cwe_mitigation_01027","_rev":"_dVfOTTq--y","original_id":"400","name":"Uncontrolled Resource Consumption","metadata":{"Phase":"Architecture and Design","Description":"\n                  Mitigation of resource exhaustion attacks requires that the target system either:\n                  \n                     \n                        recognizes the attack and denies that user further access for a given amount of time, or\n                        uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.\n                     \n                  \n                  The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.\n                  The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01028","_id":"cwe_mitigation/cwe_mitigation_01028","_rev":"_dVfOTTq--z","original_id":"400","name":"Uncontrolled Resource Consumption","metadata":{"Phase":"Architecture and Design","Description":"Ensure that protocols have specific limits of scale placed on them."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01029","_id":"cwe_mitigation/cwe_mitigation_01029","_rev":"_dVfOTTq--0","original_id":"400","name":"Uncontrolled Resource Consumption","metadata":{"Phase":"Implementation","Description":"Ensure that all failures in resource allocation place the system into a safe posture."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01033","_id":"cwe_mitigation/cwe_mitigation_01033","_rev":"_dVfOTTq--1","original_id":"401","name":"Missing Release of Memory after Effective Lifetime","metadata":{"Phase":"Implementation","Description":"\n                  Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.\n                  For example, glibc in Linux provides protection against free of invalid pointers.\n                  When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].\n                  To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01034","_id":"cwe_mitigation/cwe_mitigation_01034","_rev":"_dVfOTTq--2","original_id":"401","name":"Missing Release of Memory after Effective Lifetime","metadata":{"Phase":"Architecture and Design","Description":"Use an abstraction library to abstract away risky APIs. Not a complete solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01035","_id":"cwe_mitigation/cwe_mitigation_01035","_rev":"_dVfOTTq--3","original_id":"401","name":"Missing Release of Memory after Effective Lifetime","metadata":{"Phase":"Architecture and Design","Description":"The Boehm-Demers-Weiser Garbage Collector or valgrind can be used to detect leaks in code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01036","_id":"cwe_mitigation/cwe_mitigation_01036","_rev":"_dVfOTTq--4","original_id":"404","name":"Improper Resource Shutdown or Release","metadata":{"Phase":"Requirements","Description":"\n                  Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01037","_id":"cwe_mitigation/cwe_mitigation_01037","_rev":"_dVfOTTq--5","original_id":"404","name":"Improper Resource Shutdown or Release","metadata":{"Phase":"Implementation","Description":"It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free memory in a function. If you allocate memory that you intend to free upon completion of the function, you must be sure to free the memory at all exit points for that function including error conditions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01038","_id":"cwe_mitigation/cwe_mitigation_01038","_rev":"_dVfOTTq--6","original_id":"404","name":"Improper Resource Shutdown or Release","metadata":{"Phase":"Implementation","Description":"Memory should be allocated/freed using matching functions such as malloc/free, new/delete, and new[]/delete[]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01039","_id":"cwe_mitigation/cwe_mitigation_01039","_rev":"_dVfOTTq--7","original_id":"404","name":"Improper Resource Shutdown or Release","metadata":{"Phase":"Implementation","Description":"When releasing a complex object or structure, ensure that you properly dispose of all of its member components, not just the object itself."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01042","_id":"cwe_mitigation/cwe_mitigation_01042","_rev":"_dVfOTTq--8","original_id":"405","name":"Asymmetric Resource Consumption (Amplification)","metadata":{"Phase":"Architecture and Design","Description":"An application must make resources available to a client commensurate with the client's access level."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01043","_id":"cwe_mitigation/cwe_mitigation_01043","_rev":"_dVfOTTq--9","original_id":"405","name":"Asymmetric Resource Consumption (Amplification)","metadata":{"Phase":"Architecture and Design","Description":"An application must, at all times, keep track of allocated resources and meter their usage appropriately."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01044","_id":"cwe_mitigation/cwe_mitigation_01044","_rev":"_dVfOTTq-_-","original_id":"406","name":"Insufficient Control of Network Message Volume (Network Amplification)","metadata":{"Phase":"Architecture and Design","Description":"An application must make network resources available to a client commensurate with the client's access level."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01045","_id":"cwe_mitigation/cwe_mitigation_01045","_rev":"_dVfOTTu---","original_id":"406","name":"Insufficient Control of Network Message Volume (Network Amplification)","metadata":{"Phase":"Policy","Description":"Define a clear policy for network resource allocation and consumption."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01046","_id":"cwe_mitigation/cwe_mitigation_01046","_rev":"_dVfOTTu--_","original_id":"406","name":"Insufficient Control of Network Message Volume (Network Amplification)","metadata":{"Phase":"Implementation","Description":"An application must, at all times, keep track of network resources and meter their usage appropriately."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01047","_id":"cwe_mitigation/cwe_mitigation_01047","_rev":"_dVfOTTu--A","original_id":"410","name":"Insufficient Resource Pool","metadata":{"Phase":"Architecture and Design","Description":"Do not perform resource-intensive transactions for unauthenticated users and/or invalid requests."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01048","_id":"cwe_mitigation/cwe_mitigation_01048","_rev":"_dVfOTTu--B","original_id":"410","name":"Insufficient Resource Pool","metadata":{"Phase":"Architecture and Design","Description":"Consider implementing a velocity check mechanism which would detect abusive behavior."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01049","_id":"cwe_mitigation/cwe_mitigation_01049","_rev":"_dVfOTTu--C","original_id":"410","name":"Insufficient Resource Pool","metadata":{"Phase":"Operation","Description":"Consider load balancing as an option to handle heavy loads."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01050","_id":"cwe_mitigation/cwe_mitigation_01050","_rev":"_dVfOTTu--D","original_id":"410","name":"Insufficient Resource Pool","metadata":{"Phase":"Implementation","Description":"Make sure that resource handles are properly closed when no longer needed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01051","_id":"cwe_mitigation/cwe_mitigation_01051","_rev":"_dVfOTTu--E","original_id":"410","name":"Insufficient Resource Pool","metadata":{"Phase":"Architecture and Design","Description":"Identify the system's resource intensive operations and consider protecting them from abuse (e.g. malicious automated script which runs the resources out)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01052","_id":"cwe_mitigation/cwe_mitigation_01052","_rev":"_dVfOTTu--F","original_id":"412","name":"Unrestricted Externally Accessible Lock","metadata":{"Phase":"Architecture and Design","Description":"Use any access control that is offered by the functionality that is offering the lock."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01053","_id":"cwe_mitigation/cwe_mitigation_01053","_rev":"_dVfOTTu--G","original_id":"412","name":"Unrestricted Externally Accessible Lock","metadata":{"Phase":"Architecture and Design","Description":"Use unpredictable names or identifiers for the locks. This might not always be possible or feasible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01054","_id":"cwe_mitigation/cwe_mitigation_01054","_rev":"_dVfOTTu--H","original_id":"412","name":"Unrestricted Externally Accessible Lock","metadata":{"Phase":"Architecture and Design","Description":"Consider modifying your code to use non-blocking synchronization methods."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01056","_id":"cwe_mitigation/cwe_mitigation_01056","_rev":"_dVfOTTu--I","original_id":"413","name":"Improper Resource Locking","metadata":{"Phase":"Architecture and Design","Description":"Use a non-conflicting privilege scheme."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01057","_id":"cwe_mitigation/cwe_mitigation_01057","_rev":"_dVfOTTu--J","original_id":"413","name":"Improper Resource Locking","metadata":{"Phase":"Architecture and Design","Description":"Use synchronization when locking a resource."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01058","_id":"cwe_mitigation/cwe_mitigation_01058","_rev":"_dVfOTTu--K","original_id":"414","name":"Missing Lock Check","metadata":{"Phase":"Architecture and Design","Description":"Implement a reliable lock mechanism."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01059","_id":"cwe_mitigation/cwe_mitigation_01059","_rev":"_dVfOTTu--L","original_id":"415","name":"Double Free","metadata":{"Phase":"Architecture and Design","Description":"Choose a language that provides automatic memory management."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01060","_id":"cwe_mitigation/cwe_mitigation_01060","_rev":"_dVfOTTu--M","original_id":"415","name":"Double Free","metadata":{"Phase":"Implementation","Description":"Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01061","_id":"cwe_mitigation/cwe_mitigation_01061","_rev":"_dVfOTTu--N","original_id":"415","name":"Double Free","metadata":{"Phase":"Implementation","Description":"Use a static analysis tool to find double free instances."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01062","_id":"cwe_mitigation/cwe_mitigation_01062","_rev":"_dVfOTTu--O","original_id":"416","name":"Use After Free","metadata":{"Phase":"Architecture and Design","Description":"Choose a language that provides automatic memory management."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01063","_id":"cwe_mitigation/cwe_mitigation_01063","_rev":"_dVfOTTu--P","original_id":"416","name":"Use After Free","metadata":{"Phase":"Implementation","Description":"When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01064","_id":"cwe_mitigation/cwe_mitigation_01064","_rev":"_dVfOTTu--Q","original_id":"419","name":"Unprotected Primary Channel","metadata":{"Phase":"Architecture and Design","Description":"Do not expose administrative functionnality on the user UI."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01065","_id":"cwe_mitigation/cwe_mitigation_01065","_rev":"_dVfOTTu--R","original_id":"419","name":"Unprotected Primary Channel","metadata":{"Phase":"Architecture and Design","Description":"Protect the administrative/restricted functionality with a strong authentication mechanism."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01066","_id":"cwe_mitigation/cwe_mitigation_01066","_rev":"_dVfOTTu--S","original_id":"420","name":"Unprotected Alternate Channel","metadata":{"Phase":"Architecture and Design","Description":"Identify all alternate channels and use the same protection mechanisms that are used for the primary channels."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01067","_id":"cwe_mitigation/cwe_mitigation_01067","_rev":"_dVfOTTu--T","original_id":"422","name":"Unprotected Windows Messaging Channel ('Shatter')","metadata":{"Phase":"Architecture and Design","Description":"Always verify and authenticate the source of the message."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01068","_id":"cwe_mitigation/cwe_mitigation_01068","_rev":"_dVfOTTu--U","original_id":"424","name":"Improper Protection of Alternate Path","metadata":{"Phase":"Architecture and Design","Description":"Deploy different layers of protection to implement security in depth."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01069","_id":"cwe_mitigation/cwe_mitigation_01069","_rev":"_dVfOTTu--V","original_id":"425","name":"Direct Request ('Forced Browsing')","metadata":{"Phase":"Architecture and Design","Description":"Apply appropriate access control authorizations for each access to all restricted URLs, scripts or files."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01070","_id":"cwe_mitigation/cwe_mitigation_01070","_rev":"_dVfOTTu--W","original_id":"425","name":"Direct Request ('Forced Browsing')","metadata":{"Phase":"Architecture and Design","Description":"Consider using MVC based frameworks such as Struts."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01071","_id":"cwe_mitigation/cwe_mitigation_01071","_rev":"_dVfOTTu--X","original_id":"426","name":"Untrusted Search Path","metadata":{"Phase":"Architecture and Design","Description":"Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01072","_id":"cwe_mitigation/cwe_mitigation_01072","_rev":"_dVfOTTu--Y","original_id":"426","name":"Untrusted Search Path","metadata":{"Phase":"Implementation","Description":"When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01073","_id":"cwe_mitigation/cwe_mitigation_01073","_rev":"_dVfOTTu--Z","original_id":"426","name":"Untrusted Search Path","metadata":{"Phase":"Implementation","Description":"Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01074","_id":"cwe_mitigation/cwe_mitigation_01074","_rev":"_dVfOTTu--a","original_id":"426","name":"Untrusted Search Path","metadata":{"Phase":"Implementation","Description":"Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01075","_id":"cwe_mitigation/cwe_mitigation_01075","_rev":"_dVfOTTu--b","original_id":"426","name":"Untrusted Search Path","metadata":{"Phase":"Implementation","Description":"Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of it, while execl() and execv() require a full path."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01079","_id":"cwe_mitigation/cwe_mitigation_01079","_rev":"_dVfOTTu--c","original_id":"427","name":"Uncontrolled Search Path Element","metadata":{"Phase":"Architecture and Design","Description":"Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01080","_id":"cwe_mitigation/cwe_mitigation_01080","_rev":"_dVfOTTu--d","original_id":"427","name":"Uncontrolled Search Path Element","metadata":{"Phase":"Implementation","Description":"When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01081","_id":"cwe_mitigation/cwe_mitigation_01081","_rev":"_dVfOTTu--e","original_id":"427","name":"Uncontrolled Search Path Element","metadata":{"Phase":"Implementation","Description":"Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01082","_id":"cwe_mitigation/cwe_mitigation_01082","_rev":"_dVfOTTu--f","original_id":"427","name":"Uncontrolled Search Path Element","metadata":{"Phase":"Implementation","Description":"Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory. Since this is a denylist approach, it might not be a complete solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01083","_id":"cwe_mitigation/cwe_mitigation_01083","_rev":"_dVfOTTu--g","original_id":"427","name":"Uncontrolled Search Path Element","metadata":{"Phase":"Implementation","Description":"Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of finding the program using the PATH environment variable, while execl() and execv() require a full path."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01084","_id":"cwe_mitigation/cwe_mitigation_01084","_rev":"_dVfOTTu--h","original_id":"428","name":"Unquoted Search Path or Element","metadata":{"Phase":"Implementation","Description":"Properly quote the full search path before executing a program on the system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01085","_id":"cwe_mitigation/cwe_mitigation_01085","_rev":"_dVfOTTu--i","original_id":"428","name":"Unquoted Search Path or Element","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01086","_id":"cwe_mitigation/cwe_mitigation_01086","_rev":"_dVfOTTu--j","original_id":"428","name":"Unquoted Search Path or Element","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01087","_id":"cwe_mitigation/cwe_mitigation_01087","_rev":"_dVfOTTu--k","original_id":"430","name":"Deployment of Wrong Handler","metadata":{"Phase":"Architecture and Design","Description":"Perform a type check before interpreting an object."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01088","_id":"cwe_mitigation/cwe_mitigation_01088","_rev":"_dVfOTTu--l","original_id":"430","name":"Deployment of Wrong Handler","metadata":{"Phase":"Architecture and Design","Description":"Reject any inconsistent types, such as a file with a .GIF extension that appears to consist of PHP code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01089","_id":"cwe_mitigation/cwe_mitigation_01089","_rev":"_dVfOTTu--m","original_id":"431","name":"Missing Handler","metadata":{"Phase":"Implementation","Description":"Handle all possible situations (e.g. error condition)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01090","_id":"cwe_mitigation/cwe_mitigation_01090","_rev":"_dVfOTTu--n","original_id":"431","name":"Missing Handler","metadata":{"Phase":"Implementation","Description":"If an operation can throw an Exception, implement a handler for that specific exception."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01091","_id":"cwe_mitigation/cwe_mitigation_01091","_rev":"_dVfOTTu--o","original_id":"432","name":"Dangerous Signal Handler not Disabled During Sensitive Operations","metadata":{"Phase":"Implementation","Description":"Turn off dangerous handlers when performing sensitive operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01092","_id":"cwe_mitigation/cwe_mitigation_01092","_rev":"_dVfOTTu--p","original_id":"433","name":"Unparsed Raw Web Content Delivery","metadata":{"Phase":"Architecture and Design","Description":"Perform a type check before interpreting files."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01093","_id":"cwe_mitigation/cwe_mitigation_01093","_rev":"_dVfOTTu--q","original_id":"433","name":"Unparsed Raw Web Content Delivery","metadata":{"Phase":"Architecture and Design","Description":"Do not store sensitive information in files which may be misinterpreted."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01094","_id":"cwe_mitigation/cwe_mitigation_01094","_rev":"_dVfOTTu--r","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Architecture and Design","Description":"Generate a new, unique filename for an uploaded file instead of using the user-supplied filename, so that no external input is used at all.[REF-422] [REF-423]"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01095","_id":"cwe_mitigation/cwe_mitigation_01095","_rev":"_dVfOTTu--s","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Architecture and Design","Description":"When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01096","_id":"cwe_mitigation/cwe_mitigation_01096","_rev":"_dVfOTTu--t","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Architecture and Design","Description":"Consider storing the uploaded files outside of the web document root entirely. Then, use other mechanisms to deliver the files dynamically. [REF-423]"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01097","_id":"cwe_mitigation/cwe_mitigation_01097","_rev":"_dVfOTTu--u","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  For example, limiting filenames to alphanumeric characters can help to restrict the introduction of unintended file extensions.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01098","_id":"cwe_mitigation/cwe_mitigation_01098","_rev":"_dVfOTTu--v","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Architecture and Design","Description":"Define a very limited set of allowable extensions and only generate filenames that end in these extensions. Consider the possibility of XSS (CWE-79) before allowing .html or .htm file types."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01099","_id":"cwe_mitigation/cwe_mitigation_01099","_rev":"_dVfOTTu--w","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Implementation","Description":"Ensure that only one extension is used in the filename. Some web servers, including some versions of Apache, may process files based on inner extensions so that \"filename.php.gif\" is fed to the PHP interpreter.[REF-422] [REF-423]"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01100","_id":"cwe_mitigation/cwe_mitigation_01100","_rev":"_dVfOTTu--x","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Implementation","Description":"When running on a web server that supports case-insensitive filenames, perform case-insensitive evaluations of the extensions that are provided."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01101","_id":"cwe_mitigation/cwe_mitigation_01101","_rev":"_dVfOTTu--y","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01102","_id":"cwe_mitigation/cwe_mitigation_01102","_rev":"_dVfOTTu--z","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Implementation","Description":"Do not rely exclusively on sanity checks of file contents to ensure that the file is of the expected type and size. It may be possible for an attacker to hide code in some file segments that will still be executed by the server. For example, GIF images may contain a free-form comments field."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01103","_id":"cwe_mitigation/cwe_mitigation_01103","_rev":"_dVfOTTu--0","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Implementation","Description":"Do not rely exclusively on the MIME content type or filename attribute when determining how to render a file. Validating the MIME content type and ensuring that it matches the extension is only a partial solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01104","_id":"cwe_mitigation/cwe_mitigation_01104","_rev":"_dVfOTTy---","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01105","_id":"cwe_mitigation/cwe_mitigation_01105","_rev":"_dVfOTTy--_","original_id":"434","name":"Unrestricted Upload of File with Dangerous Type","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run the code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.\n                  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01111","_id":"cwe_mitigation/cwe_mitigation_01111","_rev":"_dVfOTTy--A","original_id":"441","name":"Unintended Proxy or Intermediary ('Confused Deputy')","metadata":{"Phase":"Architecture and Design","Description":"Enforce the use of strong mutual authentication mechanism between the two parties."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01112","_id":"cwe_mitigation/cwe_mitigation_01112","_rev":"_dVfOTTy--B","original_id":"441","name":"Unintended Proxy or Intermediary ('Confused Deputy')","metadata":{"Phase":"Architecture and Design","Description":"Whenever a product is an intermediary or proxy for\n                   transactions between two other components, the proxy core\n                   should not drop the identity of the initiator of the\n                   transaction. The immutability of the identity of the\n                   initiator must be maintained and should be forwarded all the\n                   way to the target. "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01113","_id":"cwe_mitigation/cwe_mitigation_01113","_rev":"_dVfOTTy--C","original_id":"444","name":"Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')","metadata":{"Phase":"Implementation","Description":"Use a web server that employs a strict HTTP parsing procedure, such as Apache [REF-433]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01114","_id":"cwe_mitigation/cwe_mitigation_01114","_rev":"_dVfOTTy--D","original_id":"444","name":"Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')","metadata":{"Phase":"Implementation","Description":"Use only SSL communication."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01115","_id":"cwe_mitigation/cwe_mitigation_01115","_rev":"_dVfOTTy--E","original_id":"444","name":"Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')","metadata":{"Phase":"Implementation","Description":"Terminate the client session after each request."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01116","_id":"cwe_mitigation/cwe_mitigation_01116","_rev":"_dVfOTTy--F","original_id":"444","name":"Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling')","metadata":{"Phase":"System Configuration","Description":"Turn all pages to non-cacheable."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01117","_id":"cwe_mitigation/cwe_mitigation_01117","_rev":"_dVfOTTy--G","original_id":"447","name":"Unimplemented or Unsupported Feature in UI","metadata":{"Phase":"Testing","Description":"Perform functionality testing before deploying the application."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01118","_id":"cwe_mitigation/cwe_mitigation_01118","_rev":"_dVfOTTy--H","original_id":"448","name":"Obsolete Feature in UI","metadata":{"Phase":"Architecture and Design","Description":"Remove the obsolete feature from the UI. Warn the user that the feature is no longer supported."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01119","_id":"cwe_mitigation/cwe_mitigation_01119","_rev":"_dVfOTTy--I","original_id":"449","name":"The UI Performs the Wrong Action","metadata":{"Phase":"Testing","Description":"Perform extensive functionality testing of the UI. The UI should behave as specified."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01120","_id":"cwe_mitigation/cwe_mitigation_01120","_rev":"_dVfOTTy--J","original_id":"450","name":"Multiple Interpretations of UI Input","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01121","_id":"cwe_mitigation/cwe_mitigation_01121","_rev":"_dVfOTTy--K","original_id":"450","name":"Multiple Interpretations of UI Input","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01122","_id":"cwe_mitigation/cwe_mitigation_01122","_rev":"_dVfOTTy--L","original_id":"451","name":"User Interface (UI) Misrepresentation of Critical Information","metadata":{"Phase":"Implementation","Description":"Perform data validation (e.g. syntax, length, etc.) before interpreting the data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01123","_id":"cwe_mitigation/cwe_mitigation_01123","_rev":"_dVfOTTy--M","original_id":"451","name":"User Interface (UI) Misrepresentation of Critical Information","metadata":{"Phase":"Architecture and Design","Description":"Create a strategy for presenting information, and plan for how to display unusual characters."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01124","_id":"cwe_mitigation/cwe_mitigation_01124","_rev":"_dVfOTTy--N","original_id":"453","name":"Insecure Default Variable Initialization","metadata":{"Phase":"System Configuration","Description":"Disable or change default settings when they can be used to abuse the system. Since those default settings are shipped with the product they are likely to be known by a potential attacker who is familiar with the product. For instance, default credentials should be changed or the associated accounts should be disabled."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01125","_id":"cwe_mitigation/cwe_mitigation_01125","_rev":"_dVfOTTy--O","original_id":"454","name":"External Initialization of Trusted Variables or Data Stores","metadata":{"Phase":"Implementation","Description":"A software system should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking (e.g. input validation) is performed when relying on input from outside a trust boundary."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01126","_id":"cwe_mitigation/cwe_mitigation_01126","_rev":"_dVfOTTy--P","original_id":"454","name":"External Initialization of Trusted Variables or Data Stores","metadata":{"Phase":"Architecture and Design","Description":"Avoid any external control of variables. If necessary, restrict the variables that can be modified using an allowlist, and use a different namespace or naming convention if possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01127","_id":"cwe_mitigation/cwe_mitigation_01127","_rev":"_dVfOTTy--Q","original_id":"455","name":"Non-exit on Failed Initialization","metadata":{"Phase":"Implementation","Description":"Follow the principle of failing securely when an error occurs. The system should enter a state where it is not vulnerable and will not display sensitive error messages to a potential attacker."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01128","_id":"cwe_mitigation/cwe_mitigation_01128","_rev":"_dVfOTTy--R","original_id":"456","name":"Missing Initialization of a Variable","metadata":{"Phase":"Implementation","Description":"Check that critical variables are initialized."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01129","_id":"cwe_mitigation/cwe_mitigation_01129","_rev":"_dVfOTTy--S","original_id":"456","name":"Missing Initialization of a Variable","metadata":{"Phase":"Testing","Description":"Use a static analysis tool to spot non-initialized variables."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01130","_id":"cwe_mitigation/cwe_mitigation_01130","_rev":"_dVfOTTy--T","original_id":"457","name":"Use of Uninitialized Variable","metadata":{"Phase":"Implementation","Description":"Assign all variables to an initial value."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01131","_id":"cwe_mitigation/cwe_mitigation_01131","_rev":"_dVfOTTy--U","original_id":"457","name":"Use of Uninitialized Variable","metadata":{"Phase":"Build and Compilation","Description":"Most compilers will complain about the use of uninitialized variables if warnings are turned on."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01132","_id":"cwe_mitigation/cwe_mitigation_01132","_rev":"_dVfOTTy--V","original_id":"457","name":"Use of Uninitialized Variable","metadata":{"Phase":"Implementation","Description":"When using a language that does not require explicit declaration of variables, run or compile the software in a mode that reports undeclared or unknown variables. This may indicate the presence of a typographic error in the variable's name."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01133","_id":"cwe_mitigation/cwe_mitigation_01133","_rev":"_dVfOTTy--W","original_id":"457","name":"Use of Uninitialized Variable","metadata":{"Phase":"Requirements","Description":"The choice could be made to use a language that is not susceptible to these issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01134","_id":"cwe_mitigation/cwe_mitigation_01134","_rev":"_dVfOTTy--X","original_id":"457","name":"Use of Uninitialized Variable","metadata":{"Phase":"Architecture and Design","Description":"Mitigating technologies such as safe string libraries and container abstractions could be introduced."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01135","_id":"cwe_mitigation/cwe_mitigation_01135","_rev":"_dVfOTTy--Y","original_id":"459","name":"Incomplete Cleanup","metadata":{"Phase":"Architecture and Design","Description":"Temporary files and other supporting resources should be deleted/released immediately after they are no longer needed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01136","_id":"cwe_mitigation/cwe_mitigation_01136","_rev":"_dVfOTTy--Z","original_id":"460","name":"Improper Cleanup on Thrown Exception","metadata":{"Phase":"Implementation","Description":"If one breaks from a loop or function by throwing an exception, make sure that cleanup happens or that you should exit the program. Use throwing exceptions sparsely."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01137","_id":"cwe_mitigation/cwe_mitigation_01137","_rev":"_dVfOTTy--a","original_id":"462","name":"Duplicate Key in Associative List (Alist)","metadata":{"Phase":"Architecture and Design","Description":"Use a hash table instead of an alist."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01138","_id":"cwe_mitigation/cwe_mitigation_01138","_rev":"_dVfOTTy--b","original_id":"462","name":"Duplicate Key in Associative List (Alist)","metadata":{"Phase":"Architecture and Design","Description":"Use an alist which checks the uniqueness of hash keys with each entry before inserting the entry."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01139","_id":"cwe_mitigation/cwe_mitigation_01139","_rev":"_dVfOTTy--c","original_id":"463","name":"Deletion of Data Structure Sentinel","metadata":{"Phase":"Architecture and Design","Description":"Use an abstraction library to abstract away risky APIs. Not a complete solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01140","_id":"cwe_mitigation/cwe_mitigation_01140","_rev":"_dVfOTTy--d","original_id":"463","name":"Deletion of Data Structure Sentinel","metadata":{"Phase":"Build and Compilation","Description":"\n                  Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.\n                  For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01141","_id":"cwe_mitigation/cwe_mitigation_01141","_rev":"_dVfOTTy--e","original_id":"463","name":"Deletion of Data Structure Sentinel","metadata":{"Phase":"Operation","Description":"Use OS-level preventative functionality. Not a complete solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01142","_id":"cwe_mitigation/cwe_mitigation_01142","_rev":"_dVfOTTy--f","original_id":"464","name":"Addition of Data Structure Sentinel","metadata":{"Phase":"Implementation","Description":"Encapsulate the user from interacting with data sentinels. Validate user input to verify that sentinels are not present."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01143","_id":"cwe_mitigation/cwe_mitigation_01143","_rev":"_dVfOTTy--g","original_id":"464","name":"Addition of Data Structure Sentinel","metadata":{"Phase":"Implementation","Description":"Proper error checking can reduce the risk of inadvertently introducing sentinel values into data. For example, if a parsing function fails or encounters an error, it might return a value that is the same as the sentinel."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01144","_id":"cwe_mitigation/cwe_mitigation_01144","_rev":"_dVfOTTy--h","original_id":"464","name":"Addition of Data Structure Sentinel","metadata":{"Phase":"Architecture and Design","Description":"Use an abstraction library to abstract away risky APIs. This is not a complete solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01145","_id":"cwe_mitigation/cwe_mitigation_01145","_rev":"_dVfOTTy--i","original_id":"464","name":"Addition of Data Structure Sentinel","metadata":{"Phase":"Operation","Description":"Use OS-level preventative functionality. This is not a complete solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01146","_id":"cwe_mitigation/cwe_mitigation_01146","_rev":"_dVfOTTy--j","original_id":"467","name":"Use of sizeof() on a Pointer Type","metadata":{"Phase":"Implementation","Description":"Use expressions such as \"sizeof(*pointer)\" instead of \"sizeof(pointer)\", unless you intend to run sizeof() on a pointer type to gain some platform independence or if you are allocating a variable on the stack."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01147","_id":"cwe_mitigation/cwe_mitigation_01147","_rev":"_dVfOTTy--k","original_id":"468","name":"Incorrect Pointer Scaling","metadata":{"Phase":"Architecture and Design","Description":"Use a platform with high-level memory abstractions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01148","_id":"cwe_mitigation/cwe_mitigation_01148","_rev":"_dVfOTTy--l","original_id":"468","name":"Incorrect Pointer Scaling","metadata":{"Phase":"Implementation","Description":"Always use array indexing instead of direct pointer manipulation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01149","_id":"cwe_mitigation/cwe_mitigation_01149","_rev":"_dVfOTTy--m","original_id":"468","name":"Incorrect Pointer Scaling","metadata":{"Phase":"Architecture and Design","Description":"Use technologies for preventing buffer overflows."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01150","_id":"cwe_mitigation/cwe_mitigation_01150","_rev":"_dVfOTTy--n","original_id":"469","name":"Use of Pointer Subtraction to Determine Size","metadata":{"Phase":"Implementation","Description":"Save an index variable. This is the recommended solution. Rather than subtract pointers from one another, use an index variable of the same size as the pointers in question. Use this variable to \"walk\" from one pointer to the other and calculate the difference. Always validate this number."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01151","_id":"cwe_mitigation/cwe_mitigation_01151","_rev":"_dVfOTTy--o","original_id":"470","name":"Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')","metadata":{"Phase":"Architecture and Design","Description":"Refactor your code to avoid using reflection."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01152","_id":"cwe_mitigation/cwe_mitigation_01152","_rev":"_dVfOTTy--p","original_id":"470","name":"Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')","metadata":{"Phase":"Architecture and Design","Description":"Do not use user-controlled inputs to select and load classes or code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01153","_id":"cwe_mitigation/cwe_mitigation_01153","_rev":"_dVfOTTy--q","original_id":"470","name":"Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')","metadata":{"Phase":"Implementation","Description":"Apply strict input validation by using allowlists or indirect selection to ensure that the user is only selecting allowable classes or code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01154","_id":"cwe_mitigation/cwe_mitigation_01154","_rev":"_dVfOTTy--r","original_id":"471","name":"Modification of Assumed-Immutable Data (MAID)","metadata":{"Phase":"Architecture and Design","Description":"When the data is stored or transmitted through untrusted sources that could modify the data, implement integrity checks to detect unauthorized modification, or store/transmit the data in a trusted location that is free from external influence."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01155","_id":"cwe_mitigation/cwe_mitigation_01155","_rev":"_dVfOTTy--s","original_id":"472","name":"External Control of Assumed-Immutable Web Parameter","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01156","_id":"cwe_mitigation/cwe_mitigation_01156","_rev":"_dVfOTTy--t","original_id":"472","name":"External Control of Assumed-Immutable Web Parameter","metadata":{"Phase":"Implementation","Description":"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 inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01157","_id":"cwe_mitigation/cwe_mitigation_01157","_rev":"_dVfOTTy--u","original_id":"473","name":"PHP External Variable Modification","metadata":{"Phase":"Requirements","Description":"Carefully identify which variables can be controlled or influenced by an external user, and consider adopting a naming convention to emphasize when externally modifiable variables are being used. An application should be reluctant to trust variables that have been initialized outside of its trust boundary. Ensure adequate checking is performed when relying on input from outside a trust boundary. Do not allow your application to run with register_globals enabled. If you implement a register_globals emulator, be extremely careful of variable extraction, dynamic evaluation, and similar issues, since weaknesses in your emulation could allow external variable modification to take place even without register_globals."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01158","_id":"cwe_mitigation/cwe_mitigation_01158","_rev":"_dVfOTTy--v","original_id":"474","name":"Use of Function with Inconsistent Implementations","metadata":{"Phase":"Architecture and Design","Description":"Do not accept inconsistent behavior from the API specifications when the deviant behavior increase the risk level."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01159","_id":"cwe_mitigation/cwe_mitigation_01159","_rev":"_dVfOTTy--w","original_id":"476","name":"NULL Pointer Dereference","metadata":{"Phase":"Implementation","Description":"If all pointers that could have been modified are sanity-checked previous to use, nearly all NULL pointer dereferences can be prevented."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01160","_id":"cwe_mitigation/cwe_mitigation_01160","_rev":"_dVfOTTy--x","original_id":"476","name":"NULL Pointer Dereference","metadata":{"Phase":"Requirements","Description":"The choice could be made to use a language that is not susceptible to these issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01161","_id":"cwe_mitigation/cwe_mitigation_01161","_rev":"_dVfOTTy--y","original_id":"476","name":"NULL Pointer Dereference","metadata":{"Phase":"Implementation","Description":"Check the results of all functions that return a value and verify that the value is non-null before acting upon it."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01162","_id":"cwe_mitigation/cwe_mitigation_01162","_rev":"_dVfOTTy--z","original_id":"476","name":"NULL Pointer Dereference","metadata":{"Phase":"Architecture and Design","Description":"Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01163","_id":"cwe_mitigation/cwe_mitigation_01163","_rev":"_dVfOTTy--0","original_id":"476","name":"NULL Pointer Dereference","metadata":{"Phase":"Implementation","Description":"Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01164","_id":"cwe_mitigation/cwe_mitigation_01164","_rev":"_dVfOTTy--1","original_id":"476","name":"NULL Pointer Dereference","metadata":{"Phase":"Testing","Description":"Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01167","_id":"cwe_mitigation/cwe_mitigation_01167","_rev":"_dVfOTTy--2","original_id":"477","name":"Use of Obsolete Function","metadata":{"Phase":"Implementation","Description":"Refer to the documentation for the obsolete function in order to determine why it is deprecated or obsolete and to learn about alternative ways to achieve the same functionality."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01168","_id":"cwe_mitigation/cwe_mitigation_01168","_rev":"_dVfOTTy--3","original_id":"477","name":"Use of Obsolete Function","metadata":{"Phase":"Requirements","Description":"Consider seriously the security implications of using an obsolete function. Consider using alternate functions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01176","_id":"cwe_mitigation/cwe_mitigation_01176","_rev":"_dVfOTTy--4","original_id":"478","name":"Missing Default Case in Switch Statement","metadata":{"Phase":"Implementation","Description":"Ensure that there are no unaccounted for cases, when adjusting flow or values based on the value of a given variable. In switch statements, this can be accomplished through the use of the default label."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01177","_id":"cwe_mitigation/cwe_mitigation_01177","_rev":"_dVfOTTy--5","original_id":"478","name":"Missing Default Case in Switch Statement","metadata":{"Phase":"Implementation","Description":"In the case of switch style statements, the very simple act of creating a default case can mitigate this situation, if done correctly. Often however, the default case is used simply to represent an assumed option, as opposed to working as a check for invalid input. This is poor practice and in some cases is as bad as omitting a default case entirely."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01178","_id":"cwe_mitigation/cwe_mitigation_01178","_rev":"_dVfOTTy--6","original_id":"479","name":"Signal Handler Use of a Non-reentrant Function","metadata":{"Phase":"Requirements","Description":"Require languages or libraries that provide reentrant functionality, or otherwise make it easier to avoid this weakness."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01179","_id":"cwe_mitigation/cwe_mitigation_01179","_rev":"_dVfOTTy--7","original_id":"479","name":"Signal Handler Use of a Non-reentrant Function","metadata":{"Phase":"Architecture and Design","Description":"Design signal handlers to only set flags rather than perform complex functionality."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01180","_id":"cwe_mitigation/cwe_mitigation_01180","_rev":"_dVfOTTy--8","original_id":"479","name":"Signal Handler Use of a Non-reentrant Function","metadata":{"Phase":"Implementation","Description":"Ensure that non-reentrant functions are not found in signal handlers."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01181","_id":"cwe_mitigation/cwe_mitigation_01181","_rev":"_dVfOTTy--9","original_id":"479","name":"Signal Handler Use of a Non-reentrant Function","metadata":{"Phase":"Implementation","Description":"Use sanity checks to reduce the timing window for exploitation of race conditions. This is only a partial solution, since many attacks might fail, but other attacks still might work within the narrower window, even accidentally."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01184","_id":"cwe_mitigation/cwe_mitigation_01184","_rev":"_dVfOTTy-_-","original_id":"481","name":"Assigning instead of Comparing","metadata":{"Phase":"Testing","Description":"Many IDEs and static analysis products will detect this problem."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01185","_id":"cwe_mitigation/cwe_mitigation_01185","_rev":"_dVfOTTy-__","original_id":"481","name":"Assigning instead of Comparing","metadata":{"Phase":"Implementation","Description":"Place constants on the left. If one attempts to assign a constant with a variable, the compiler will produce an error."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01186","_id":"cwe_mitigation/cwe_mitigation_01186","_rev":"_dVfOTTy-_A","original_id":"482","name":"Comparing instead of Assigning","metadata":{"Phase":"Testing","Description":"Many IDEs and static analysis products will detect this problem."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01187","_id":"cwe_mitigation/cwe_mitigation_01187","_rev":"_dVfOTT2---","original_id":"483","name":"Incorrect Block Delimitation","metadata":{"Phase":"Implementation","Description":"Always use explicit block delimitation and use static-analysis technologies to enforce this practice."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01188","_id":"cwe_mitigation/cwe_mitigation_01188","_rev":"_dVfOTT2--_","original_id":"484","name":"Omitted Break Statement in Switch","metadata":{"Phase":"Implementation","Description":"Omitting a break statement so that one may fall through is often indistinguishable from an error, and therefore should be avoided. If you need to use fall-through capabilities, make sure that you have clearly documented this within the switch statement, and ensure that you have examined all the logical possibilities."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01189","_id":"cwe_mitigation/cwe_mitigation_01189","_rev":"_dVfOTT2--A","original_id":"484","name":"Omitted Break Statement in Switch","metadata":{"Phase":"Implementation","Description":"The functionality of omitting a break statement could be clarified with an if statement. This method is much safer."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01192","_id":"cwe_mitigation/cwe_mitigation_01192","_rev":"_dVfOTT2--B","original_id":"486","name":"Comparison of Classes by Name","metadata":{"Phase":"Implementation","Description":"Use class equivalency to determine type. Rather than use the class name to determine if an object is of a given type, use the getClass() method, and == operator."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01193","_id":"cwe_mitigation/cwe_mitigation_01193","_rev":"_dVfOTT2--C","original_id":"487","name":"Reliance on Package-level Scope","metadata":{"Phase":"Architecture and Design","Description":"Data should be private static and final whenever possible. This will assure that your code is protected by instantiating early, preventing access and tampering."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01194","_id":"cwe_mitigation/cwe_mitigation_01194","_rev":"_dVfOTT2--D","original_id":"488","name":"Exposure of Data Element to Wrong Session","metadata":{"Phase":"Architecture and Design","Description":"Protect the application's sessions from information leakage. Make sure that a session's data is not used or visible by other sessions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01195","_id":"cwe_mitigation/cwe_mitigation_01195","_rev":"_dVfOTT2--E","original_id":"488","name":"Exposure of Data Element to Wrong Session","metadata":{"Phase":"Testing","Description":"Use a static analysis tool to scan the code for information leakage vulnerabilities (e.g. Singleton Member Field)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01196","_id":"cwe_mitigation/cwe_mitigation_01196","_rev":"_dVfOTT2--F","original_id":"488","name":"Exposure of Data Element to Wrong Session","metadata":{"Phase":"Architecture and Design","Description":"In a multithreading environment, storing user data in Servlet member fields introduces a data access race condition. Do not use member fields to store information in the Servlet."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01197","_id":"cwe_mitigation/cwe_mitigation_01197","_rev":"_dVfOTT2--G","original_id":"489","name":"Active Debug Code","metadata":{"Phase":"Build and Compilation","Description":"Remove debug code before deploying the application."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01198","_id":"cwe_mitigation/cwe_mitigation_01198","_rev":"_dVfOTT2--H","original_id":"491","name":"Public cloneable() Method Without Final ('Object Hijack')","metadata":{"Phase":"Implementation","Description":"Make the cloneable() method final."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01199","_id":"cwe_mitigation/cwe_mitigation_01199","_rev":"_dVfOTT2--I","original_id":"492","name":"Use of Inner Class Containing Sensitive Data","metadata":{"Phase":"Implementation","Description":"Using sealed classes protects object-oriented encapsulation paradigms and therefore protects code from being extended in unforeseen ways."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01200","_id":"cwe_mitigation/cwe_mitigation_01200","_rev":"_dVfOTT2--J","original_id":"492","name":"Use of Inner Class Containing Sensitive Data","metadata":{"Phase":"Implementation","Description":"Inner Classes do not provide security. Warning: Never reduce the security of the object from an outer class, going to an inner class. If an outer class is final or private, ensure that its inner class is private as well."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01201","_id":"cwe_mitigation/cwe_mitigation_01201","_rev":"_dVfOTT2--K","original_id":"493","name":"Critical Public Variable Without Final Modifier","metadata":{"Phase":"Implementation","Description":"Declare all public fields as final when possible, especially if it is used to maintain internal state of an Applet or of classes used by an Applet. If a field must be public, then perform all appropriate sanity checks before accessing the field from your code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01202","_id":"cwe_mitigation/cwe_mitigation_01202","_rev":"_dVfOTT2--L","original_id":"494","name":"Download of Code Without Integrity Check","metadata":{"Phase":"Implementation","Description":"Perform proper forward and reverse DNS lookups to detect DNS spoofing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01203","_id":"cwe_mitigation/cwe_mitigation_01203","_rev":"_dVfOTT2--M","original_id":"494","name":"Download of Code Without Integrity Check","metadata":{"Phase":"Architecture and Design","Description":"\n                  Encrypt the code with a reliable encryption scheme before transmitting.\n                  This will only be a partial solution, since it will not detect DNS spoofing and it will not prevent your code from being modified on the hosting site.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01204","_id":"cwe_mitigation/cwe_mitigation_01204","_rev":"_dVfOTT2--N","original_id":"494","name":"Download of Code Without Integrity Check","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  Speficially, it may be helpful to use tools or frameworks to perform integrity checking on the transmitted code.\n                  \n                     \n                        When providing the code that is to be downloaded, such as for automatic updates of the software, then use cryptographic signatures for the code and modify the download clients to verify the signatures. Ensure that the implementation does not contain CWE-295, CWE-320, CWE-347, and related weaknesses.\n                        Use code signing technologies such as Authenticode. See references [REF-454] [REF-455] [REF-456].\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01205","_id":"cwe_mitigation/cwe_mitigation_01205","_rev":"_dVfOTT2--O","original_id":"494","name":"Download of Code Without Integrity Check","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01206","_id":"cwe_mitigation/cwe_mitigation_01206","_rev":"_dVfOTT2--P","original_id":"494","name":"Download of Code Without Integrity Check","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run the code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.\n                  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01209","_id":"cwe_mitigation/cwe_mitigation_01209","_rev":"_dVfOTT2--Q","original_id":"495","name":"Private Data Structure Returned From A Public Method","metadata":{"Phase":"Implementation","Description":"Declare the method private."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01210","_id":"cwe_mitigation/cwe_mitigation_01210","_rev":"_dVfOTT2--R","original_id":"495","name":"Private Data Structure Returned From A Public Method","metadata":{"Phase":"Implementation","Description":"Clone the member data and keep an unmodified version of the data private to the object."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01211","_id":"cwe_mitigation/cwe_mitigation_01211","_rev":"_dVfOTT2--S","original_id":"495","name":"Private Data Structure Returned From A Public Method","metadata":{"Phase":"Implementation","Description":"Use public setter methods that govern how a private member can be modified."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01212","_id":"cwe_mitigation/cwe_mitigation_01212","_rev":"_dVfOTT2--T","original_id":"496","name":"Public Data Assigned to Private Array-Typed Field","metadata":{"Phase":"Implementation","Description":"Do not allow objects to modify private members of a class."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01213","_id":"cwe_mitigation/cwe_mitigation_01213","_rev":"_dVfOTT2--U","original_id":"497","name":"Exposure of Sensitive System Information to an Unauthorized Control Sphere","metadata":{"Phase":"Architecture and Design","Description":"Production applications should never use methods that generate internal details such as stack traces and error messages unless that information is directly committed to a log that is not viewable by the end user. All error message text should be HTML entity encoded before being written to the log file to protect against potential cross-site scripting attacks against the viewer of the logs"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01214","_id":"cwe_mitigation/cwe_mitigation_01214","_rev":"_dVfOTT2--V","original_id":"498","name":"Cloneable Class Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"If you do make your classes clonable, ensure that your clone method is final and throw super.clone()."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01215","_id":"cwe_mitigation/cwe_mitigation_01215","_rev":"_dVfOTT2--W","original_id":"499","name":"Serializable Class Containing Sensitive Data","metadata":{"Phase":"Implementation","Description":"In Java, explicitly define final writeObject() to prevent serialization. This is the recommended solution. Define the writeObject() function to throw an exception explicitly denying serialization."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01216","_id":"cwe_mitigation/cwe_mitigation_01216","_rev":"_dVfOTT2--X","original_id":"499","name":"Serializable Class Containing Sensitive Data","metadata":{"Phase":"Implementation","Description":"Make sure to prevent serialization of your objects."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01217","_id":"cwe_mitigation/cwe_mitigation_01217","_rev":"_dVfOTT2--Y","original_id":"500","name":"Public Static Field Not Marked Final","metadata":{"Phase":"Architecture and Design","Description":"Clearly identify the scope for all critical data elements, including whether they should be regarded as static."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01218","_id":"cwe_mitigation/cwe_mitigation_01218","_rev":"_dVfOTT2--Z","original_id":"500","name":"Public Static Field Not Marked Final","metadata":{"Phase":"Implementation","Description":"\n                  Make any static fields private and constant.\n                  A constant field is denoted by the keyword 'const' in C/C++ and ' final' in Java\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01219","_id":"cwe_mitigation/cwe_mitigation_01219","_rev":"_dVfOTT2--a","original_id":"502","name":"Deserialization of Untrusted Data","metadata":{"Phase":"Architecture and Design","Description":"If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01220","_id":"cwe_mitigation/cwe_mitigation_01220","_rev":"_dVfOTT2--b","original_id":"502","name":"Deserialization of Untrusted Data","metadata":{"Phase":"Implementation","Description":"When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01221","_id":"cwe_mitigation/cwe_mitigation_01221","_rev":"_dVfOTT2--c","original_id":"502","name":"Deserialization of Untrusted Data","metadata":{"Phase":"Implementation","Description":"Explicitly define a final object() to prevent deserialization."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01222","_id":"cwe_mitigation/cwe_mitigation_01222","_rev":"_dVfOTT2--d","original_id":"502","name":"Deserialization of Untrusted Data","metadata":{"Phase":"Architecture and Design","Description":"\n                  Make fields transient to protect them from deserialization.\n                  An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01223","_id":"cwe_mitigation/cwe_mitigation_01223","_rev":"_dVfOTT2--e","original_id":"502","name":"Deserialization of Untrusted Data","metadata":{"Phase":"Implementation","Description":"Avoid having unnecessary types or gadgets available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01224","_id":"cwe_mitigation/cwe_mitigation_01224","_rev":"_dVfOTT2--f","original_id":"506","name":"Embedded Malicious Code","metadata":{"Phase":"Testing","Description":"Remove the malicious code and start an effort to ensure that no more malicious code exists. This may require a detailed review of all code, as it is possible to hide a serious attack in only one or two lines of code. These lines may be located almost anywhere in an application and may have been intentionally obfuscated by the attacker."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01229","_id":"cwe_mitigation/cwe_mitigation_01229","_rev":"_dVfOTT2--g","original_id":"507","name":"Trojan Horse","metadata":{"Phase":"Operation","Description":"Most antivirus software scans for Trojan Horses."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01230","_id":"cwe_mitigation/cwe_mitigation_01230","_rev":"_dVfOTT2--h","original_id":"507","name":"Trojan Horse","metadata":{"Phase":"Installation","Description":"Verify the integrity of the software that is being installed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01231","_id":"cwe_mitigation/cwe_mitigation_01231","_rev":"_dVfOTT2--i","original_id":"508","name":"Non-Replicating Malicious Code","metadata":{"Phase":"Operation","Description":"Antivirus software can help mitigate known malicious code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01232","_id":"cwe_mitigation/cwe_mitigation_01232","_rev":"_dVfOTT2--j","original_id":"508","name":"Non-Replicating Malicious Code","metadata":{"Phase":"Installation","Description":"Verify the integrity of the software that is being installed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01233","_id":"cwe_mitigation/cwe_mitigation_01233","_rev":"_dVfOTT2--k","original_id":"509","name":"Replicating Malicious Code (Virus or Worm)","metadata":{"Phase":"Operation","Description":"Antivirus software scans for viruses or worms."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01234","_id":"cwe_mitigation/cwe_mitigation_01234","_rev":"_dVfOTT2--l","original_id":"509","name":"Replicating Malicious Code (Virus or Worm)","metadata":{"Phase":"Installation","Description":"Always verify the integrity of the software that is being installed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01235","_id":"cwe_mitigation/cwe_mitigation_01235","_rev":"_dVfOTT2--m","original_id":"510","name":"Trapdoor","metadata":{"Phase":"Installation","Description":"Always verify the integrity of the software that is being installed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01236","_id":"cwe_mitigation/cwe_mitigation_01236","_rev":"_dVfOTT2--n","original_id":"510","name":"Trapdoor","metadata":{"Phase":"Testing","Description":"Identify and closely inspect the conditions for entering privileged areas of the code, especially those related to authentication, process invocation, and network communications."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01243","_id":"cwe_mitigation/cwe_mitigation_01243","_rev":"_dVfOTT2--o","original_id":"511","name":"Logic/Time Bomb","metadata":{"Phase":"Installation","Description":"Always verify the integrity of the software that is being installed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01244","_id":"cwe_mitigation/cwe_mitigation_01244","_rev":"_dVfOTT2--p","original_id":"511","name":"Logic/Time Bomb","metadata":{"Phase":"Testing","Description":"Conduct a code coverage analysis using live testing, then closely inspect any code that is not covered."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01245","_id":"cwe_mitigation/cwe_mitigation_01245","_rev":"_dVfOTT2--q","original_id":"512","name":"Spyware","metadata":{"Phase":"Operation","Description":"Use spyware detection and removal software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01246","_id":"cwe_mitigation/cwe_mitigation_01246","_rev":"_dVfOTT2--r","original_id":"512","name":"Spyware","metadata":{"Phase":"Installation","Description":"Always verify the integrity of the software that is being installed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01248","_id":"cwe_mitigation/cwe_mitigation_01248","_rev":"_dVfOTT2--s","original_id":"515","name":"Covert Storage Channel","metadata":{"Phase":"Implementation","Description":"Ensure that all reserved fields are set to zero before messages are sent and that no unnecessary information is included."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01249","_id":"cwe_mitigation/cwe_mitigation_01249","_rev":"_dVfOTT2--t","original_id":"520","name":".NET Misconfiguration: Use of Impersonation","metadata":{"Phase":"Operation","Description":"Run the application with limited privilege to the underlying operating and file system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01250","_id":"cwe_mitigation/cwe_mitigation_01250","_rev":"_dVfOTT2--u","original_id":"521","name":"Weak Password Requirements","metadata":{"Phase":"Architecture and Design","Description":"\n                 A product's design should require adherance to an appropriate password policy. Specific password requirements depend strongly on contextual factors, but it is recommended to contain the following attributes:\n                \n                 \n                   Enforcement of a minimum and maximum length\n                   Restrictions against password reuse\n                   Restrictions against using common passwords\n                   Restrictions against using contextual string in the password (e.g., user id, app name)\n                 \n                 Depending on the threat model, the password policy may include several additional attributes.\n                 \n                   Complex passwords requiring mixed character sets (alpha, numeric, special, mixed case)\n                     \n                       Increasing the range of characters makes the password harder to crack and may be appropriate for systems relying on single factor authentication.\n                       Unfortunately, a complex password may be difficult to memorize, encouraging a user to select a short password or to incorrectly manage the password (write it down).\n                       Another disadvantage of this approach is that it often does not result in a significant increases in overal password complexity due to people's predictable usage of various symbols.\n                     \n                   \n                   Large Minimum Length (encouraging passphrases instead of passwords)\n                     \n                       Increasing the number of characters makes the password harder to crack and may be appropriate for systems relying on single factor authentication.\n                       A disadvantage of this approach is that selecting a good passphrase is not easy and poor passwords can still be generated. Some prompting may be needed to encourage long un-predictable passwords.\n                     \n                   \n                   Randomly Chosen Secrets\n                     \n                       Generating a password for the user can help make sure that length and complexity requirements are met, and can result in secure passwords being used.\n                       A disadvantage of this approach is that the resulting password or passpharse may be too difficult to memorize, encouraging them to be written down.\n                     \n                   \n                   Password Expiration\n                     \n                       Requiring a periodic password change can reduce the time window that an adversary has to crack a password, while also limiting the damage caused by password exposures at other locations.\n\t\t\t\t\t   Password expiration may be a good mitigating technique when long complex passwords are not desired.\n                     \n                   \n                 \n                 \n                  See NIST 800-63B https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf Sections: 5.1.1, 10.2.1, and Appendix A for further information on password requirements. \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01251","_id":"cwe_mitigation/cwe_mitigation_01251","_rev":"_dVfOTT2--v","original_id":"521","name":"Weak Password Requirements","metadata":{"Phase":"Architecture and Design","Description":"Consider a second\n                 authentication factor beyond the password, which prevents the\n                 password from being a single point of failure. See CWE-308 for\n                 further information."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01252","_id":"cwe_mitigation/cwe_mitigation_01252","_rev":"_dVfOTT2--w","original_id":"521","name":"Weak Password Requirements","metadata":{"Phase":"Implementation","Description":"Consider implementing a password complexity meter to inform users when a chosen password meets the required attributes."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01253","_id":"cwe_mitigation/cwe_mitigation_01253","_rev":"_dVfOTT2--x","original_id":"522","name":"Insufficiently Protected Credentials","metadata":{"Phase":"Architecture and Design","Description":"Use an appropriate security mechanism to protect the credentials."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01254","_id":"cwe_mitigation/cwe_mitigation_01254","_rev":"_dVfOTT2--y","original_id":"522","name":"Insufficiently Protected Credentials","metadata":{"Phase":"Architecture and Design","Description":"Make appropriate use of cryptography to protect the credentials."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01255","_id":"cwe_mitigation/cwe_mitigation_01255","_rev":"_dVfOTT2--z","original_id":"522","name":"Insufficiently Protected Credentials","metadata":{"Phase":"Implementation","Description":"Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01256","_id":"cwe_mitigation/cwe_mitigation_01256","_rev":"_dVfOTT2--0","original_id":"523","name":"Unprotected Transport of Credentials","metadata":{"Phase":"Operation","Description":"Enforce SSL use for the login page or any page used to transmit user credentials or other sensitive information. Even if the entire site does not use SSL, it MUST use SSL for login. Additionally, to help prevent phishing attacks, make sure that SSL serves the login page. SSL allows the user to verify the identity of the server to which they are connecting. If the SSL serves login page, the user can be certain they are talking to the proper end system. A phishing attack would typically redirect a user to a site that does not have a valid trusted server certificate issued from an authorized supplier."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01257","_id":"cwe_mitigation/cwe_mitigation_01257","_rev":"_dVfOTT2--1","original_id":"524","name":"Use of Cache Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"Protect information stored in cache."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01258","_id":"cwe_mitigation/cwe_mitigation_01258","_rev":"_dVfOTT2--2","original_id":"524","name":"Use of Cache Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"Do not store unnecessarily sensitive information in the cache."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01259","_id":"cwe_mitigation/cwe_mitigation_01259","_rev":"_dVfOTT2--3","original_id":"524","name":"Use of Cache Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"Consider using encryption in the cache."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01260","_id":"cwe_mitigation/cwe_mitigation_01260","_rev":"_dVfOTT2--4","original_id":"525","name":"Use of Web Browser Cache Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"Protect information stored in cache."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01261","_id":"cwe_mitigation/cwe_mitigation_01261","_rev":"_dVfOTT2--5","original_id":"525","name":"Use of Web Browser Cache Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"Use a restrictive caching policy for forms and web pages that potentially contain sensitive information."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01262","_id":"cwe_mitigation/cwe_mitigation_01262","_rev":"_dVfOTT2--6","original_id":"525","name":"Use of Web Browser Cache Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"Do not store unnecessarily sensitive information in the cache."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01263","_id":"cwe_mitigation/cwe_mitigation_01263","_rev":"_dVfOTT2--7","original_id":"525","name":"Use of Web Browser Cache Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"Consider using encryption in the cache."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01264","_id":"cwe_mitigation/cwe_mitigation_01264","_rev":"_dVfOTT2--8","original_id":"526","name":"Exposure of Sensitive Information Through Environmental Variables","metadata":{"Phase":"Architecture and Design","Description":"Protect information stored in environment variable from being exposed to the user."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01265","_id":"cwe_mitigation/cwe_mitigation_01265","_rev":"_dVfOTT2--9","original_id":"527","name":"Exposure of Version-Control Repository to an Unauthorized Control Sphere","metadata":{"Phase":"Operation","Description":"Recommendations include removing any CVS directories and repositories from the production server, disabling the use of remote CVS repositories, and ensuring that the latest CVS patches and version updates have been performed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01266","_id":"cwe_mitigation/cwe_mitigation_01266","_rev":"_dVfOTT2-_-","original_id":"528","name":"Exposure of Core Dump File to an Unauthorized Control Sphere","metadata":{"Phase":"System Configuration","Description":"Protect the core dump files from unauthorized access."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01267","_id":"cwe_mitigation/cwe_mitigation_01267","_rev":"_dVfOTT2-__","original_id":"529","name":"Exposure of Access Control List Files to an Unauthorized Control Sphere","metadata":{"Phase":"System Configuration","Description":"Protect access control list files."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01268","_id":"cwe_mitigation/cwe_mitigation_01268","_rev":"_dVfOTT2-_A","original_id":"530","name":"Exposure of Backup File to an Unauthorized Control Sphere","metadata":{"Phase":"Policy","Description":"Recommendations include implementing a security policy within your organization that prohibits backing up web application source code in the webroot."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01269","_id":"cwe_mitigation/cwe_mitigation_01269","_rev":"_dVfOTT2-_B","original_id":"531","name":"Inclusion of Sensitive Information in Test Code","metadata":{"Phase":"Distribution","Description":"Remove test code before deploying the application into production."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01270","_id":"cwe_mitigation/cwe_mitigation_01270","_rev":"_dVfOTT6---","original_id":"532","name":"Insertion of Sensitive Information into Log File","metadata":{"Phase":"Architecture and Design","Description":"Consider seriously the sensitivity of the information written into log files. Do not write secrets into the log files."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01271","_id":"cwe_mitigation/cwe_mitigation_01271","_rev":"_dVfOTT6--_","original_id":"532","name":"Insertion of Sensitive Information into Log File","metadata":{"Phase":"Distribution","Description":"Remove debug log files before deploying the application into production."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01272","_id":"cwe_mitigation/cwe_mitigation_01272","_rev":"_dVfOTT6--A","original_id":"532","name":"Insertion of Sensitive Information into Log File","metadata":{"Phase":"Operation","Description":"Protect log files against unauthorized read/write."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01273","_id":"cwe_mitigation/cwe_mitigation_01273","_rev":"_dVfOTT6--B","original_id":"532","name":"Insertion of Sensitive Information into Log File","metadata":{"Phase":"Implementation","Description":"Adjust configurations appropriately when software is transitioned from a debug state to production."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01274","_id":"cwe_mitigation/cwe_mitigation_01274","_rev":"_dVfOTT6--C","original_id":"537","name":"Java Runtime Error Message Containing Sensitive Information","metadata":{"Phase":"Implementation","Description":"Do not expose sensitive error information to the user."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01275","_id":"cwe_mitigation/cwe_mitigation_01275","_rev":"_dVfOTT6--D","original_id":"538","name":"Insertion of Sensitive Information into Externally-Accessible File or Directory","metadata":{"Phase":"Architecture and Design","Description":"Do not expose file and directory information to the user."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01276","_id":"cwe_mitigation/cwe_mitigation_01276","_rev":"_dVfOTT6--E","original_id":"539","name":"Use of Persistent Cookies Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"Do not store sensitive information in persistent cookies."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01277","_id":"cwe_mitigation/cwe_mitigation_01277","_rev":"_dVfOTT6--F","original_id":"540","name":"Inclusion of Sensitive Information in Source Code","metadata":{"Phase":"Architecture and Design","Description":"Recommendations include removing this script from the web server and moving it to a location not accessible from the Internet."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01278","_id":"cwe_mitigation/cwe_mitigation_01278","_rev":"_dVfOTT6--G","original_id":"541","name":"Inclusion of Sensitive Information in an Include File","metadata":{"Phase":"Architecture and Design","Description":"Do not store sensitive information in include files."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01279","_id":"cwe_mitigation/cwe_mitigation_01279","_rev":"_dVfOTT6--H","original_id":"541","name":"Inclusion of Sensitive Information in an Include File","metadata":{"Phase":"Architecture and Design","Description":"Protect include files from being exposed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01280","_id":"cwe_mitigation/cwe_mitigation_01280","_rev":"_dVfOTT6--I","original_id":"543","name":"Use of Singleton Pattern Without Synchronization in a Multithreaded Context","metadata":{"Phase":"Architecture and Design","Description":"Use the Thread-Specific Storage Pattern. See References."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01281","_id":"cwe_mitigation/cwe_mitigation_01281","_rev":"_dVfOTT6--J","original_id":"543","name":"Use of Singleton Pattern Without Synchronization in a Multithreaded Context","metadata":{"Phase":"Implementation","Description":"Do not use member fields to store information in the Servlet. In multithreading environments, storing user data in Servlet member fields introduces a data access race condition."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01282","_id":"cwe_mitigation/cwe_mitigation_01282","_rev":"_dVfOTT6--K","original_id":"543","name":"Use of Singleton Pattern Without Synchronization in a Multithreaded Context","metadata":{"Phase":"Implementation","Description":"Avoid using the double-checked locking pattern in language versions that cannot guarantee thread safety. This pattern may be used to avoid the overhead of a synchronized call, but in certain versions of Java (for example), this has been shown to be unsafe because it still introduces a race condition (CWE-209)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01283","_id":"cwe_mitigation/cwe_mitigation_01283","_rev":"_dVfOTT6--L","original_id":"544","name":"Missing Standardized Error Handling Mechanism","metadata":{"Phase":"Architecture and Design","Description":"define a strategy for handling errors of different severities, such as fatal errors versus basic log events. Use or create built-in language features, or an external package, that provides an easy-to-use API and define coding standards for the detection and handling of errors."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01284","_id":"cwe_mitigation/cwe_mitigation_01284","_rev":"_dVfOTT6--M","original_id":"546","name":"Suspicious Comment","metadata":{"Phase":"Documentation","Description":"Remove comments that suggest the presence of bugs, incomplete functionality, or weaknesses, before deploying the application."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01285","_id":"cwe_mitigation/cwe_mitigation_01285","_rev":"_dVfOTT6--N","original_id":"547","name":"Use of Hard-coded, Security-relevant Constants","metadata":{"Phase":"Implementation","Description":"Avoid using hard-coded constants. Configuration files offer a more flexible solution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01286","_id":"cwe_mitigation/cwe_mitigation_01286","_rev":"_dVfOTT6--O","original_id":"548","name":"Exposure of Information Through Directory Listing","metadata":{"Phase":"Architecture and Design","Description":"Recommendations include restricting access to important directories or files by adopting a need to know requirement for both the document and server root, and turning off features such as Automatic Directory Listings that could expose private files and provide information that could be utilized by an attacker when formulating or conducting an attack."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01287","_id":"cwe_mitigation/cwe_mitigation_01287","_rev":"_dVfOTT6--P","original_id":"549","name":"Missing Password Field Masking","metadata":{"Phase":"Implementation","Description":"Recommendations include requiring all password fields in your web application be masked to prevent other users from seeing this information."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01288","_id":"cwe_mitigation/cwe_mitigation_01288","_rev":"_dVfOTT6--Q","original_id":"550","name":"Server-generated Error Message Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"Recommendations include designing and adding consistent error handling mechanisms which are capable of handling any user input to your web application, providing meaningful detail to end-users, and preventing error messages that might provide information useful to an attacker from being displayed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01289","_id":"cwe_mitigation/cwe_mitigation_01289","_rev":"_dVfOTT6--R","original_id":"551","name":"Incorrect Behavior Order: Authorization Before Parsing and Canonicalization","metadata":{"Phase":"Architecture and Design","Description":"URL Inputs should be decoded and canonicalized to the application's current internal representation before being validated and processed for authorization. Make sure that your application does not decode the same input twice. Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01290","_id":"cwe_mitigation/cwe_mitigation_01290","_rev":"_dVfOTT6--S","original_id":"553","name":"Command Shell in Externally Accessible Directory","metadata":{"Phase":"Installation","Description":"Remove any Shells accessible under the web root folder and children directories."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01291","_id":"cwe_mitigation/cwe_mitigation_01291","_rev":"_dVfOTT6--T","original_id":"554","name":"ASP.NET Misconfiguration: Not Using Input Validation Framework","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use the ASP.NET validation framework to check all program input before it is processed by the application. Example uses of the validation framework include checking to ensure that:\n                  \n                     \n                        Phone number fields contain only valid characters in phone numbers\n                        Boolean values are only \"T\" or \"F\"\n                        Free-form strings are of a reasonable length and composition\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01292","_id":"cwe_mitigation/cwe_mitigation_01292","_rev":"_dVfOTT6--U","original_id":"555","name":"J2EE Misconfiguration: Plaintext Password in Configuration File","metadata":{"Phase":"Architecture and Design","Description":"Do not hardwire passwords into your software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01293","_id":"cwe_mitigation/cwe_mitigation_01293","_rev":"_dVfOTT6--V","original_id":"555","name":"J2EE Misconfiguration: Plaintext Password in Configuration File","metadata":{"Phase":"Architecture and Design","Description":"Use industry standard libraries to encrypt passwords before storage in configuration files."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01294","_id":"cwe_mitigation/cwe_mitigation_01294","_rev":"_dVfOTT6--W","original_id":"556","name":"ASP.NET Misconfiguration: Use of Identity Impersonation","metadata":{"Phase":"Architecture and Design","Description":"Use the least privilege principle."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01295","_id":"cwe_mitigation/cwe_mitigation_01295","_rev":"_dVfOTT6--X","original_id":"558","name":"Use of getlogin() in Multithreaded Application","metadata":{"Phase":"Architecture and Design","Description":"Using names for security purposes is not advised. Names are easy to forge and can have overlapping user IDs, potentially causing confusion or impersonation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01296","_id":"cwe_mitigation/cwe_mitigation_01296","_rev":"_dVfOTT6--Y","original_id":"558","name":"Use of getlogin() in Multithreaded Application","metadata":{"Phase":"Implementation","Description":"Use getlogin_r() instead, which is reentrant, meaning that other processes are locked out from changing the username."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01297","_id":"cwe_mitigation/cwe_mitigation_01297","_rev":"_dVfOTT6--Z","original_id":"560","name":"Use of umask() with chmod-style Argument","metadata":{"Phase":"Implementation","Description":"Use umask() with the correct argument."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01298","_id":"cwe_mitigation/cwe_mitigation_01298","_rev":"_dVfOTT6--a","original_id":"560","name":"Use of umask() with chmod-style Argument","metadata":{"Phase":"Testing","Description":"If you suspect misuse of umask(), you can use grep to spot call instances of umask()."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01299","_id":"cwe_mitigation/cwe_mitigation_01299","_rev":"_dVfOTT6--b","original_id":"561","name":"Dead Code","metadata":{"Phase":"Implementation","Description":"Remove dead code before deploying the application."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01300","_id":"cwe_mitigation/cwe_mitigation_01300","_rev":"_dVfOTT6--c","original_id":"561","name":"Dead Code","metadata":{"Phase":"Testing","Description":"Use a static analysis tool to spot dead code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01308","_id":"cwe_mitigation/cwe_mitigation_01308","_rev":"_dVfOTT6--d","original_id":"562","name":"Return of Stack Variable Address","metadata":{"Phase":"Testing","Description":"Use static analysis tools to spot return of the address of a stack variable."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01309","_id":"cwe_mitigation/cwe_mitigation_01309","_rev":"_dVfOTT6--e","original_id":"563","name":"Assignment to Variable without Use","metadata":{"Phase":"Implementation","Description":"Remove unused variables from the code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01310","_id":"cwe_mitigation/cwe_mitigation_01310","_rev":"_dVfOTT6--f","original_id":"564","name":"SQL Injection: Hibernate","metadata":{"Phase":"Requirements","Description":"A non-SQL style database which is not subject to this flaw may be chosen."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01311","_id":"cwe_mitigation/cwe_mitigation_01311","_rev":"_dVfOTT6--g","original_id":"564","name":"SQL Injection: Hibernate","metadata":{"Phase":"Architecture and Design","Description":"Follow the principle of least privilege when creating user accounts to a SQL database. Users should only have the minimum privileges necessary to use their account. If the requirements of the system indicate that a user can read and modify their own data, then limit their privileges so they cannot read/write others' data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01312","_id":"cwe_mitigation/cwe_mitigation_01312","_rev":"_dVfOTT6--h","original_id":"564","name":"SQL Injection: Hibernate","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01313","_id":"cwe_mitigation/cwe_mitigation_01313","_rev":"_dVfOTT6--i","original_id":"564","name":"SQL Injection: Hibernate","metadata":{"Phase":"Implementation","Description":"Implement SQL strings using prepared statements that bind variables. Prepared statements that do not bind variables can be vulnerable to attack."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01314","_id":"cwe_mitigation/cwe_mitigation_01314","_rev":"_dVfOTT6--j","original_id":"564","name":"SQL Injection: Hibernate","metadata":{"Phase":"Implementation","Description":"Use vigorous allowlist style checking on any user input that may be used in a SQL command. Rather than escape meta-characters, it is safest to disallow them entirely. Reason: Later use of data that have been entered in the database may neglect to escape meta-characters before use. Narrowly define the set of safe characters based on the expected value of the parameter in the request."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01315","_id":"cwe_mitigation/cwe_mitigation_01315","_rev":"_dVfOTT6--k","original_id":"565","name":"Reliance on Cookies without Validation and Integrity Checking","metadata":{"Phase":"Architecture and Design","Description":"Avoid using cookie data for a security-related decision."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01316","_id":"cwe_mitigation/cwe_mitigation_01316","_rev":"_dVfOTT6--l","original_id":"565","name":"Reliance on Cookies without Validation and Integrity Checking","metadata":{"Phase":"Implementation","Description":"Perform thorough input validation (i.e.: server side validation) on the cookie data if you're going to use it for a security related decision."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01317","_id":"cwe_mitigation/cwe_mitigation_01317","_rev":"_dVfOTT6--m","original_id":"565","name":"Reliance on Cookies without Validation and Integrity Checking","metadata":{"Phase":"Architecture and Design","Description":"Add integrity checks to detect tampering."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01318","_id":"cwe_mitigation/cwe_mitigation_01318","_rev":"_dVfOTT6--n","original_id":"565","name":"Reliance on Cookies without Validation and Integrity Checking","metadata":{"Phase":"Architecture and Design","Description":"Protect critical cookies from replay attacks, since cross-site scripting or other attacks may allow attackers to steal a strongly-encrypted cookie that also passes integrity checks. This mitigation applies to cookies that should only be valid during a single transaction or session. By enforcing timeouts, you may limit the scope of an attack. As part of your integrity check, use an unpredictable, server-side value that is not exposed to the client."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01319","_id":"cwe_mitigation/cwe_mitigation_01319","_rev":"_dVfOTT6--o","original_id":"566","name":"Authorization Bypass Through User-Controlled SQL Primary Key","metadata":{"Phase":"Implementation","Description":"Assume all input is malicious. Use a standard input validation mechanism to validate all input for length, type, syntax, and business rules before accepting the data. Use an \"accept known good\" validation strategy."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01320","_id":"cwe_mitigation/cwe_mitigation_01320","_rev":"_dVfOTT6--p","original_id":"566","name":"Authorization Bypass Through User-Controlled SQL Primary Key","metadata":{"Phase":"Implementation","Description":"Use a parameterized query AND make sure that the accepted values conform to the business rules. Construct your SQL statement accordingly."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01321","_id":"cwe_mitigation/cwe_mitigation_01321","_rev":"_dVfOTT6--q","original_id":"567","name":"Unsynchronized Access to Shared Data in a Multithreaded Context","metadata":{"Phase":"Implementation","Description":"Remove the use of static variables used between servlets. If this cannot be avoided, use synchronized access for these variables."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01322","_id":"cwe_mitigation/cwe_mitigation_01322","_rev":"_dVfOTT6--r","original_id":"568","name":"finalize() Method Without super.finalize()","metadata":{"Phase":"Implementation","Description":"Call the super.finalize() method."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01323","_id":"cwe_mitigation/cwe_mitigation_01323","_rev":"_dVfOTT6--s","original_id":"568","name":"finalize() Method Without super.finalize()","metadata":{"Phase":"Testing","Description":"Use static analysis tools to spot such issues in your code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01324","_id":"cwe_mitigation/cwe_mitigation_01324","_rev":"_dVfOTT6--t","original_id":"570","name":"Expression is Always False","metadata":{"Phase":"Testing","Description":"Use Static Analysis tools to spot such conditions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01325","_id":"cwe_mitigation/cwe_mitigation_01325","_rev":"_dVfOTT6--u","original_id":"571","name":"Expression is Always True","metadata":{"Phase":"Testing","Description":"Use Static Analysis tools to spot such conditions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01326","_id":"cwe_mitigation/cwe_mitigation_01326","_rev":"_dVfOTT6--v","original_id":"572","name":"Call to Thread run() instead of start()","metadata":{"Phase":"Implementation","Description":"Use the start() method instead of the run() method."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01327","_id":"cwe_mitigation/cwe_mitigation_01327","_rev":"_dVfOTT6--w","original_id":"574","name":"EJB Bad Practices: Use of Synchronization Primitives","metadata":{"Phase":"Implementation","Description":"Do not use Synchronization Primitives when writing EJBs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01328","_id":"cwe_mitigation/cwe_mitigation_01328","_rev":"_dVfOTT6--x","original_id":"575","name":"EJB Bad Practices: Use of AWT Swing","metadata":{"Phase":"Architecture and Design","Description":"Do not use AWT/Swing when writing EJBs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01329","_id":"cwe_mitigation/cwe_mitigation_01329","_rev":"_dVfOTT6--y","original_id":"576","name":"EJB Bad Practices: Use of Java I/O","metadata":{"Phase":"Implementation","Description":"Do not use Java I/O when writing EJBs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01330","_id":"cwe_mitigation/cwe_mitigation_01330","_rev":"_dVfOTT6--z","original_id":"577","name":"EJB Bad Practices: Use of Sockets","metadata":{"Phase":"Architecture and Design","Description":"Do not use Sockets when writing EJBs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01331","_id":"cwe_mitigation/cwe_mitigation_01331","_rev":"_dVfOTT6--0","original_id":"578","name":"EJB Bad Practices: Use of Class Loader","metadata":{"Phase":"Architecture and Design","Description":"Do not use the Class Loader when writing EJBs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01332","_id":"cwe_mitigation/cwe_mitigation_01332","_rev":"_dVfOTT6--1","original_id":"579","name":"J2EE Bad Practices: Non-serializable Object Stored in Session","metadata":{"Phase":"Implementation","Description":"In order for session replication to work, the values the application stores as attributes in the session must implement the Serializable interface."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01333","_id":"cwe_mitigation/cwe_mitigation_01333","_rev":"_dVfOTT6--2","original_id":"580","name":"clone() Method Without super.clone()","metadata":{"Phase":"Implementation","Description":"Call super.clone() within your clone() method, when obtaining a new object."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01334","_id":"cwe_mitigation/cwe_mitigation_01334","_rev":"_dVfOTT6--3","original_id":"580","name":"clone() Method Without super.clone()","metadata":{"Phase":"Implementation","Description":"In some cases, you can eliminate the clone method altogether and use copy constructors."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01335","_id":"cwe_mitigation/cwe_mitigation_01335","_rev":"_dVfOTT6--4","original_id":"581","name":"Object Model Violation: Just One of Equals and Hashcode Defined","metadata":{"Phase":"Implementation","Description":"Both Equals() and Hashcode() should be defined."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01336","_id":"cwe_mitigation/cwe_mitigation_01336","_rev":"_dVfOTT6--5","original_id":"582","name":"Array Declared Public, Final, and Static","metadata":{"Phase":"Implementation","Description":"In most situations the array should be made private."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01337","_id":"cwe_mitigation/cwe_mitigation_01337","_rev":"_dVfOTT6--6","original_id":"583","name":"finalize() Method Declared Public","metadata":{"Phase":"Implementation","Description":"If you are using finalize() as it was designed, there is no reason to declare finalize() with anything other than protected access."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01338","_id":"cwe_mitigation/cwe_mitigation_01338","_rev":"_dVfOTT6--7","original_id":"584","name":"Return Inside Finally Block","metadata":{"Phase":"Implementation","Description":"Do not use a return statement inside the finally block. The finally block should have \"cleanup\" code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01339","_id":"cwe_mitigation/cwe_mitigation_01339","_rev":"_dVfOTT6--8","original_id":"585","name":"Empty Synchronized Block","metadata":{"Phase":"Implementation","Description":"When you come across an empty synchronized statement, or a synchronized statement in which the code has been commented out, try to determine what the original intentions were and whether or not the synchronized block is still necessary."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01340","_id":"cwe_mitigation/cwe_mitigation_01340","_rev":"_dVfOTT6--9","original_id":"586","name":"Explicit Call to Finalize()","metadata":{"Phase":"Implementation","Description":"Do not make explicit calls to finalize(). Use static analysis tools to spot such instances."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01341","_id":"cwe_mitigation/cwe_mitigation_01341","_rev":"_dVfOTT6-_-","original_id":"587","name":"Assignment of a Fixed Address to a Pointer","metadata":{"Phase":"Implementation","Description":"Never set a pointer to a fixed address."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01342","_id":"cwe_mitigation/cwe_mitigation_01342","_rev":"_dVfOTT6-__","original_id":"588","name":"Attempt to Access Child of a Non-structure Pointer","metadata":{"Phase":"Requirements","Description":"The choice could be made to use a language that is not susceptible to these issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01343","_id":"cwe_mitigation/cwe_mitigation_01343","_rev":"_dVfOTT6-_A","original_id":"588","name":"Attempt to Access Child of a Non-structure Pointer","metadata":{"Phase":"Implementation","Description":"Review of type casting operations can identify locations where incompatible types are cast."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01344","_id":"cwe_mitigation/cwe_mitigation_01344","_rev":"_dVfOTT6-_B","original_id":"589","name":"Call to Non-ubiquitous API","metadata":{"Phase":"Implementation","Description":"Always test your code on any platform on which it is targeted to run on."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01345","_id":"cwe_mitigation/cwe_mitigation_01345","_rev":"_dVfOTU----","original_id":"589","name":"Call to Non-ubiquitous API","metadata":{"Phase":"Testing","Description":"Test your code on the newest and oldest platform on which it is targeted to run on."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01346","_id":"cwe_mitigation/cwe_mitigation_01346","_rev":"_dVfOTU---_","original_id":"589","name":"Call to Non-ubiquitous API","metadata":{"Phase":"Testing","Description":"Develop a system to test for API functions that are not portable."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01347","_id":"cwe_mitigation/cwe_mitigation_01347","_rev":"_dVfOTU---A","original_id":"590","name":"Free of Memory not on the Heap","metadata":{"Phase":"Implementation","Description":"Only free pointers that you have called malloc on previously. This is the recommended solution. Keep track of which pointers point at the beginning of valid chunks and free them only once."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01348","_id":"cwe_mitigation/cwe_mitigation_01348","_rev":"_dVfOTU---B","original_id":"590","name":"Free of Memory not on the Heap","metadata":{"Phase":"Implementation","Description":"Before freeing a pointer, the programmer should make sure that the pointer was previously allocated on the heap and that the memory belongs to the programmer. Freeing an unallocated pointer will cause undefined behavior in the program."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01349","_id":"cwe_mitigation/cwe_mitigation_01349","_rev":"_dVfOTU---C","original_id":"590","name":"Free of Memory not on the Heap","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, glibc in Linux provides protection against free of invalid pointers.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01350","_id":"cwe_mitigation/cwe_mitigation_01350","_rev":"_dVfOTU---D","original_id":"590","name":"Free of Memory not on the Heap","metadata":{"Phase":"Architecture and Design","Description":"Use a language that provides abstractions for memory allocation and deallocation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01351","_id":"cwe_mitigation/cwe_mitigation_01351","_rev":"_dVfOTU---E","original_id":"590","name":"Free of Memory not on the Heap","metadata":{"Phase":"Testing","Description":"Use a tool that dynamically detects memory management problems, such as valgrind."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01352","_id":"cwe_mitigation/cwe_mitigation_01352","_rev":"_dVfOTU---F","original_id":"591","name":"Sensitive Data Storage in Improperly Locked Memory","metadata":{"Phase":"Architecture and Design","Description":"Identify data that needs to be protected from swapping and choose platform-appropriate protection mechanisms."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01353","_id":"cwe_mitigation/cwe_mitigation_01353","_rev":"_dVfOTU---G","original_id":"591","name":"Sensitive Data Storage in Improperly Locked Memory","metadata":{"Phase":"Implementation","Description":"Check return values to ensure locking operations are successful."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01354","_id":"cwe_mitigation/cwe_mitigation_01354","_rev":"_dVfOTU---H","original_id":"593","name":"Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created","metadata":{"Phase":"Architecture and Design","Description":"Use a language or a library that provides a cryptography framework at a higher level of abstraction."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01355","_id":"cwe_mitigation/cwe_mitigation_01355","_rev":"_dVfOTU---I","original_id":"593","name":"Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created","metadata":{"Phase":"Implementation","Description":"Most SSL_CTX functions have SSL counterparts that act on SSL-type objects."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01356","_id":"cwe_mitigation/cwe_mitigation_01356","_rev":"_dVfOTU---J","original_id":"593","name":"Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created","metadata":{"Phase":"Implementation","Description":"Applications should set up an SSL_CTX completely, before creating SSL objects from it."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01357","_id":"cwe_mitigation/cwe_mitigation_01357","_rev":"_dVfOTU---K","original_id":"594","name":"J2EE Framework: Saving Unserializable Objects to Disk","metadata":{"Phase":"Architecture and Design","Description":"All objects that become part of session and application scope must implement the java.io.Serializable interface to ensure serializability of containing objects."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01358","_id":"cwe_mitigation/cwe_mitigation_01358","_rev":"_dVfOTU---L","original_id":"595","name":"Comparison of Object References Instead of Object Contents","metadata":{"Phase":"Implementation","Description":"In Java, use the equals() method to compare objects instead of the == operator. If using ==, it is important for performance reasons that your objects are created by a static factory, not by a constructor."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01359","_id":"cwe_mitigation/cwe_mitigation_01359","_rev":"_dVfOTU---M","original_id":"597","name":"Use of Wrong Operator in String Comparison","metadata":{"Phase":"Implementation","Description":"Within Java, use .equals() to compare string values.\n               Within JavaScript, use == to compare string values.\n               Within PHP, use == to compare a numeric value to a string value. (PHP converts the string to a number.)\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01360","_id":"cwe_mitigation/cwe_mitigation_01360","_rev":"_dVfOTU---N","original_id":"598","name":"Use of GET Request Method With Sensitive Query Strings","metadata":{"Phase":"Implementation","Description":"When sensitive information is sent, use the POST method (e.g. registration form)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01361","_id":"cwe_mitigation/cwe_mitigation_01361","_rev":"_dVfOTU---O","original_id":"599","name":"Missing Validation of OpenSSL Certificate","metadata":{"Phase":"Architecture and Design","Description":"Ensure that proper authentication is included in the system design."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01362","_id":"cwe_mitigation/cwe_mitigation_01362","_rev":"_dVfOTU---P","original_id":"599","name":"Missing Validation of OpenSSL Certificate","metadata":{"Phase":"Implementation","Description":"Understand and properly implement all checks necessary to ensure the identity of entities involved in encrypted communications."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01363","_id":"cwe_mitigation/cwe_mitigation_01363","_rev":"_dVfOTU---Q","original_id":"600","name":"Uncaught Exception in Servlet ","metadata":{"Phase":"Implementation","Description":"Implement Exception blocks to handle all types of Exceptions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01364","_id":"cwe_mitigation/cwe_mitigation_01364","_rev":"_dVfOTU---R","original_id":"601","name":"URL Redirection to Untrusted Site ('Open Redirect')","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  Use a list of approved URLs or domains to be used for redirection.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01365","_id":"cwe_mitigation/cwe_mitigation_01365","_rev":"_dVfOTU---S","original_id":"601","name":"URL Redirection to Untrusted Site ('Open Redirect')","metadata":{"Phase":"Architecture and Design","Description":"Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01366","_id":"cwe_mitigation/cwe_mitigation_01366","_rev":"_dVfOTU---T","original_id":"601","name":"URL Redirection to Untrusted Site ('Open Redirect')","metadata":{"Phase":"Architecture and Design","Description":"\n                  When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.\n                  For example, ID 1 could map to \"/login.asp\" and ID 2 could map to \"http://www.example.com/\". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01367","_id":"cwe_mitigation/cwe_mitigation_01367","_rev":"_dVfOTU---U","original_id":"601","name":"URL Redirection to Untrusted Site ('Open Redirect')","metadata":{"Phase":"Architecture and Design","Description":"Ensure that no externally-supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application [REF-483]. Be sure that the nonce is not predictable (CWE-330)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01368","_id":"cwe_mitigation/cwe_mitigation_01368","_rev":"_dVfOTU---V","original_id":"601","name":"URL Redirection to Untrusted Site ('Open Redirect')","metadata":{"Phase":"Architecture and Design","Description":"\n                  Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.\n                  Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01369","_id":"cwe_mitigation/cwe_mitigation_01369","_rev":"_dVfOTU---W","original_id":"601","name":"URL Redirection to Untrusted Site ('Open Redirect')","metadata":{"Phase":"Operation","Description":"Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01380","_id":"cwe_mitigation/cwe_mitigation_01380","_rev":"_dVfOTU---X","original_id":"602","name":"Client-Side Enforcement of Server-Side Security","metadata":{"Phase":"Architecture and Design","Description":"\n                  For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.\n                  Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01381","_id":"cwe_mitigation/cwe_mitigation_01381","_rev":"_dVfOTU---Y","original_id":"602","name":"Client-Side Enforcement of Server-Side Security","metadata":{"Phase":"Architecture and Design","Description":"If some degree of trust is required between the two entities, then use integrity checking and strong authentication to ensure that the inputs are coming from a trusted source. Design the product so that this trust is managed in a centralized fashion, especially if there are complex or numerous communication channels, in order to reduce the risks that the implementer will mistakenly omit a check in a single code path."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01382","_id":"cwe_mitigation/cwe_mitigation_01382","_rev":"_dVfOTU---Z","original_id":"602","name":"Client-Side Enforcement of Server-Side Security","metadata":{"Phase":"Testing","Description":"Use dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01383","_id":"cwe_mitigation/cwe_mitigation_01383","_rev":"_dVfOTU---a","original_id":"602","name":"Client-Side Enforcement of Server-Side Security","metadata":{"Phase":"Testing","Description":"Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01384","_id":"cwe_mitigation/cwe_mitigation_01384","_rev":"_dVfOTU---b","original_id":"603","name":"Use of Client-Side Authentication","metadata":{"Phase":"Architecture and Design","Description":"Do not rely on client side data. Always perform server side authentication."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01385","_id":"cwe_mitigation/cwe_mitigation_01385","_rev":"_dVfOTU---c","original_id":"605","name":"Multiple Binds to the Same Port","metadata":{"Phase":"Policy","Description":"Restrict server socket address to known local addresses."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01386","_id":"cwe_mitigation/cwe_mitigation_01386","_rev":"_dVfOTU---d","original_id":"606","name":"Unchecked Input for Loop Condition","metadata":{"Phase":"Implementation","Description":"Do not use user-controlled data for loop conditions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01387","_id":"cwe_mitigation/cwe_mitigation_01387","_rev":"_dVfOTU---e","original_id":"606","name":"Unchecked Input for Loop Condition","metadata":{"Phase":"Implementation","Description":"Perform input validation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01388","_id":"cwe_mitigation/cwe_mitigation_01388","_rev":"_dVfOTU---f","original_id":"607","name":"Public Static Final Field References Mutable Object","metadata":{"Phase":"Implementation","Description":"Protect mutable objects by making them private. Restrict access to the getter and setter as well."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01389","_id":"cwe_mitigation/cwe_mitigation_01389","_rev":"_dVfOTU---g","original_id":"608","name":"Struts: Non-private Field in ActionForm Class","metadata":{"Phase":"Implementation","Description":"Make all fields private. Use getter to get the value of the field. Setter should be used only by the framework; setting an action form field from other actions is bad practice and should be avoided."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01390","_id":"cwe_mitigation/cwe_mitigation_01390","_rev":"_dVfOTU---h","original_id":"609","name":"Double-Checked Locking","metadata":{"Phase":"Implementation","Description":"While double-checked locking can be achieved in some languages, it is inherently flawed in Java before 1.5, and cannot be achieved without compromising platform independence. Before Java 1.5, only use of the synchronized keyword is known to work. Beginning in Java 1.5, use of the \"volatile\" keyword allows double-checked locking to work successfully, although there is some debate as to whether it achieves sufficient performance gains. See references."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01391","_id":"cwe_mitigation/cwe_mitigation_01391","_rev":"_dVfOTU---i","original_id":"611","name":"Improper Restriction of XML External Entity Reference","metadata":{"Phase":"Implementation","Description":"Many XML parsers and validators can be configured to disable external entity expansion."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01392","_id":"cwe_mitigation/cwe_mitigation_01392","_rev":"_dVfOTU---j","original_id":"613","name":"Insufficient Session Expiration","metadata":{"Phase":"Implementation","Description":"Set sessions/credentials expiration date."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01393","_id":"cwe_mitigation/cwe_mitigation_01393","_rev":"_dVfOTU---k","original_id":"614","name":"Sensitive Cookie in HTTPS Session Without 'Secure' Attribute","metadata":{"Phase":"Implementation","Description":"Always set the secure attribute when the cookie should sent via HTTPS only."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01394","_id":"cwe_mitigation/cwe_mitigation_01394","_rev":"_dVfOTU---l","original_id":"615","name":"Inclusion of Sensitive Information in Source Code Comments","metadata":{"Phase":"Distribution","Description":"Remove comments which have sensitive information about the design/implementation of the application. Some of the comments may be exposed to the user and affect the security posture of the application."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01395","_id":"cwe_mitigation/cwe_mitigation_01395","_rev":"_dVfOTU---m","original_id":"616","name":"Incomplete Identification of Uploaded File Variables (PHP)","metadata":{"Phase":"Architecture and Design","Description":"Use PHP 4 or later."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01396","_id":"cwe_mitigation/cwe_mitigation_01396","_rev":"_dVfOTU---n","original_id":"616","name":"Incomplete Identification of Uploaded File Variables (PHP)","metadata":{"Phase":"Architecture and Design","Description":"If you must support older PHP versions, write your own version of is_uploaded_file() and run it against $HTTP_POST_FILES['userfile']))"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01397","_id":"cwe_mitigation/cwe_mitigation_01397","_rev":"_dVfOTU---o","original_id":"616","name":"Incomplete Identification of Uploaded File Variables (PHP)","metadata":{"Phase":"Implementation","Description":"For later PHP versions, reference uploaded files using the $HTTP_POST_FILES or $_FILES variables, and use is_uploaded_file() or move_uploaded_file() to ensure that you are dealing with an uploaded file."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01398","_id":"cwe_mitigation/cwe_mitigation_01398","_rev":"_dVfOTU---p","original_id":"617","name":"Reachable Assertion","metadata":{"Phase":"Implementation","Description":"Make sensitive open/close operation non reachable by directly user-controlled data (e.g. open/close resources)"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01399","_id":"cwe_mitigation/cwe_mitigation_01399","_rev":"_dVfOTU---q","original_id":"617","name":"Reachable Assertion","metadata":{"Phase":"Implementation","Description":"Perform input validation on user data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01400","_id":"cwe_mitigation/cwe_mitigation_01400","_rev":"_dVfOTU---r","original_id":"618","name":"Exposed Unsafe ActiveX Method","metadata":{"Phase":"Implementation","Description":"If you must expose a method, make sure to perform input validation on all arguments, and protect against all possible vulnerabilities."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01401","_id":"cwe_mitigation/cwe_mitigation_01401","_rev":"_dVfOTU---s","original_id":"618","name":"Exposed Unsafe ActiveX Method","metadata":{"Phase":"Architecture and Design","Description":"Use code signing, although this does not protect against any weaknesses that are already in the control."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01402","_id":"cwe_mitigation/cwe_mitigation_01402","_rev":"_dVfOTU---t","original_id":"618","name":"Exposed Unsafe ActiveX Method","metadata":{"Phase":"Architecture and Design","Description":"Where possible, avoid marking the control as safe for scripting."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01403","_id":"cwe_mitigation/cwe_mitigation_01403","_rev":"_dVfOTU---u","original_id":"619","name":"Dangling Database Cursor ('Cursor Injection')","metadata":{"Phase":"Implementation","Description":"Close cursors immediately after access to them is complete. Ensure that you close cursors if exceptions occur."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01404","_id":"cwe_mitigation/cwe_mitigation_01404","_rev":"_dVfOTU---v","original_id":"620","name":"Unverified Password Change","metadata":{"Phase":"Architecture and Design","Description":"When prompting for a password change, force the user to provide the original password in addition to the new password."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01405","_id":"cwe_mitigation/cwe_mitigation_01405","_rev":"_dVfOTU---w","original_id":"620","name":"Unverified Password Change","metadata":{"Phase":"Architecture and Design","Description":"Do not use \"forgotten password\" functionality. But if you must, ensure that you are only providing information to the actual user, e.g. by using an email address or challenge question that the legitimate user already provided in the past; do not allow the current user to change this identity information until the correct password has been provided."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01406","_id":"cwe_mitigation/cwe_mitigation_01406","_rev":"_dVfOTU---x","original_id":"621","name":"Variable Extraction Error","metadata":{"Phase":"Implementation","Description":"Use allowlists of variable names that can be extracted."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01407","_id":"cwe_mitigation/cwe_mitigation_01407","_rev":"_dVfOTU---y","original_id":"621","name":"Variable Extraction Error","metadata":{"Phase":"Implementation","Description":"Consider refactoring your code to avoid extraction routines altogether."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01408","_id":"cwe_mitigation/cwe_mitigation_01408","_rev":"_dVfOTU---z","original_id":"621","name":"Variable Extraction Error","metadata":{"Phase":"Implementation","Description":"In PHP, call extract() with options such as EXTR_SKIP and EXTR_PREFIX_ALL; call import_request_variables() with a prefix argument. Note that these capabilities are not present in all PHP versions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01409","_id":"cwe_mitigation/cwe_mitigation_01409","_rev":"_dVfOTU---0","original_id":"622","name":"Improper Validation of Function Hook Arguments","metadata":{"Phase":"Architecture and Design","Description":"Ensure that all arguments are verified, as defined by the API you are protecting."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01410","_id":"cwe_mitigation/cwe_mitigation_01410","_rev":"_dVfOTU---1","original_id":"622","name":"Improper Validation of Function Hook Arguments","metadata":{"Phase":"Architecture and Design","Description":"Drop privileges before invoking such functions, if possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01411","_id":"cwe_mitigation/cwe_mitigation_01411","_rev":"_dVfOTU---2","original_id":"623","name":"Unsafe ActiveX Control Marked Safe For Scripting","metadata":{"Phase":"Architecture and Design","Description":"During development, do not mark it as safe for scripting."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01412","_id":"cwe_mitigation/cwe_mitigation_01412","_rev":"_dVfOTU---3","original_id":"623","name":"Unsafe ActiveX Control Marked Safe For Scripting","metadata":{"Phase":"System Configuration","Description":"After distribution, you can set the kill bit for the control so that it is not accessible from Internet Explorer."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01413","_id":"cwe_mitigation/cwe_mitigation_01413","_rev":"_dVfOTU---4","original_id":"624","name":"Executable Regular Expression Error","metadata":{"Phase":"Implementation","Description":"The regular expression feature in some languages allows inputs to be quoted or escaped before insertion, such as \\Q and \\E in Perl."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01414","_id":"cwe_mitigation/cwe_mitigation_01414","_rev":"_dVfOTU---5","original_id":"625","name":"Permissive Regular Expression","metadata":{"Phase":"Implementation","Description":"When applicable, ensure that the regular expression marks beginning and ending string patterns, such as \"/^string$/\" for Perl."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01415","_id":"cwe_mitigation/cwe_mitigation_01415","_rev":"_dVfOTU---6","original_id":"626","name":"Null Byte Interaction Error (Poison Null Byte)","metadata":{"Phase":"Implementation","Description":"Remove null bytes from all incoming strings."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01416","_id":"cwe_mitigation/cwe_mitigation_01416","_rev":"_dVfOTU---7","original_id":"627","name":"Dynamic Variable Evaluation","metadata":{"Phase":"Implementation","Description":"Refactor the code to avoid dynamic variable evaluation whenever possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01417","_id":"cwe_mitigation/cwe_mitigation_01417","_rev":"_dVfOTU---8","original_id":"627","name":"Dynamic Variable Evaluation","metadata":{"Phase":"Implementation","Description":"Use only allowlists of acceptable variable or function names."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01418","_id":"cwe_mitigation/cwe_mitigation_01418","_rev":"_dVfOTU---9","original_id":"627","name":"Dynamic Variable Evaluation","metadata":{"Phase":"Implementation","Description":"For function names, ensure that you are only calling functions that accept the proper number of arguments, to avoid unexpected null arguments."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01419","_id":"cwe_mitigation/cwe_mitigation_01419","_rev":"_dVfOTU--_-","original_id":"628","name":"Function Call with Incorrectly Specified Arguments","metadata":{"Phase":"Build and Compilation","Description":"Once found, these issues are easy to fix. Use code inspection tools and relevant compiler features to identify potential violations. Pay special attention to code that is not likely to be exercised heavily during QA."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01420","_id":"cwe_mitigation/cwe_mitigation_01420","_rev":"_dVfOTU--__","original_id":"628","name":"Function Call with Incorrectly Specified Arguments","metadata":{"Phase":"Architecture and Design","Description":"Make sure your API's are stable before you use them in production code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01422","_id":"cwe_mitigation/cwe_mitigation_01422","_rev":"_dVfOTU--_A","original_id":"636","name":"Not Failing Securely ('Failing Open')","metadata":{"Phase":"Architecture and Design","Description":"Subdivide and allocate resources and components so that a failure in one part does not affect the entire product."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01423","_id":"cwe_mitigation/cwe_mitigation_01423","_rev":"_dVfOTUC---","original_id":"637","name":"Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism')","metadata":{"Phase":"Architecture and Design","Description":"Avoid complex security mechanisms when simpler ones would meet requirements. Avoid complex data models, and unnecessarily complex operations. Adopt architectures that provide guarantees, simplify understanding through elegance and abstraction, and that can be implemented similarly. Modularize, isolate and do not trust complex code, and apply other secure programming principles on these modules (e.g., least privilege) to mitigate vulnerabilities."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01424","_id":"cwe_mitigation/cwe_mitigation_01424","_rev":"_dVfOTUC--_","original_id":"638","name":"Not Using Complete Mediation","metadata":{"Phase":"Architecture and Design","Description":"Invalidate cached privileges, file handles or descriptors, or other access credentials whenever identities, processes, policies, roles, capabilities or permissions change. Perform complete authentication checks before accepting, caching and reusing data, dynamic content and code (scripts). Avoid caching access control decisions as much as possible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01425","_id":"cwe_mitigation/cwe_mitigation_01425","_rev":"_dVfOTUC--A","original_id":"638","name":"Not Using Complete Mediation","metadata":{"Phase":"Architecture and Design","Description":"Identify all possible code paths that might access sensitive resources. If possible, create and use a single interface that performs the access checks, and develop code standards that require use of this interface."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01426","_id":"cwe_mitigation/cwe_mitigation_01426","_rev":"_dVfOTUC--B","original_id":"639","name":"Authorization Bypass Through User-Controlled Key","metadata":{"Phase":"Architecture and Design","Description":"For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01427","_id":"cwe_mitigation/cwe_mitigation_01427","_rev":"_dVfOTUC--C","original_id":"639","name":"Authorization Bypass Through User-Controlled Key","metadata":{"Phase":"Architecture and Design","Description":"Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01428","_id":"cwe_mitigation/cwe_mitigation_01428","_rev":"_dVfOTUC--D","original_id":"639","name":"Authorization Bypass Through User-Controlled Key","metadata":{"Phase":"Architecture and Design","Description":"Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01429","_id":"cwe_mitigation/cwe_mitigation_01429","_rev":"_dVfOTUC--E","original_id":"640","name":"Weak Password Recovery Mechanism for Forgotten Password","metadata":{"Phase":"Architecture and Design","Description":"Make sure that all input supplied by the user to the password recovery mechanism is thoroughly filtered and validated."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01430","_id":"cwe_mitigation/cwe_mitigation_01430","_rev":"_dVfOTUC--F","original_id":"640","name":"Weak Password Recovery Mechanism for Forgotten Password","metadata":{"Phase":"Architecture and Design","Description":"Do not use standard weak security questions and use several security questions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01431","_id":"cwe_mitigation/cwe_mitigation_01431","_rev":"_dVfOTUC--G","original_id":"640","name":"Weak Password Recovery Mechanism for Forgotten Password","metadata":{"Phase":"Architecture and Design","Description":"Make sure that there is throttling on the number of incorrect answers to a security question. Disable the password recovery functionality after a certain (small) number of incorrect guesses."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01432","_id":"cwe_mitigation/cwe_mitigation_01432","_rev":"_dVfOTUC--H","original_id":"640","name":"Weak Password Recovery Mechanism for Forgotten Password","metadata":{"Phase":"Architecture and Design","Description":"Require that the user properly answers the security question prior to resetting their password and sending the new password to the e-mail address of record."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01433","_id":"cwe_mitigation/cwe_mitigation_01433","_rev":"_dVfOTUC--I","original_id":"640","name":"Weak Password Recovery Mechanism for Forgotten Password","metadata":{"Phase":"Architecture and Design","Description":"Never allow the user to control what e-mail address the new password will be sent to in the password recovery mechanism."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01434","_id":"cwe_mitigation/cwe_mitigation_01434","_rev":"_dVfOTUC--J","original_id":"640","name":"Weak Password Recovery Mechanism for Forgotten Password","metadata":{"Phase":"Architecture and Design","Description":"Assign a new temporary password rather than revealing the original password."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01435","_id":"cwe_mitigation/cwe_mitigation_01435","_rev":"_dVfOTUC--K","original_id":"641","name":"Improper Restriction of Names for Files and Other Resources","metadata":{"Phase":"Architecture and Design","Description":"Do not allow users to control names of resources used on the server side."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01436","_id":"cwe_mitigation/cwe_mitigation_01436","_rev":"_dVfOTUC--L","original_id":"641","name":"Improper Restriction of Names for Files and Other Resources","metadata":{"Phase":"Architecture and Design","Description":"Perform allowlist input validation at entry points and also before consuming the resources. Reject bad file names rather than trying to cleanse them."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01437","_id":"cwe_mitigation/cwe_mitigation_01437","_rev":"_dVfOTUC--M","original_id":"641","name":"Improper Restriction of Names for Files and Other Resources","metadata":{"Phase":"Architecture and Design","Description":"Make sure that technologies consuming the resources are not vulnerable (e.g. buffer overflow, format string, etc.) in a way that would allow code execution if the name of the resource is malformed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01438","_id":"cwe_mitigation/cwe_mitigation_01438","_rev":"_dVfOTUC--N","original_id":"642","name":"External Control of Critical State Data","metadata":{"Phase":"Architecture and Design","Description":"Understand all the potential locations that are accessible to attackers. For example, some programmers assume that cookies and hidden form fields cannot be modified by an attacker, or they may not consider that environment variables can be modified before a privileged program is invoked."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01439","_id":"cwe_mitigation/cwe_mitigation_01439","_rev":"_dVfOTUC--O","original_id":"642","name":"External Control of Critical State Data","metadata":{"Phase":"Architecture and Design","Description":"\n                  Store state information and sensitive data on the server side only.\n                  Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.\n                  If information must be stored on the client, do not do so without encryption and integrity checking, or otherwise having a mechanism on the server side to catch tampering. Use a message authentication code (MAC) algorithm, such as Hash Message Authentication Code (HMAC) [REF-529]. Apply this against the state or sensitive data that you has to be exposed, which can guarantee the integrity of the data - i.e., that the data has not been modified. Ensure that a strong hash function is used (CWE-328).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01440","_id":"cwe_mitigation/cwe_mitigation_01440","_rev":"_dVfOTUC--P","original_id":"642","name":"External Control of Critical State Data","metadata":{"Phase":"Architecture and Design","Description":"Store state information on the server side only. Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01441","_id":"cwe_mitigation/cwe_mitigation_01441","_rev":"_dVfOTUC--Q","original_id":"642","name":"External Control of Critical State Data","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  With a stateless protocol such as HTTP, use some frameworks can maintain the state for you.\n                  Examples include ASP.NET View State and the OWASP ESAPI Session Management feature.\n                  Be careful of language features that provide state support, since these might be provided as a convenience to the programmer and may not be considering security.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01442","_id":"cwe_mitigation/cwe_mitigation_01442","_rev":"_dVfOTUC--R","original_id":"642","name":"External Control of Critical State Data","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01443","_id":"cwe_mitigation/cwe_mitigation_01443","_rev":"_dVfOTUC--S","original_id":"642","name":"External Control of Critical State Data","metadata":{"Phase":"Operation","Description":"When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01444","_id":"cwe_mitigation/cwe_mitigation_01444","_rev":"_dVfOTUC--T","original_id":"642","name":"External Control of Critical State Data","metadata":{"Phase":"Testing","Description":"Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01445","_id":"cwe_mitigation/cwe_mitigation_01445","_rev":"_dVfOTUC--U","original_id":"642","name":"External Control of Critical State Data","metadata":{"Phase":"Testing","Description":"Use dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01446","_id":"cwe_mitigation/cwe_mitigation_01446","_rev":"_dVfOTUC--V","original_id":"642","name":"External Control of Critical State Data","metadata":{"Phase":"Testing","Description":"Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01447","_id":"cwe_mitigation/cwe_mitigation_01447","_rev":"_dVfOTUC--W","original_id":"643","name":"Improper Neutralization of Data within XPath Expressions ('XPath Injection')","metadata":{"Phase":"Implementation","Description":"Use parameterized XPath queries (e.g. using XQuery). This will help ensure separation between data plane and control plane."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01448","_id":"cwe_mitigation/cwe_mitigation_01448","_rev":"_dVfOTUC--X","original_id":"643","name":"Improper Neutralization of Data within XPath Expressions ('XPath Injection')","metadata":{"Phase":"Implementation","Description":"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."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01449","_id":"cwe_mitigation/cwe_mitigation_01449","_rev":"_dVfOTUC--Y","original_id":"644","name":"Improper Neutralization of HTTP Headers for Scripting Syntax","metadata":{"Phase":"Architecture and Design","Description":"Perform output validation in order to filter/escape/encode unsafe data that is being passed from the server in an HTTP response header."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01450","_id":"cwe_mitigation/cwe_mitigation_01450","_rev":"_dVfOTUC--Z","original_id":"644","name":"Improper Neutralization of HTTP Headers for Scripting Syntax","metadata":{"Phase":"Architecture and Design","Description":"Disable script execution functionality in the clients' browser."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01451","_id":"cwe_mitigation/cwe_mitigation_01451","_rev":"_dVfOTUC--a","original_id":"645","name":"Overly Restrictive Account Lockout Mechanism","metadata":{"Phase":"Architecture and Design","Description":"Implement more intelligent password throttling mechanisms such as those which take IP address into account, in addition to the login name."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01452","_id":"cwe_mitigation/cwe_mitigation_01452","_rev":"_dVfOTUC--b","original_id":"645","name":"Overly Restrictive Account Lockout Mechanism","metadata":{"Phase":"Architecture and Design","Description":"Implement a lockout timeout that grows as the number of incorrect login attempts goes up, eventually resulting in a complete lockout."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01453","_id":"cwe_mitigation/cwe_mitigation_01453","_rev":"_dVfOTUC--c","original_id":"645","name":"Overly Restrictive Account Lockout Mechanism","metadata":{"Phase":"Architecture and Design","Description":"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)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01454","_id":"cwe_mitigation/cwe_mitigation_01454","_rev":"_dVfOTUC--d","original_id":"646","name":"Reliance on File Name or Extension of Externally-Supplied File","metadata":{"Phase":"Architecture and Design","Description":"Make decisions on the server side based on file content and not on file name or extension."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01455","_id":"cwe_mitigation/cwe_mitigation_01455","_rev":"_dVfOTUC--e","original_id":"647","name":"Use of Non-Canonical URL Paths for Authorization Decisions","metadata":{"Phase":"Architecture and Design","Description":"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."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01456","_id":"cwe_mitigation/cwe_mitigation_01456","_rev":"_dVfOTUC--f","original_id":"647","name":"Use of Non-Canonical URL Paths for Authorization Decisions","metadata":{"Phase":"Architecture and Design","Description":"Reject all alternate path encodings that are not in the expected canonical form."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01457","_id":"cwe_mitigation/cwe_mitigation_01457","_rev":"_dVfOTUC--g","original_id":"648","name":"Incorrect Use of Privileged APIs","metadata":{"Phase":"Implementation","Description":"Before calling privileged APIs, always ensure that the assumptions made by the privileged code hold true prior to making the call."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01458","_id":"cwe_mitigation/cwe_mitigation_01458","_rev":"_dVfOTUC--h","original_id":"648","name":"Incorrect Use of Privileged APIs","metadata":{"Phase":"Architecture and Design","Description":"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."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01459","_id":"cwe_mitigation/cwe_mitigation_01459","_rev":"_dVfOTUC--i","original_id":"648","name":"Incorrect Use of Privileged APIs","metadata":{"Phase":"Implementation","Description":"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."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01460","_id":"cwe_mitigation/cwe_mitigation_01460","_rev":"_dVfOTUC--j","original_id":"648","name":"Incorrect Use of Privileged APIs","metadata":{"Phase":"Implementation","Description":"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 be returned to the user or made available to user-controlled processes."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01461","_id":"cwe_mitigation/cwe_mitigation_01461","_rev":"_dVfOTUC--k","original_id":"648","name":"Incorrect Use of Privileged APIs","metadata":{"Phase":"Implementation","Description":"Only call privileged APIs from safe, consistent and expected state."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01462","_id":"cwe_mitigation/cwe_mitigation_01462","_rev":"_dVfOTUC--l","original_id":"648","name":"Incorrect Use of Privileged APIs","metadata":{"Phase":"Implementation","Description":"Ensure that a failure or an error will not leave a system in a state where privileges are not properly shed and privilege escalation is possible (i.e. fail securely with regards to handling of privileges)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01463","_id":"cwe_mitigation/cwe_mitigation_01463","_rev":"_dVfOTUC--m","original_id":"649","name":"Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking","metadata":{"Phase":"Architecture and Design","Description":"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."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01464","_id":"cwe_mitigation/cwe_mitigation_01464","_rev":"_dVfOTUC--n","original_id":"649","name":"Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking","metadata":{"Phase":"Architecture and Design","Description":"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."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01465","_id":"cwe_mitigation/cwe_mitigation_01465","_rev":"_dVfOTUC--o","original_id":"649","name":"Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking","metadata":{"Phase":"Architecture and Design","Description":"Client side tokens/parameters should not be such that it would be easy/predictable to guess another valid state."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01466","_id":"cwe_mitigation/cwe_mitigation_01466","_rev":"_dVfOTUC--p","original_id":"649","name":"Reliance on Obfuscation or Encryption of Security-Relevant Inputs without Integrity Checking","metadata":{"Phase":"Architecture and Design","Description":"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 plaintext or reveal its structure, compromising integrity is possible (although less likely) without the provision of the integrity service."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01467","_id":"cwe_mitigation/cwe_mitigation_01467","_rev":"_dVfOTUC--q","original_id":"650","name":"Trusting HTTP Permission Methods on the Server Side","metadata":{"Phase":"System Configuration","Description":"Configure ACLs on the server side to ensure that proper level of access control is defined for each accessible resource representation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01468","_id":"cwe_mitigation/cwe_mitigation_01468","_rev":"_dVfOTUC--r","original_id":"651","name":"Exposure of WSDL File Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"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."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01469","_id":"cwe_mitigation/cwe_mitigation_01469","_rev":"_dVfOTUC--s","original_id":"651","name":"Exposure of WSDL File Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"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."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01470","_id":"cwe_mitigation/cwe_mitigation_01470","_rev":"_dVfOTUC--t","original_id":"651","name":"Exposure of WSDL File Containing Sensitive Information","metadata":{"Phase":"Architecture and Design","Description":"Do not use method names in WSDL that might help an adversary guess names of private methods/resources used by the service."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01471","_id":"cwe_mitigation/cwe_mitigation_01471","_rev":"_dVfOTUC--u","original_id":"652","name":"Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')","metadata":{"Phase":"Implementation","Description":"Use parameterized queries. This will help ensure separation between data plane and control plane."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01472","_id":"cwe_mitigation/cwe_mitigation_01472","_rev":"_dVfOTUC--v","original_id":"652","name":"Improper Neutralization of Data within XQuery Expressions ('XQuery Injection')","metadata":{"Phase":"Implementation","Description":"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."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01473","_id":"cwe_mitigation/cwe_mitigation_01473","_rev":"_dVfOTUC--w","original_id":"653","name":"Improper Isolation or Compartmentalization","metadata":{"Phase":"Architecture and Design","Description":"Break up privileges between different modules, objects, or entities. Minimize the interfaces between modules and require strong access control between them."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01477","_id":"cwe_mitigation/cwe_mitigation_01477","_rev":"_dVfOTUC--x","original_id":"654","name":"Reliance on a Single Factor in a Security Decision","metadata":{"Phase":"Architecture and Design","Description":"Use multiple simultaneous checks before granting access to critical operations or granting critical privileges. A weaker but helpful mitigation is to use several successive checks (multiple layers of security)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01478","_id":"cwe_mitigation/cwe_mitigation_01478","_rev":"_dVfOTUC--y","original_id":"654","name":"Reliance on a Single Factor in a Security Decision","metadata":{"Phase":"Architecture and Design","Description":"Use redundant access rules on different choke points (e.g., firewalls)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01479","_id":"cwe_mitigation/cwe_mitigation_01479","_rev":"_dVfOTUC--z","original_id":"655","name":"Insufficient Psychological Acceptability","metadata":{"Phase":"Testing","Description":"Where possible, perform human factors and usability studies to identify where your product's security mechanisms are difficult to use, and why."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01480","_id":"cwe_mitigation/cwe_mitigation_01480","_rev":"_dVfOTUC--0","original_id":"655","name":"Insufficient Psychological Acceptability","metadata":{"Phase":"Architecture and Design","Description":"Make the security mechanism as seamless as possible, while also providing the user with sufficient details when a security decision produces unexpected results."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01481","_id":"cwe_mitigation/cwe_mitigation_01481","_rev":"_dVfOTUC--1","original_id":"656","name":"Reliance on Security Through Obscurity","metadata":{"Phase":"Architecture and Design","Description":"Always consider whether knowledge of your code or design is sufficient to break it. Reverse engineering is a highly successful discipline, and financially feasible for motivated adversaries. Black-box techniques are established for binary analysis of executables that use obfuscation, runtime analysis of proprietary protocols, inferring file formats, and others."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01482","_id":"cwe_mitigation/cwe_mitigation_01482","_rev":"_dVfOTUC--2","original_id":"656","name":"Reliance on Security Through Obscurity","metadata":{"Phase":"Architecture and Design","Description":"When available, use publicly-vetted algorithms and procedures, as these are more likely to undergo more extensive security analysis and testing. This is especially the case with encryption and authentication."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01483","_id":"cwe_mitigation/cwe_mitigation_01483","_rev":"_dVfOTUC--3","original_id":"662","name":"Improper Synchronization","metadata":{"Phase":"Implementation","Description":"Use industry standard APIs to synchronize your code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01484","_id":"cwe_mitigation/cwe_mitigation_01484","_rev":"_dVfOTUC--4","original_id":"663","name":"Use of a Non-reentrant Function in a Concurrent Context","metadata":{"Phase":"Implementation","Description":"Use reentrant functions if available."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01485","_id":"cwe_mitigation/cwe_mitigation_01485","_rev":"_dVfOTUC--5","original_id":"663","name":"Use of a Non-reentrant Function in a Concurrent Context","metadata":{"Phase":"Implementation","Description":"Add synchronization to your non-reentrant function."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01486","_id":"cwe_mitigation/cwe_mitigation_01486","_rev":"_dVfOTUC--6","original_id":"663","name":"Use of a Non-reentrant Function in a Concurrent Context","metadata":{"Phase":"Implementation","Description":"In Java, use the ReentrantLock Class."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01487","_id":"cwe_mitigation/cwe_mitigation_01487","_rev":"_dVfOTUC--7","original_id":"664","name":"Improper Control of a Resource Through its Lifetime","metadata":{"Phase":"Testing","Description":"Use Static analysis tools to check for unreleased resources."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01488","_id":"cwe_mitigation/cwe_mitigation_01488","_rev":"_dVfOTUG---","original_id":"665","name":"Improper Initialization","metadata":{"Phase":"Requirements","Description":"\n                  Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, in Java, if the programmer does not explicitly initialize a variable, then the code could produce a compile-time error (if the variable is local) or automatically initialize the variable to the default value for the variable's type. In Perl, if explicit initialization is not performed, then a default value of undef is assigned, which is interpreted as 0, false, or an equivalent value depending on the context in which the variable is accessed.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01489","_id":"cwe_mitigation/cwe_mitigation_01489","_rev":"_dVfOTUG--_","original_id":"665","name":"Improper Initialization","metadata":{"Phase":"Architecture and Design","Description":"Identify all variables and data stores that receive information from external sources, and apply input validation to make sure that they are only initialized to expected values."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01490","_id":"cwe_mitigation/cwe_mitigation_01490","_rev":"_dVfOTUG--A","original_id":"665","name":"Improper Initialization","metadata":{"Phase":"Implementation","Description":"Explicitly initialize all your variables and other data stores, either during declaration or just before the first usage."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01491","_id":"cwe_mitigation/cwe_mitigation_01491","_rev":"_dVfOTUG--B","original_id":"665","name":"Improper Initialization","metadata":{"Phase":"Implementation","Description":"Pay close attention to complex conditionals that affect initialization, since some conditions might not perform the initialization."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01492","_id":"cwe_mitigation/cwe_mitigation_01492","_rev":"_dVfOTUG--C","original_id":"665","name":"Improper Initialization","metadata":{"Phase":"Implementation","Description":"Avoid race conditions (CWE-362) during initialization routines."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01493","_id":"cwe_mitigation/cwe_mitigation_01493","_rev":"_dVfOTUG--D","original_id":"665","name":"Improper Initialization","metadata":{"Phase":"Build and Compilation","Description":"Run or compile your software with settings that generate warnings about uninitialized variables or data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01494","_id":"cwe_mitigation/cwe_mitigation_01494","_rev":"_dVfOTUG--E","original_id":"665","name":"Improper Initialization","metadata":{"Phase":"Testing","Description":"Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01497","_id":"cwe_mitigation/cwe_mitigation_01497","_rev":"_dVfOTUG--F","original_id":"666","name":"Operation on Resource in Wrong Phase of Lifetime","metadata":{"Phase":"Architecture and Design","Description":"Follow the resource's lifecycle from creation to release."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01498","_id":"cwe_mitigation/cwe_mitigation_01498","_rev":"_dVfOTUG--G","original_id":"667","name":"Improper Locking","metadata":{"Phase":"Implementation","Description":"Use industry standard APIs to implement locking mechanism."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01499","_id":"cwe_mitigation/cwe_mitigation_01499","_rev":"_dVfOTUG--H","original_id":"674","name":"Uncontrolled Recursion","metadata":{"Phase":"Implementation","Description":"Ensure an end condition will be reached under all logic conditions.  The end condition may include testing against the depth of recursion and exiting with an error if the recursion goes too deep. The complexity of the end condition contributes to the effectiveness of this action."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01500","_id":"cwe_mitigation/cwe_mitigation_01500","_rev":"_dVfOTUG--I","original_id":"674","name":"Uncontrolled Recursion","metadata":{"Phase":"Implementation","Description":"Increase the stack size."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01501","_id":"cwe_mitigation/cwe_mitigation_01501","_rev":"_dVfOTUG--J","original_id":"676","name":"Use of Potentially Dangerous Function","metadata":{"Phase":"Build and Compilation","Description":"Identify a list of prohibited API functions and prohibit developers from using these functions, providing safer alternatives. In some cases, automatic code analysis tools or the compiler can be instructed to spot use of prohibited functions, such as the \"banned.h\" include file from Microsoft's SDL. [REF-554] [REF-7]"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01509","_id":"cwe_mitigation/cwe_mitigation_01509","_rev":"_dVfOTUG--K","original_id":"681","name":"Incorrect Conversion between Numeric Types","metadata":{"Phase":"Implementation","Description":"Avoid making conversion between numeric types. Always check for the allowed ranges."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01510","_id":"cwe_mitigation/cwe_mitigation_01510","_rev":"_dVfOTUG--L","original_id":"682","name":"Incorrect Calculation","metadata":{"Phase":"Implementation","Description":"Understand your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, \"not-a-number\" calculations, and how your language handles numbers that are too large or too small for its underlying representation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01511","_id":"cwe_mitigation/cwe_mitigation_01511","_rev":"_dVfOTUG--M","original_id":"682","name":"Incorrect Calculation","metadata":{"Phase":"Implementation","Description":"Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01512","_id":"cwe_mitigation/cwe_mitigation_01512","_rev":"_dVfOTUG--N","original_id":"682","name":"Incorrect Calculation","metadata":{"Phase":"Implementation","Description":"Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01513","_id":"cwe_mitigation/cwe_mitigation_01513","_rev":"_dVfOTUG--O","original_id":"682","name":"Incorrect Calculation","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.\n                  Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01514","_id":"cwe_mitigation/cwe_mitigation_01514","_rev":"_dVfOTUG--P","original_id":"682","name":"Incorrect Calculation","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.\n                  Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01515","_id":"cwe_mitigation/cwe_mitigation_01515","_rev":"_dVfOTUG--Q","original_id":"682","name":"Incorrect Calculation","metadata":{"Phase":"Implementation","Description":"Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01516","_id":"cwe_mitigation/cwe_mitigation_01516","_rev":"_dVfOTUG--R","original_id":"682","name":"Incorrect Calculation","metadata":{"Phase":"Testing","Description":"Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01517","_id":"cwe_mitigation/cwe_mitigation_01517","_rev":"_dVfOTUG--S","original_id":"682","name":"Incorrect Calculation","metadata":{"Phase":"Testing","Description":"Use dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01519","_id":"cwe_mitigation/cwe_mitigation_01519","_rev":"_dVfOTUG--T","original_id":"683","name":"Function Call With Incorrect Order of Arguments","metadata":{"Phase":"Implementation","Description":"Use the function, procedure, or routine as specified."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01520","_id":"cwe_mitigation/cwe_mitigation_01520","_rev":"_dVfOTUG--U","original_id":"683","name":"Function Call With Incorrect Order of Arguments","metadata":{"Phase":"Testing","Description":"Because this function call often produces incorrect behavior it will usually be detected during testing or normal operation of the software. During testing exercise all possible control paths will typically expose this weakness except in rare cases when the incorrect function call accidentally produces the correct results or if the provided argument type is very similar to the expected argument type."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01521","_id":"cwe_mitigation/cwe_mitigation_01521","_rev":"_dVfOTUG--V","original_id":"684","name":"Incorrect Provision of Specified Functionality","metadata":{"Phase":"Implementation","Description":"Ensure that your code strictly conforms to specifications."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01522","_id":"cwe_mitigation/cwe_mitigation_01522","_rev":"_dVfOTUG--W","original_id":"685","name":"Function Call With Incorrect Number of Arguments","metadata":{"Phase":"Testing","Description":"Because this function call often produces incorrect behavior it will usually be detected during testing or normal operation of the software. During testing exercise all possible control paths will typically expose this weakness except in rare cases when the incorrect function call accidentally produces the correct results or if the provided argument type is very similar to the expected argument type."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01524","_id":"cwe_mitigation/cwe_mitigation_01524","_rev":"_dVfOTUG--X","original_id":"686","name":"Function Call With Incorrect Argument Type","metadata":{"Phase":"Testing","Description":"Because this function call often produces incorrect behavior it will usually be detected during testing or normal operation of the software. During testing exercise all possible control paths will typically expose this weakness except in rare cases when the incorrect function call accidentally produces the correct results or if the provided argument type is very similar to the expected argument type."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01526","_id":"cwe_mitigation/cwe_mitigation_01526","_rev":"_dVfOTUG--Y","original_id":"688","name":"Function Call With Incorrect Variable or Reference as Argument","metadata":{"Phase":"Testing","Description":"Because this function call often produces incorrect behavior it will usually be detected during testing or normal operation of the software. During testing exercise all possible control paths will typically expose this weakness except in rare cases when the incorrect function call accidentally produces the correct results or if the provided argument type is very similar to the expected argument type."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01530","_id":"cwe_mitigation/cwe_mitigation_01530","_rev":"_dVfOTUG--Z","original_id":"694","name":"Use of Multiple Resources with Duplicate Identifier","metadata":{"Phase":"Architecture and Design","Description":"Where possible, use unique identifiers. If non-unique identifiers are detected, then do not operate any resource with a non-unique identifier and report the error appropriately."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01536","_id":"cwe_mitigation/cwe_mitigation_01536","_rev":"_dVfOTUG--a","original_id":"708","name":"Incorrect Ownership Assignment","metadata":{"Phase":"Policy","Description":"Periodically review the privileges and their owners."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01537","_id":"cwe_mitigation/cwe_mitigation_01537","_rev":"_dVfOTUG--b","original_id":"708","name":"Incorrect Ownership Assignment","metadata":{"Phase":"Testing","Description":"Use automated tools to check for privilege settings."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01538","_id":"cwe_mitigation/cwe_mitigation_01538","_rev":"_dVfOTUG--c","original_id":"710","name":"Improper Adherence to Coding Standards","metadata":{"Phase":"Implementation","Description":"Document and closely follow coding standards."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01539","_id":"cwe_mitigation/cwe_mitigation_01539","_rev":"_dVfOTUG--d","original_id":"710","name":"Improper Adherence to Coding Standards","metadata":{"Phase":"Testing","Description":"Where possible, use automated tools to enforce the standards."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01540","_id":"cwe_mitigation/cwe_mitigation_01540","_rev":"_dVfOTUG--e","original_id":"732","name":"Incorrect Permission Assignment for Critical Resource","metadata":{"Phase":"Implementation","Description":"When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user) [REF-62], and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unauthorized party."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01541","_id":"cwe_mitigation/cwe_mitigation_01541","_rev":"_dVfOTUG--f","original_id":"732","name":"Incorrect Permission Assignment for Critical Resource","metadata":{"Phase":"Architecture and Design","Description":"Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly. This will allow you to maintain more fine-grained control over your resources. [REF-207]"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01542","_id":"cwe_mitigation/cwe_mitigation_01542","_rev":"_dVfOTUG--g","original_id":"732","name":"Incorrect Permission Assignment for Critical Resource","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run the code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.\n                  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01543","_id":"cwe_mitigation/cwe_mitigation_01543","_rev":"_dVfOTUG--h","original_id":"732","name":"Incorrect Permission Assignment for Critical Resource","metadata":{"Phase":"Implementation","Description":"During program startup, explicitly set the default permissions or umask to the most restrictive setting possible. Also set the appropriate permissions during program installation. This will prevent you from inheriting insecure permissions from any user who installs or runs the program."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01544","_id":"cwe_mitigation/cwe_mitigation_01544","_rev":"_dVfOTUG--i","original_id":"732","name":"Incorrect Permission Assignment for Critical Resource","metadata":{"Phase":"System Configuration","Description":"For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01545","_id":"cwe_mitigation/cwe_mitigation_01545","_rev":"_dVfOTUG--j","original_id":"732","name":"Incorrect Permission Assignment for Critical Resource","metadata":{"Phase":"Documentation","Description":"Do not suggest insecure configuration changes in documentation, especially if those configurations can extend to resources and other programs that are outside the scope of the application."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01546","_id":"cwe_mitigation/cwe_mitigation_01546","_rev":"_dVfOTUG--k","original_id":"732","name":"Incorrect Permission Assignment for Critical Resource","metadata":{"Phase":"Installation","Description":"Do not assume that a system administrator will manually change the configuration to the settings that are recommended in the software's manual."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01547","_id":"cwe_mitigation/cwe_mitigation_01547","_rev":"_dVfOTUG--l","original_id":"732","name":"Incorrect Permission Assignment for Critical Resource","metadata":{"Phase":"Operation","Description":"Ensure that the software runs properly under the Federal Desktop Core Configuration (FDCC) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01565","_id":"cwe_mitigation/cwe_mitigation_01565","_rev":"_dVfOTUG--m","original_id":"749","name":"Exposed Dangerous Method or Function","metadata":{"Phase":"Architecture and Design","Description":"If you must expose a method, make sure to perform input validation on all arguments, limit access to authorized parties, and protect against all possible vulnerabilities."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01566","_id":"cwe_mitigation/cwe_mitigation_01566","_rev":"_dVfOTUG--n","original_id":"749","name":"Exposed Dangerous Method or Function","metadata":{"Phase":"Architecture and Design","Description":"\n                  Identify all exposed functionality. Explicitly list all functionality that must be exposed to some user or set of users. Identify which functionality may be:\n                  \n                     \n                        accessible to all users\n                        restricted to a small set of privileged users\n                        prevented from being directly accessible at all\n                     \n                  \n                  Ensure that the implemented code follows these expectations. This includes setting the appropriate access modifiers where applicable (public, private, protected, etc.) or not marking ActiveX controls safe-for-scripting.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01567","_id":"cwe_mitigation/cwe_mitigation_01567","_rev":"_dVfOTUG--o","original_id":"754","name":"Improper Check for Unusual or Exceptional Conditions","metadata":{"Phase":"Requirements","Description":"\n                  Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01568","_id":"cwe_mitigation/cwe_mitigation_01568","_rev":"_dVfOTUG--p","original_id":"754","name":"Improper Check for Unusual or Exceptional Conditions","metadata":{"Phase":"Implementation","Description":"Check the results of all functions that return a value and verify that the value is expected."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01569","_id":"cwe_mitigation/cwe_mitigation_01569","_rev":"_dVfOTUG--q","original_id":"754","name":"Improper Check for Unusual or Exceptional Conditions","metadata":{"Phase":"Implementation","Description":"If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01570","_id":"cwe_mitigation/cwe_mitigation_01570","_rev":"_dVfOTUG--r","original_id":"754","name":"Improper Check for Unusual or Exceptional Conditions","metadata":{"Phase":"Implementation","Description":"\n                  Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.\n                  If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.\n\t\t  Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.\n\t\t  Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.\n\t       "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01571","_id":"cwe_mitigation/cwe_mitigation_01571","_rev":"_dVfOTUG--s","original_id":"754","name":"Improper Check for Unusual or Exceptional Conditions","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01572","_id":"cwe_mitigation/cwe_mitigation_01572","_rev":"_dVfOTUG--t","original_id":"754","name":"Improper Check for Unusual or Exceptional Conditions","metadata":{"Phase":"Architecture and Design","Description":"If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01573","_id":"cwe_mitigation/cwe_mitigation_01573","_rev":"_dVfOTUG--u","original_id":"754","name":"Improper Check for Unusual or Exceptional Conditions","metadata":{"Phase":"Architecture and Design","Description":"Use system limits, which should help to prevent resource exhaustion. However, the software should still handle low resource conditions since they may still occur."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01576","_id":"cwe_mitigation/cwe_mitigation_01576","_rev":"_dVfOTUG--v","original_id":"759","name":"Use of a One-Way Hash without a Salt","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations (\"stretching\") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use.\n                  Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead.\n                  Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01577","_id":"cwe_mitigation/cwe_mitigation_01577","_rev":"_dVfOTUG--w","original_id":"759","name":"Use of a One-Way Hash without a Salt","metadata":{"Phase":"Architecture and Design","Description":"If a technique that requires extra computational effort can not be implemented, then for each password that is processed, generate a new random salt using a strong random number generator with unpredictable seeds. Add the salt to the plaintext password before hashing it. When storing the hash, also store the salt. Do not use the same salt for every password."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01578","_id":"cwe_mitigation/cwe_mitigation_01578","_rev":"_dVfOTUG--x","original_id":"759","name":"Use of a One-Way Hash without a Salt","metadata":{"Phase":"Implementation","Description":"When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01585","_id":"cwe_mitigation/cwe_mitigation_01585","_rev":"_dVfOTUG--y","original_id":"760","name":"Use of a One-Way Hash with a Predictable Salt","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations (\"stretching\") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use.\n                  Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead.\n                  Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01586","_id":"cwe_mitigation/cwe_mitigation_01586","_rev":"_dVfOTUG--z","original_id":"760","name":"Use of a One-Way Hash with a Predictable Salt","metadata":{"Phase":"Implementation","Description":"If a technique that requires extra computational effort can not be implemented, then for each password that is processed, generate a new random salt using a strong random number generator with unpredictable seeds. Add the salt to the plaintext password before hashing it. When storing the hash, also store the salt. Do not use the same salt for every password."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01587","_id":"cwe_mitigation/cwe_mitigation_01587","_rev":"_dVfOTUG--0","original_id":"761","name":"Free of Pointer not at Start of Buffer","metadata":{"Phase":"Implementation","Description":"When utilizing pointer arithmetic to traverse a buffer, use a separate variable to track progress through memory and preserve the originally allocated address for later freeing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01588","_id":"cwe_mitigation/cwe_mitigation_01588","_rev":"_dVfOTUG--1","original_id":"761","name":"Free of Pointer not at Start of Buffer","metadata":{"Phase":"Implementation","Description":"When programming in C++, consider using smart pointers provided by the boost library to help correctly and consistently manage memory."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01589","_id":"cwe_mitigation/cwe_mitigation_01589","_rev":"_dVfOTUG--2","original_id":"761","name":"Free of Pointer not at Start of Buffer","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, glibc in Linux provides protection against free of invalid pointers.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01590","_id":"cwe_mitigation/cwe_mitigation_01590","_rev":"_dVfOTUK---","original_id":"761","name":"Free of Pointer not at Start of Buffer","metadata":{"Phase":"Architecture and Design","Description":"Use a language that provides abstractions for memory allocation and deallocation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01591","_id":"cwe_mitigation/cwe_mitigation_01591","_rev":"_dVfOTUK--_","original_id":"761","name":"Free of Pointer not at Start of Buffer","metadata":{"Phase":"Testing","Description":"Use a tool that dynamically detects memory management problems, such as valgrind."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01592","_id":"cwe_mitigation/cwe_mitigation_01592","_rev":"_dVfOTUK--A","original_id":"762","name":"Mismatched Memory Management Routines","metadata":{"Phase":"Implementation","Description":"Only call matching memory management functions. Do not mix and match routines. For example, when you allocate a buffer with malloc(), dispose of the original pointer with free()."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01593","_id":"cwe_mitigation/cwe_mitigation_01593","_rev":"_dVfOTUK--B","original_id":"762","name":"Mismatched Memory Management Routines","metadata":{"Phase":"Implementation","Description":"\n                  Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.\n                  For example, glibc in Linux provides protection against free of invalid pointers.\n                  When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].\n                  To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01594","_id":"cwe_mitigation/cwe_mitigation_01594","_rev":"_dVfOTUK--C","original_id":"762","name":"Mismatched Memory Management Routines","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, glibc in Linux provides protection against free of invalid pointers.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01595","_id":"cwe_mitigation/cwe_mitigation_01595","_rev":"_dVfOTUK--D","original_id":"762","name":"Mismatched Memory Management Routines","metadata":{"Phase":"Architecture and Design","Description":"Use a language that provides abstractions for memory allocation and deallocation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01596","_id":"cwe_mitigation/cwe_mitigation_01596","_rev":"_dVfOTUK--E","original_id":"762","name":"Mismatched Memory Management Routines","metadata":{"Phase":"Testing","Description":"Use a tool that dynamically detects memory management problems, such as valgrind."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01597","_id":"cwe_mitigation/cwe_mitigation_01597","_rev":"_dVfOTUK--F","original_id":"763","name":"Release of Invalid Pointer or Reference","metadata":{"Phase":"Implementation","Description":"Only call matching memory management functions. Do not mix and match routines. For example, when you allocate a buffer with malloc(), dispose of the original pointer with free()."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01598","_id":"cwe_mitigation/cwe_mitigation_01598","_rev":"_dVfOTUK--G","original_id":"763","name":"Release of Invalid Pointer or Reference","metadata":{"Phase":"Implementation","Description":"When programming in C++, consider using smart pointers provided by the boost library to help correctly and consistently manage memory."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01599","_id":"cwe_mitigation/cwe_mitigation_01599","_rev":"_dVfOTUK--H","original_id":"763","name":"Release of Invalid Pointer or Reference","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, glibc in Linux provides protection against free of invalid pointers.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01600","_id":"cwe_mitigation/cwe_mitigation_01600","_rev":"_dVfOTUK--I","original_id":"763","name":"Release of Invalid Pointer or Reference","metadata":{"Phase":"Architecture and Design","Description":"Use a language that provides abstractions for memory allocation and deallocation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01601","_id":"cwe_mitigation/cwe_mitigation_01601","_rev":"_dVfOTUK--J","original_id":"763","name":"Release of Invalid Pointer or Reference","metadata":{"Phase":"Testing","Description":"Use a tool that dynamically detects memory management problems, such as valgrind."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01602","_id":"cwe_mitigation/cwe_mitigation_01602","_rev":"_dVfOTUK--K","original_id":"764","name":"Multiple Locks of a Critical Resource","metadata":{"Phase":"Implementation","Description":"When locking and unlocking a resource, try to be sure that all control paths through the code in which the resource is locked one or more times correspond to exactly as many unlocks. If the software acquires a lock and then determines it is not able to perform its intended behavior, be sure to release the lock(s) before waiting for conditions to improve. Reacquire the lock(s) before trying again."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01603","_id":"cwe_mitigation/cwe_mitigation_01603","_rev":"_dVfOTUK--L","original_id":"765","name":"Multiple Unlocks of a Critical Resource","metadata":{"Phase":"Implementation","Description":"When locking and unlocking a resource, try to be sure that all control paths through the code in which the resource is locked one or more times correspond to exactly as many unlocks. If the software acquires a lock and then determines it is not able to perform its intended behavior, be sure to release the lock(s) before waiting for conditions to improve. Reacquire the lock(s) before trying again."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01604","_id":"cwe_mitigation/cwe_mitigation_01604","_rev":"_dVfOTUK--M","original_id":"766","name":"Critical Data Element Declared Public","metadata":{"Phase":"Implementation","Description":"Data should be private, static, and final whenever possible. This will assure that your code is protected by instantiating early, preventing access, and preventing tampering."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01605","_id":"cwe_mitigation/cwe_mitigation_01605","_rev":"_dVfOTUK--N","original_id":"767","name":"Access to Critical Private Variable via Public Method","metadata":{"Phase":"Implementation","Description":"Use class accessor and mutator methods appropriately. Perform validation when accepting data from a public method that is intended to modify a critical private variable. Also be sure that appropriate access controls are being applied when a public method interfaces with critical data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01606","_id":"cwe_mitigation/cwe_mitigation_01606","_rev":"_dVfOTUK--O","original_id":"768","name":"Incorrect Short Circuit Evaluation","metadata":{"Phase":"Implementation","Description":"Minimizing the number of statements in a conditional that produce side effects will help to prevent the likelihood of short circuit evaluation to alter control flow in an unexpected way."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01607","_id":"cwe_mitigation/cwe_mitigation_01607","_rev":"_dVfOTUK--P","original_id":"770","name":"Allocation of Resources Without Limits or Throttling","metadata":{"Phase":"Requirements","Description":"Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01608","_id":"cwe_mitigation/cwe_mitigation_01608","_rev":"_dVfOTUK--Q","original_id":"770","name":"Allocation of Resources Without Limits or Throttling","metadata":{"Phase":"Architecture and Design","Description":"Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01609","_id":"cwe_mitigation/cwe_mitigation_01609","_rev":"_dVfOTUK--R","original_id":"770","name":"Allocation of Resources Without Limits or Throttling","metadata":{"Phase":"Architecture and Design","Description":"Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place, and it will help the administrator to identify who is committing the abuse. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01610","_id":"cwe_mitigation/cwe_mitigation_01610","_rev":"_dVfOTUK--S","original_id":"770","name":"Allocation of Resources Without Limits or Throttling","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01611","_id":"cwe_mitigation/cwe_mitigation_01611","_rev":"_dVfOTUK--T","original_id":"770","name":"Allocation of Resources Without Limits or Throttling","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01612","_id":"cwe_mitigation/cwe_mitigation_01612","_rev":"_dVfOTUK--U","original_id":"770","name":"Allocation of Resources Without Limits or Throttling","metadata":{"Phase":"Architecture and Design","Description":"\n                  Mitigation of resource exhaustion attacks requires that the target system either:\n                  \n                     \n                        recognizes the attack and denies that user further access for a given amount of time, typically by using increasing time delays\n                        uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.\n                     \n                  \n                  The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.\n                  The second solution can be difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply requires more resources on the part of the attacker.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01613","_id":"cwe_mitigation/cwe_mitigation_01613","_rev":"_dVfOTUK--V","original_id":"770","name":"Allocation of Resources Without Limits or Throttling","metadata":{"Phase":"Architecture and Design","Description":"Ensure that protocols have specific limits of scale placed on them."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01614","_id":"cwe_mitigation/cwe_mitigation_01614","_rev":"_dVfOTUK--W","original_id":"770","name":"Allocation of Resources Without Limits or Throttling","metadata":{"Phase":"Architecture and Design","Description":"\n                  If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.\n                  Ensure that all failures in resource allocation place the system into a safe posture.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01615","_id":"cwe_mitigation/cwe_mitigation_01615","_rev":"_dVfOTUK--X","original_id":"770","name":"Allocation of Resources Without Limits or Throttling","metadata":{"Phase":"Operation","Description":"\n                  Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.\n                  When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.\n                  Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01620","_id":"cwe_mitigation/cwe_mitigation_01620","_rev":"_dVfOTUK--Y","original_id":"771","name":"Missing Reference to Active Allocated Resource","metadata":{"Phase":"Operation","Description":"\n                  Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.\n                  When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.\n                  Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01621","_id":"cwe_mitigation/cwe_mitigation_01621","_rev":"_dVfOTUK--Z","original_id":"772","name":"Missing Release of Resource after Effective Lifetime","metadata":{"Phase":"Requirements","Description":"\n                  Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01622","_id":"cwe_mitigation/cwe_mitigation_01622","_rev":"_dVfOTUK--a","original_id":"772","name":"Missing Release of Resource after Effective Lifetime","metadata":{"Phase":"Implementation","Description":"It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01623","_id":"cwe_mitigation/cwe_mitigation_01623","_rev":"_dVfOTUK--b","original_id":"772","name":"Missing Release of Resource after Effective Lifetime","metadata":{"Phase":"Operation","Description":"\n                  Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.\n                  When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.\n                  Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01624","_id":"cwe_mitigation/cwe_mitigation_01624","_rev":"_dVfOTUK--c","original_id":"773","name":"Missing Reference to Active File Descriptor or Handle","metadata":{"Phase":"Operation","Description":"\n                  Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.\n                  When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.\n                  Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01625","_id":"cwe_mitigation/cwe_mitigation_01625","_rev":"_dVfOTUK--d","original_id":"774","name":"Allocation of File Descriptors or Handles Without Limits or Throttling","metadata":{"Phase":"Operation","Description":"\n                  Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.\n                  When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.\n                  Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01626","_id":"cwe_mitigation/cwe_mitigation_01626","_rev":"_dVfOTUK--e","original_id":"775","name":"Missing Release of File Descriptor or Handle after Effective Lifetime","metadata":{"Phase":"Operation","Description":"\n                  Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.\n                  When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.\n                  Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01627","_id":"cwe_mitigation/cwe_mitigation_01627","_rev":"_dVfOTUK--f","original_id":"776","name":"Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')","metadata":{"Phase":"Operation","Description":"If possible, prohibit the use of DTDs or use an XML parser that limits the expansion of recursive DTD entities."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01628","_id":"cwe_mitigation/cwe_mitigation_01628","_rev":"_dVfOTUK--g","original_id":"776","name":"Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')","metadata":{"Phase":"Implementation","Description":"Before parsing XML files with associated DTDs, scan for recursive entity declarations and do not continue parsing potentially explosive content."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01629","_id":"cwe_mitigation/cwe_mitigation_01629","_rev":"_dVfOTUK--h","original_id":"777","name":"Regular Expression without Anchors","metadata":{"Phase":"Implementation","Description":"Be sure to understand both what will be matched and what will not be matched by a regular expression. Anchoring the ends of the expression will allow the programmer to define an allowlist strictly limited to what is matched by the text in the regular expression. If you are using a package that only matches one line by default, ensure that you can match multi-line inputs if necessary."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01630","_id":"cwe_mitigation/cwe_mitigation_01630","_rev":"_dVfOTUK--i","original_id":"778","name":"Insufficient Logging","metadata":{"Phase":"Architecture and Design","Description":"Use a centralized logging mechanism that supports multiple levels of detail. Ensure that all security-related successes and failures can be logged."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01631","_id":"cwe_mitigation/cwe_mitigation_01631","_rev":"_dVfOTUK--j","original_id":"778","name":"Insufficient Logging","metadata":{"Phase":"Operation","Description":"Be sure to set the level of logging appropriately in a production environment. Sufficient data should be logged to enable system administrators to detect attacks, diagnose errors, and recover from attacks. At the same time, logging too much data (CWE-779) can cause the same problems."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01632","_id":"cwe_mitigation/cwe_mitigation_01632","_rev":"_dVfOTUK--k","original_id":"779","name":"Logging of Excessive Data","metadata":{"Phase":"Architecture and Design","Description":"Suppress large numbers of duplicate log messages and replace them with periodic summaries. For example, syslog may include an entry that states \"last message repeated X times\" when recording repeated events."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01633","_id":"cwe_mitigation/cwe_mitigation_01633","_rev":"_dVfOTUK--l","original_id":"779","name":"Logging of Excessive Data","metadata":{"Phase":"Architecture and Design","Description":"Support a maximum size for the log file that can be controlled by the administrator. If the maximum size is reached, the admin should be notified. Also, consider reducing functionality of the software. This may result in a denial-of-service to legitimate software users, but it will prevent the software from adversely impacting the entire system."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01634","_id":"cwe_mitigation/cwe_mitigation_01634","_rev":"_dVfOTUK--m","original_id":"779","name":"Logging of Excessive Data","metadata":{"Phase":"Implementation","Description":"Adjust configurations appropriately when software is transitioned from a debug state to production."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01635","_id":"cwe_mitigation/cwe_mitigation_01635","_rev":"_dVfOTUK--n","original_id":"781","name":"Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code","metadata":{"Phase":"Implementation","Description":"If METHOD_NEITHER is required for the IOCTL, then ensure that all user-space addresses are properly validated before they are first accessed. The ProbeForRead and ProbeForWrite routines are available for this task. Also properly protect and manage the user-supplied buffers, since the I/O Manager does not do this when METHOD_NEITHER is being used. See References."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01636","_id":"cwe_mitigation/cwe_mitigation_01636","_rev":"_dVfOTUK--o","original_id":"781","name":"Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code","metadata":{"Phase":"Architecture and Design","Description":"If possible, avoid using METHOD_NEITHER in the IOCTL and select methods that effectively control the buffer size, such as METHOD_BUFFERED, METHOD_IN_DIRECT, or METHOD_OUT_DIRECT."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01637","_id":"cwe_mitigation/cwe_mitigation_01637","_rev":"_dVfOTUK--p","original_id":"781","name":"Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code","metadata":{"Phase":"Architecture and Design","Description":"If the IOCTL is part of a driver that is only intended to be accessed by trusted users, then use proper access control for the associated device or device namespace. See References."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01638","_id":"cwe_mitigation/cwe_mitigation_01638","_rev":"_dVfOTUK--q","original_id":"782","name":"Exposed IOCTL with Insufficient Access Control","metadata":{"Phase":"Architecture and Design","Description":"In Windows environments, use proper access control for the associated device or device namespace. See References."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01639","_id":"cwe_mitigation/cwe_mitigation_01639","_rev":"_dVfOTUK--r","original_id":"783","name":"Operator Precedence Logic Error","metadata":{"Phase":"Implementation","Description":"Regularly wrap sub-expressions in parentheses, especially in security-critical code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01640","_id":"cwe_mitigation/cwe_mitigation_01640","_rev":"_dVfOTUK--s","original_id":"784","name":"Reliance on Cookies without Validation and Integrity Checking in a Security Decision","metadata":{"Phase":"Architecture and Design","Description":"Avoid using cookie data for a security-related decision."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01641","_id":"cwe_mitigation/cwe_mitigation_01641","_rev":"_dVfOTUK--t","original_id":"784","name":"Reliance on Cookies without Validation and Integrity Checking in a Security Decision","metadata":{"Phase":"Implementation","Description":"Perform thorough input validation (i.e.: server side validation) on the cookie data if you're going to use it for a security related decision."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01642","_id":"cwe_mitigation/cwe_mitigation_01642","_rev":"_dVfOTUK--u","original_id":"784","name":"Reliance on Cookies without Validation and Integrity Checking in a Security Decision","metadata":{"Phase":"Architecture and Design","Description":"Add integrity checks to detect tampering."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01643","_id":"cwe_mitigation/cwe_mitigation_01643","_rev":"_dVfOTUK--v","original_id":"784","name":"Reliance on Cookies without Validation and Integrity Checking in a Security Decision","metadata":{"Phase":"Architecture and Design","Description":"Protect critical cookies from replay attacks, since cross-site scripting or other attacks may allow attackers to steal a strongly-encrypted cookie that also passes integrity checks. This mitigation applies to cookies that should only be valid during a single transaction or session. By enforcing timeouts, you may limit the scope of an attack. As part of your integrity check, use an unpredictable, server-side value that is not exposed to the client."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01644","_id":"cwe_mitigation/cwe_mitigation_01644","_rev":"_dVfOTUK--w","original_id":"785","name":"Use of Path Manipulation Function without Maximum-sized Buffer","metadata":{"Phase":"Implementation","Description":"Always specify output buffers large enough to handle the maximum-size possible result from path manipulation functions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01645","_id":"cwe_mitigation/cwe_mitigation_01645","_rev":"_dVfOTUK--x","original_id":"787","name":"Out-of-bounds Write","metadata":{"Phase":"Requirements","Description":"\n                  Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.\n                  Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01646","_id":"cwe_mitigation/cwe_mitigation_01646","_rev":"_dVfOTUK--y","original_id":"787","name":"Out-of-bounds Write","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01647","_id":"cwe_mitigation/cwe_mitigation_01647","_rev":"_dVfOTUK--z","original_id":"787","name":"Out-of-bounds Write","metadata":{"Phase":"Build and Compilation","Description":"\n                  Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.\n                  For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01648","_id":"cwe_mitigation/cwe_mitigation_01648","_rev":"_dVfOTUK--0","original_id":"787","name":"Out-of-bounds Write","metadata":{"Phase":"Implementation","Description":"\n                  Consider adhering to the following rules when allocating and managing an application's memory:\n                  \n                     \n                        Double check that the buffer is as large as specified.\n                        When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.\n                        Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.\n                        If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01649","_id":"cwe_mitigation/cwe_mitigation_01649","_rev":"_dVfOTUK--1","original_id":"787","name":"Out-of-bounds Write","metadata":{"Phase":"Operation","Description":"\n                  Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.\n                  Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64].\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01650","_id":"cwe_mitigation/cwe_mitigation_01650","_rev":"_dVfOTUK--2","original_id":"787","name":"Out-of-bounds Write","metadata":{"Phase":"Operation","Description":"Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-60] [REF-61]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01651","_id":"cwe_mitigation/cwe_mitigation_01651","_rev":"_dVfOTUK--3","original_id":"787","name":"Out-of-bounds Write","metadata":{"Phase":"Implementation","Description":"Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01654","_id":"cwe_mitigation/cwe_mitigation_01654","_rev":"_dVfOTUK--4","original_id":"789","name":"Memory Allocation with Excessive Size Value","metadata":{"Phase":"Implementation","Description":"Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01655","_id":"cwe_mitigation/cwe_mitigation_01655","_rev":"_dVfOTUK--5","original_id":"789","name":"Memory Allocation with Excessive Size Value","metadata":{"Phase":"Operation","Description":"Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01656","_id":"cwe_mitigation/cwe_mitigation_01656","_rev":"_dVfOTUK--6","original_id":"798","name":"Use of Hard-coded Credentials","metadata":{"Phase":"Architecture and Design","Description":"\n                  For outbound authentication: store passwords, keys, and other credentials outside of the code in a strongly-protected, encrypted configuration file or database that is protected from access by all outsiders, including other local users on the same system. Properly protect the key (CWE-320). If you cannot use encryption to protect the file, then make sure that the permissions are as restrictive as possible [REF-7].\n                  In Windows environments, the Encrypted File System (EFS) may provide some protection.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01657","_id":"cwe_mitigation/cwe_mitigation_01657","_rev":"_dVfOTUK--7","original_id":"798","name":"Use of Hard-coded Credentials","metadata":{"Phase":"Architecture and Design","Description":"For inbound authentication: Rather than hard-code a default username and password, key, or other authentication credentials for first time logins, utilize a \"first login\" mode that requires the user to enter a unique strong password or key."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01658","_id":"cwe_mitigation/cwe_mitigation_01658","_rev":"_dVfOTUK--8","original_id":"798","name":"Use of Hard-coded Credentials","metadata":{"Phase":"Architecture and Design","Description":"If the software must contain hard-coded credentials or they cannot be removed, perform access control checks and limit which entities can access the feature that requires the hard-coded credentials. For example, a feature might only be enabled through the system console instead of through a network connection."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01659","_id":"cwe_mitigation/cwe_mitigation_01659","_rev":"_dVfOTUK--9","original_id":"798","name":"Use of Hard-coded Credentials","metadata":{"Phase":"Architecture and Design","Description":"\n                  For inbound authentication using passwords: apply strong one-way hashes to passwords and store those hashes in a configuration file or database with appropriate access control. That way, theft of the file/database still requires the attacker to try to crack the password. When handling an incoming password during authentication, take the hash of the password and compare it to the saved hash.\n                  Use randomly assigned salts for each separate hash that is generated. This increases the amount of computation that an attacker needs to conduct a brute-force attack, possibly limiting the effectiveness of the rainbow table method.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01660","_id":"cwe_mitigation/cwe_mitigation_01660","_rev":"_dVfOTUK-_-","original_id":"798","name":"Use of Hard-coded Credentials","metadata":{"Phase":"Architecture and Design","Description":"\n                  For front-end to back-end connections: Three solutions are possible, although none are complete.\n                  \n                     \n                        The first suggestion involves the use of generated passwords or keys that are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals.\n                        Next, the passwords or keys should be limited at the back end to only performing actions valid for the front end, as opposed to having full access.\n                        Finally, the messages sent should be tagged and checksummed with time sensitive values so as to prevent replay-style attacks.\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01672","_id":"cwe_mitigation/cwe_mitigation_01672","_rev":"_dVfOTUK-__","original_id":"805","name":"Buffer Access with Incorrect Length Value","metadata":{"Phase":"Requirements","Description":"\n                  Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.\n                  Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01673","_id":"cwe_mitigation/cwe_mitigation_01673","_rev":"_dVfOTUK-_A","original_id":"805","name":"Buffer Access with Incorrect Length Value","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01674","_id":"cwe_mitigation/cwe_mitigation_01674","_rev":"_dVfOTUK-_B","original_id":"805","name":"Buffer Access with Incorrect Length Value","metadata":{"Phase":"Build and Compilation","Description":"\n                  Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.\n                  For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01675","_id":"cwe_mitigation/cwe_mitigation_01675","_rev":"_dVfOTUO---","original_id":"805","name":"Buffer Access with Incorrect Length Value","metadata":{"Phase":"Implementation","Description":"\n                  Consider adhering to the following rules when allocating and managing an application's memory:\n                  \n                     \n                        Double check that the buffer is as large as specified.\n                        When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string.\n                        Check buffer boundaries if accessing the buffer in a loop and make sure there is no danger of writing past the allocated space.\n                        If necessary, truncate all input strings to a reasonable length before passing them to the copy and concatenation functions.\n                     \n                  \n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01676","_id":"cwe_mitigation/cwe_mitigation_01676","_rev":"_dVfOTUO--_","original_id":"805","name":"Buffer Access with Incorrect Length Value","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01677","_id":"cwe_mitigation/cwe_mitigation_01677","_rev":"_dVfOTUO--A","original_id":"805","name":"Buffer Access with Incorrect Length Value","metadata":{"Phase":"Operation","Description":"\n                  Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.\n                  Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64].\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01678","_id":"cwe_mitigation/cwe_mitigation_01678","_rev":"_dVfOTUO--B","original_id":"805","name":"Buffer Access with Incorrect Length Value","metadata":{"Phase":"Operation","Description":"Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-60] [REF-61]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01679","_id":"cwe_mitigation/cwe_mitigation_01679","_rev":"_dVfOTUO--C","original_id":"805","name":"Buffer Access with Incorrect Length Value","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01680","_id":"cwe_mitigation/cwe_mitigation_01680","_rev":"_dVfOTUO--D","original_id":"805","name":"Buffer Access with Incorrect Length Value","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run the code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.\n                  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01684","_id":"cwe_mitigation/cwe_mitigation_01684","_rev":"_dVfOTUO--E","original_id":"806","name":"Buffer Access Using Size of Source Buffer","metadata":{"Phase":"Architecture and Design","Description":"Use an abstraction library to abstract away risky APIs. Examples include the Safe C String Library (SafeStr) by Viega, and the Strsafe.h library from Microsoft. This is not a complete solution, since many buffer overflows are not related to strings."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01685","_id":"cwe_mitigation/cwe_mitigation_01685","_rev":"_dVfOTUO--F","original_id":"806","name":"Buffer Access Using Size of Source Buffer","metadata":{"Phase":"Build and Compilation","Description":"Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include StackGuard, ProPolice and the Microsoft Visual Studio /GS flag. This is not necessarily a complete solution, since these canary-based mechanisms only detect certain types of overflows. In addition, the result is still a denial of service, since the typical response is to exit the application."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01686","_id":"cwe_mitigation/cwe_mitigation_01686","_rev":"_dVfOTUO--G","original_id":"806","name":"Buffer Access Using Size of Source Buffer","metadata":{"Phase":"Implementation","Description":"Programmers should adhere to the following rules when allocating and managing their applications memory: Double check that your buffer is as large as you specify. When using functions that accept a number of bytes to copy, such as strncpy(), be aware that if the destination buffer size is equal to the source buffer size, it may not NULL-terminate the string. Check buffer boundaries if calling this function in a loop and make sure there is no danger of writing past the allocated space. Truncate all input strings to a reasonable length before passing them to the copy and concatenation functions"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01687","_id":"cwe_mitigation/cwe_mitigation_01687","_rev":"_dVfOTUO--H","original_id":"806","name":"Buffer Access Using Size of Source Buffer","metadata":{"Phase":"Operation","Description":"\n                  Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.\n                  Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64].\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01688","_id":"cwe_mitigation/cwe_mitigation_01688","_rev":"_dVfOTUO--I","original_id":"806","name":"Buffer Access Using Size of Source Buffer","metadata":{"Phase":"Operation","Description":"Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [REF-60] [REF-61]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01689","_id":"cwe_mitigation/cwe_mitigation_01689","_rev":"_dVfOTUO--J","original_id":"806","name":"Buffer Access Using Size of Source Buffer","metadata":{"Phase":"Build and Compilation","Description":"Most mitigating technologies at the compiler or OS level to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is good practice to implement strategies to increase the workload of an attacker, such as leaving the attacker to guess an unknown value that changes every program execution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01690","_id":"cwe_mitigation/cwe_mitigation_01690","_rev":"_dVfOTUO--K","original_id":"807","name":"Reliance on Untrusted Inputs in a Security Decision","metadata":{"Phase":"Architecture and Design","Description":"\n                  Store state information and sensitive data on the server side only.\n                  Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.\n                  If information must be stored on the client, do not do so without encryption and integrity checking, or otherwise having a mechanism on the server side to catch tampering. Use a message authentication code (MAC) algorithm, such as Hash Message Authentication Code (HMAC) [REF-529]. Apply this against the state or sensitive data that you has to be exposed, which can guarantee the integrity of the data - i.e., that the data has not been modified. Ensure that a strong hash function is used (CWE-328).\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01691","_id":"cwe_mitigation/cwe_mitigation_01691","_rev":"_dVfOTUO--L","original_id":"807","name":"Reliance on Untrusted Inputs in a Security Decision","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  With a stateless protocol such as HTTP, use a framework that maintains the state for you.\n                  Examples include ASP.NET View State [REF-756] and the OWASP ESAPI Session Management feature [REF-45].\n                  Be careful of language features that provide state support, since these might be provided as a convenience to the programmer and may not be considering security.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01692","_id":"cwe_mitigation/cwe_mitigation_01692","_rev":"_dVfOTUO--M","original_id":"807","name":"Reliance on Untrusted Inputs in a Security Decision","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01693","_id":"cwe_mitigation/cwe_mitigation_01693","_rev":"_dVfOTUO--N","original_id":"807","name":"Reliance on Untrusted Inputs in a Security Decision","metadata":{"Phase":"Operation","Description":"When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01694","_id":"cwe_mitigation/cwe_mitigation_01694","_rev":"_dVfOTUO--O","original_id":"807","name":"Reliance on Untrusted Inputs in a Security Decision","metadata":{"Phase":"Architecture and Design","Description":"\n                  Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.\n                  Identify all inputs that are used for security decisions and determine if you can modify the design so that you do not have to rely on submitted inputs at all. For example, you may be able to keep critical information about the user's session on the server side instead of recording it within external data.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01703","_id":"cwe_mitigation/cwe_mitigation_01703","_rev":"_dVfOTUO--P","original_id":"825","name":"Expired Pointer Dereference","metadata":{"Phase":"Architecture and Design","Description":"Choose a language that provides automatic memory management."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01704","_id":"cwe_mitigation/cwe_mitigation_01704","_rev":"_dVfOTUO--Q","original_id":"825","name":"Expired Pointer Dereference","metadata":{"Phase":"Implementation","Description":"When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01705","_id":"cwe_mitigation/cwe_mitigation_01705","_rev":"_dVfOTUO--R","original_id":"828","name":"Signal Handler with Functionality that is not Asynchronous-Safe","metadata":{"Phase":"Implementation","Description":"\n                  Eliminate the usage of non-reentrant functionality inside of signal handlers. This includes replacing all non-reentrant library calls with reentrant calls.\n                  Note: This will not always be possible and may require large portions of the software to be rewritten or even redesigned. Sometimes reentrant-safe library alternatives will not be available. Sometimes non-reentrant interaction between the state of the system and the signal handler will be required by design.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01706","_id":"cwe_mitigation/cwe_mitigation_01706","_rev":"_dVfOTUO--S","original_id":"828","name":"Signal Handler with Functionality that is not Asynchronous-Safe","metadata":{"Phase":"Implementation","Description":"Where non-reentrant functionality must be leveraged within a signal handler, be sure to block or mask signals appropriately. This includes blocking other signals within the signal handler itself that may also leverage the functionality. It also includes blocking all signals reliant upon the functionality when it is being accessed or modified by the normal behaviors of the software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01707","_id":"cwe_mitigation/cwe_mitigation_01707","_rev":"_dVfOTUO--T","original_id":"829","name":"Inclusion of Functionality from Untrusted Control Sphere","metadata":{"Phase":"Architecture and Design","Description":"Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01708","_id":"cwe_mitigation/cwe_mitigation_01708","_rev":"_dVfOTUO--U","original_id":"829","name":"Inclusion of Functionality from Untrusted Control Sphere","metadata":{"Phase":"Architecture and Design","Description":"\n                  When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.\n                  For example, ID 1 could map to \"inbox.txt\" and ID 2 could map to \"profile.txt\". Features such as the ESAPI AccessReferenceMap [REF-45] provide this capability.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01709","_id":"cwe_mitigation/cwe_mitigation_01709","_rev":"_dVfOTUO--V","original_id":"829","name":"Inclusion of Functionality from Untrusted Control Sphere","metadata":{"Phase":"Architecture and Design","Description":"For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01710","_id":"cwe_mitigation/cwe_mitigation_01710","_rev":"_dVfOTUO--W","original_id":"829","name":"Inclusion of Functionality from Untrusted Control Sphere","metadata":{"Phase":"Architecture and Design","Description":"\n                  Run the code in a \"jail\" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.\n                  OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.\n                  This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.\n                  Be careful to avoid CWE-243 and other weaknesses related to jails.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01711","_id":"cwe_mitigation/cwe_mitigation_01711","_rev":"_dVfOTUO--X","original_id":"829","name":"Inclusion of Functionality from Untrusted Control Sphere","metadata":{"Phase":"Architecture and Design","Description":"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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01712","_id":"cwe_mitigation/cwe_mitigation_01712","_rev":"_dVfOTUO--Y","original_id":"829","name":"Inclusion of Functionality from Untrusted Control Sphere","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n                  When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single \".\" character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as \"/\" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.\n                  Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering \"/\" is insufficient protection if the filesystem also supports the use of \"\\\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if \"../\" sequences are removed from the \".../...//\" string in a sequential fashion, two instances of \"../\" would be removed from the original string, but the remaining characters would still form the \"../\" string.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01713","_id":"cwe_mitigation/cwe_mitigation_01713","_rev":"_dVfOTUO--Z","original_id":"829","name":"Inclusion of Functionality from Untrusted Control Sphere","metadata":{"Phase":"Architecture and Design","Description":"\n                  Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.\n                  This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01714","_id":"cwe_mitigation/cwe_mitigation_01714","_rev":"_dVfOTUO--a","original_id":"829","name":"Inclusion of Functionality from Untrusted Control Sphere","metadata":{"Phase":"Architecture and Design","Description":"\n                  Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.\n                  Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01715","_id":"cwe_mitigation/cwe_mitigation_01715","_rev":"_dVfOTUO--b","original_id":"829","name":"Inclusion of Functionality from Untrusted Control Sphere","metadata":{"Phase":"Operation","Description":"Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01726","_id":"cwe_mitigation/cwe_mitigation_01726","_rev":"_dVfOTUO--c","original_id":"838","name":"Inappropriate Encoding for Output Context","metadata":{"Phase":"Implementation","Description":"Use context-aware encoding. That is, understand which encoding is being used by the downstream component, and ensure that this encoding is used. If an encoding can be specified, do so, instead of assuming that the default encoding is the same as the default being assumed by the downstream component."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01727","_id":"cwe_mitigation/cwe_mitigation_01727","_rev":"_dVfOTUO--d","original_id":"838","name":"Inappropriate Encoding for Output Context","metadata":{"Phase":"Architecture and Design","Description":"Where possible, use communications protocols or data formats that provide strict boundaries between control and data. If this is not feasible, ensure that the protocols or formats allow the communicating components to explicitly state which encoding/decoding method is being used. Some template frameworks provide built-in support."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01728","_id":"cwe_mitigation/cwe_mitigation_01728","_rev":"_dVfOTUO--e","original_id":"838","name":"Inappropriate Encoding for Output Context","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.\n                  Note that some template mechanisms provide built-in support for the appropriate encoding.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01729","_id":"cwe_mitigation/cwe_mitigation_01729","_rev":"_dVfOTUO--f","original_id":"839","name":"Numeric Range Comparison Without Minimum Check","metadata":{"Phase":"Implementation","Description":"If the number to be used is always expected to be positive, change the variable type from signed to unsigned or size_t."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01730","_id":"cwe_mitigation/cwe_mitigation_01730","_rev":"_dVfOTUO--g","original_id":"839","name":"Numeric Range Comparison Without Minimum Check","metadata":{"Phase":"Implementation","Description":"If the number to be used could have a negative value based on the specification (thus requiring a signed value), but the number should only be positive to preserve code correctness, then include a check to ensure that the value is positive."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01731","_id":"cwe_mitigation/cwe_mitigation_01731","_rev":"_dVfOTUO--h","original_id":"862","name":"Missing Authorization","metadata":{"Phase":"Architecture and Design","Description":"\n                  Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.\n                  Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01732","_id":"cwe_mitigation/cwe_mitigation_01732","_rev":"_dVfOTUO--i","original_id":"862","name":"Missing Authorization","metadata":{"Phase":"Architecture and Design","Description":"Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01733","_id":"cwe_mitigation/cwe_mitigation_01733","_rev":"_dVfOTUO--j","original_id":"862","name":"Missing Authorization","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01734","_id":"cwe_mitigation/cwe_mitigation_01734","_rev":"_dVfOTUO--k","original_id":"862","name":"Missing Authorization","metadata":{"Phase":"Architecture and Design","Description":"\n                  For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.\n                  One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01735","_id":"cwe_mitigation/cwe_mitigation_01735","_rev":"_dVfOTUO--l","original_id":"862","name":"Missing Authorization","metadata":{"Phase":"System Configuration","Description":"Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a \"default deny\" policy when defining these ACLs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01745","_id":"cwe_mitigation/cwe_mitigation_01745","_rev":"_dVfOTUO--m","original_id":"863","name":"Incorrect Authorization","metadata":{"Phase":"Architecture and Design","Description":"\n                  Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.\n                  Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01746","_id":"cwe_mitigation/cwe_mitigation_01746","_rev":"_dVfOTUO--n","original_id":"863","name":"Incorrect Authorization","metadata":{"Phase":"Architecture and Design","Description":"Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01747","_id":"cwe_mitigation/cwe_mitigation_01747","_rev":"_dVfOTUO--o","original_id":"863","name":"Incorrect Authorization","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.\n                  For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01748","_id":"cwe_mitigation/cwe_mitigation_01748","_rev":"_dVfOTUO--p","original_id":"863","name":"Incorrect Authorization","metadata":{"Phase":"Architecture and Design","Description":"\n                  For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.\n                  One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01749","_id":"cwe_mitigation/cwe_mitigation_01749","_rev":"_dVfOTUO--q","original_id":"863","name":"Incorrect Authorization","metadata":{"Phase":"System Configuration","Description":"Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a \"default deny\" policy when defining these ACLs."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01759","_id":"cwe_mitigation/cwe_mitigation_01759","_rev":"_dVfOTUO--r","original_id":"908","name":"Use of Uninitialized Resource","metadata":{"Phase":"Implementation","Description":"Explicitly initialize the resource before use. If this is performed through an API function or standard procedure, follow all required steps."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01760","_id":"cwe_mitigation/cwe_mitigation_01760","_rev":"_dVfOTUO--s","original_id":"908","name":"Use of Uninitialized Resource","metadata":{"Phase":"Implementation","Description":"Pay close attention to complex conditionals that affect initialization, since some branches might not perform the initialization."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01761","_id":"cwe_mitigation/cwe_mitigation_01761","_rev":"_dVfOTUO--t","original_id":"908","name":"Use of Uninitialized Resource","metadata":{"Phase":"Implementation","Description":"Avoid race conditions (CWE-362) during initialization routines."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01762","_id":"cwe_mitigation/cwe_mitigation_01762","_rev":"_dVfOTUO--u","original_id":"908","name":"Use of Uninitialized Resource","metadata":{"Phase":"Build and Compilation","Description":"Run or compile the software with settings that generate warnings about uninitialized variables or data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01763","_id":"cwe_mitigation/cwe_mitigation_01763","_rev":"_dVfOTUO--v","original_id":"909","name":"Missing Initialization of Resource","metadata":{"Phase":"Implementation","Description":"Explicitly initialize the resource before use. If this is performed through an API function or standard procedure, follow all specified steps."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01764","_id":"cwe_mitigation/cwe_mitigation_01764","_rev":"_dVfOTUO--w","original_id":"909","name":"Missing Initialization of Resource","metadata":{"Phase":"Implementation","Description":"Pay close attention to complex conditionals that affect initialization, since some branches might not perform the initialization."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01765","_id":"cwe_mitigation/cwe_mitigation_01765","_rev":"_dVfOTUO--x","original_id":"909","name":"Missing Initialization of Resource","metadata":{"Phase":"Implementation","Description":"Avoid race conditions (CWE-362) during initialization routines."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01766","_id":"cwe_mitigation/cwe_mitigation_01766","_rev":"_dVfOTUO--y","original_id":"909","name":"Missing Initialization of Resource","metadata":{"Phase":"Build and Compilation","Description":"Run or compile your software with settings that generate warnings about uninitialized variables or data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01767","_id":"cwe_mitigation/cwe_mitigation_01767","_rev":"_dVfOTUO--z","original_id":"912","name":"Hidden Functionality","metadata":{"Phase":"Installation","Description":"Always verify the integrity of the software that is being installed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01768","_id":"cwe_mitigation/cwe_mitigation_01768","_rev":"_dVfOTUO--0","original_id":"912","name":"Hidden Functionality","metadata":{"Phase":"Testing","Description":"Conduct a code coverage analysis using live testing, then closely inspect any code that is not covered."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01769","_id":"cwe_mitigation/cwe_mitigation_01769","_rev":"_dVfOTUO--1","original_id":"913","name":"Improper Control of Dynamically-Managed Code Resources","metadata":{"Phase":"Implementation","Description":"For any externally-influenced input, check the input against an allowlist of acceptable values."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01770","_id":"cwe_mitigation/cwe_mitigation_01770","_rev":"_dVfOTUO--2","original_id":"913","name":"Improper Control of Dynamically-Managed Code Resources","metadata":{"Phase":"Implementation","Description":"Refactor the code so that it does not need to be dynamically managed."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01771","_id":"cwe_mitigation/cwe_mitigation_01771","_rev":"_dVfOTUO--3","original_id":"914","name":"Improper Control of Dynamically-Identified Variables","metadata":{"Phase":"Implementation","Description":"For any externally-influenced input, check the input against an allowlist of internal program variables that are allowed to be modified."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01772","_id":"cwe_mitigation/cwe_mitigation_01772","_rev":"_dVfOTUO--4","original_id":"914","name":"Improper Control of Dynamically-Identified Variables","metadata":{"Phase":"Implementation","Description":"Refactor the code so that internal program variables do not need to be dynamically identified."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01773","_id":"cwe_mitigation/cwe_mitigation_01773","_rev":"_dVfOTUS---","original_id":"915","name":"Improperly Controlled Modification of Dynamically-Determined Object Attributes","metadata":{"Phase":"Implementation","Description":"\n                  If available, use features of the language or framework that allow specification of allowlists of attributes or fields that are allowed to be modified. If possible, prefer allowlists over denylists.\n                  For applications written with Ruby on Rails, use the attr_accessible (allowlist) or attr_protected (denylist) macros in each class that may be used in mass assignment.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01774","_id":"cwe_mitigation/cwe_mitigation_01774","_rev":"_dVfOTUS--_","original_id":"915","name":"Improperly Controlled Modification of Dynamically-Determined Object Attributes","metadata":{"Phase":"Architecture and Design","Description":"If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01775","_id":"cwe_mitigation/cwe_mitigation_01775","_rev":"_dVfOTUS--A","original_id":"915","name":"Improperly Controlled Modification of Dynamically-Determined Object Attributes","metadata":{"Phase":"Implementation","Description":"For any externally-influenced input, check the input against an allowlist of internal object attributes or fields that are allowed to be modified."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01776","_id":"cwe_mitigation/cwe_mitigation_01776","_rev":"_dVfOTUS--B","original_id":"915","name":"Improperly Controlled Modification of Dynamically-Determined Object Attributes","metadata":{"Phase":"Implementation","Description":"Refactor the code so that object attributes or fields do not need to be dynamically identified, and only expose getter/setter functionality for the intended attributes."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01777","_id":"cwe_mitigation/cwe_mitigation_01777","_rev":"_dVfOTUS--C","original_id":"916","name":"Use of Password Hash With Insufficient Computational Effort","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations (\"stretching\") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use.\n                  Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead.\n                  Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01778","_id":"cwe_mitigation/cwe_mitigation_01778","_rev":"_dVfOTUS--D","original_id":"916","name":"Use of Password Hash With Insufficient Computational Effort","metadata":{"Phase":"Implementation","Description":"When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for preventing common attacks."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01785","_id":"cwe_mitigation/cwe_mitigation_01785","_rev":"_dVfOTUS--E","original_id":"925","name":"Improper Verification of Intent by Broadcast Receiver","metadata":{"Phase":"Architecture and Design","Description":"Before acting on the Intent, check the Intent Action to make sure it matches the expected System action."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01786","_id":"cwe_mitigation/cwe_mitigation_01786","_rev":"_dVfOTUS--F","original_id":"926","name":"Improper Export of Android Application Components","metadata":{"Phase":"Build and Compilation","Description":"If they do not need to be shared by other applications, explicitly mark components with android:exported=\"false\" in the application manifest."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01787","_id":"cwe_mitigation/cwe_mitigation_01787","_rev":"_dVfOTUS--G","original_id":"926","name":"Improper Export of Android Application Components","metadata":{"Phase":"Build and Compilation","Description":"If you only intend to use exported components between related apps under your control, use android:protectionLevel=\"signature\" in the xml manifest to restrict access to applications signed by you."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01788","_id":"cwe_mitigation/cwe_mitigation_01788","_rev":"_dVfOTUS--H","original_id":"926","name":"Improper Export of Android Application Components","metadata":{"Phase":"Build and Compilation","Description":"Limit Content Provider permissions (read/write) as appropriate."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01789","_id":"cwe_mitigation/cwe_mitigation_01789","_rev":"_dVfOTUS--I","original_id":"926","name":"Improper Export of Android Application Components","metadata":{"Phase":"Build and Compilation","Description":"Limit Content Provider permissions (read/write) as appropriate."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01790","_id":"cwe_mitigation/cwe_mitigation_01790","_rev":"_dVfOTUS--J","original_id":"927","name":"Use of Implicit Intent for Sensitive Communication","metadata":{"Phase":"Implementation","Description":"If the application only requires communication with its own components, then the destination is always known, and an explicit intent could be used."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01791","_id":"cwe_mitigation/cwe_mitigation_01791","_rev":"_dVfOTUS--K","original_id":"939","name":"Improper Authorization in Handler for Custom URL Scheme","metadata":{"Phase":"Architecture and Design","Description":"\n                  Utilize a user prompt pop-up to authorize potentially harmful actions such as those modifying data or dealing with sensitive information.\n                  When designing functionality of actions in the URL scheme, consider whether the action should be accessible to all mobile applications, or if an allowlist of applications to interface with is appropriate.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01792","_id":"cwe_mitigation/cwe_mitigation_01792","_rev":"_dVfOTUS--L","original_id":"940","name":"Improper Verification of Source of a Communication Channel","metadata":{"Phase":"Architecture and Design","Description":"\n                  Use a mechanism that can validate the identity of the source, such as a certificate, and validate the integrity of data to ensure that it cannot be modified in transit using an Adversary-in-the-Middle (AITM) attack.\n                  When designing functionality of actions in the URL scheme, consider whether the action should be accessible to all mobile applications, or if an allowlist of applications to interface with is appropriate.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01793","_id":"cwe_mitigation/cwe_mitigation_01793","_rev":"_dVfOTUS--M","original_id":"942","name":"Permissive Cross-domain Policy with Untrusted Domains","metadata":{"Phase":"Architecture and Design","Description":"Avoid using wildcards in the cross-domain policy file. Any domain matching the wildcard expression will be implicitly trusted, and can perform two-way interaction with the target server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01794","_id":"cwe_mitigation/cwe_mitigation_01794","_rev":"_dVfOTUS--N","original_id":"942","name":"Permissive Cross-domain Policy with Untrusted Domains","metadata":{"Phase":"Architecture and Design","Description":"For Flash, modify crossdomain.xml to use meta-policy options such as 'master-only' or 'none' to reduce the possibility of an attacker planting extraneous cross-domain policy files on a server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01795","_id":"cwe_mitigation/cwe_mitigation_01795","_rev":"_dVfOTUS--O","original_id":"942","name":"Permissive Cross-domain Policy with Untrusted Domains","metadata":{"Phase":"Architecture and Design","Description":"For Flash, modify crossdomain.xml to use meta-policy options such as 'master-only' or 'none' to reduce the possibility of an attacker planting extraneous cross-domain policy files on a server."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01796","_id":"cwe_mitigation/cwe_mitigation_01796","_rev":"_dVfOTUS--P","original_id":"1004","name":"Sensitive Cookie Without 'HttpOnly' Flag","metadata":{"Phase":"Implementation","Description":"Leverage the HttpOnly flag when setting a sensitive cookie in a response."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01797","_id":"cwe_mitigation/cwe_mitigation_01797","_rev":"_dVfOTUS--Q","original_id":"1007","name":"Insufficient Visual Distinction of Homoglyphs Presented to User","metadata":{"Phase":"Implementation","Description":"\n                  Use a browser that displays Punycode for IDNs in the URL and status bars, or which color code various scripts in URLs.\n                  Due to the prominence of homoglyph attacks, several browsers now help safeguard against this attack via the use of Punycode. For example, Mozilla Firefox and Google Chrome will display IDNs as Punycode if top-level domains do not restrict which characters can be used in domain names or if labels mix scripts for different languages.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01798","_id":"cwe_mitigation/cwe_mitigation_01798","_rev":"_dVfOTUS--R","original_id":"1007","name":"Insufficient Visual Distinction of Homoglyphs Presented to User","metadata":{"Phase":"Implementation","Description":"\n                  Use an email client that has strict filters and prevents messages that mix character sets to end up in a user's inbox.\n                  Certain email clients such as Google's GMail prevent the use of non-Latin characters in email addresses or in links contained within emails. This helps prevent homoglyph attacks by flagging these emails and redirecting them to a user's spam folder.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01800","_id":"cwe_mitigation/cwe_mitigation_01800","_rev":"_dVfOTUS--S","original_id":"1021","name":"Improper Restriction of Rendered UI Layers or Frames","metadata":{"Phase":"Implementation","Description":"\n                  The use of X-Frame-Options allows developers of web content to restrict the usage of their application within the form of overlays, frames, or iFrames. The developer can indicate from which domains can frame the content.\n                  The concept of X-Frame-Options is well documented, but implementation of this protection mechanism is in development to cover gaps. There is a need for allowing frames from multiple domains.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01801","_id":"cwe_mitigation/cwe_mitigation_01801","_rev":"_dVfOTUS--T","original_id":"1021","name":"Improper Restriction of Rendered UI Layers or Frames","metadata":{"Phase":"Implementation","Description":"\n                  A developer can use a \"frame-breaker\" script in each page that should not be framed. This is very helpful for legacy browsers that do not support X-Frame-Options security feature previously mentioned.\n                  It is also important to note that this tactic has been circumvented or bypassed. Improper usage of frames can persist in the web application through nested frames. The \"frame-breaking\" script does not intuitively account for multiple nested frames that can be presented to the user.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01802","_id":"cwe_mitigation/cwe_mitigation_01802","_rev":"_dVfOTUS--U","original_id":"1021","name":"Improper Restriction of Rendered UI Layers or Frames","metadata":{"Phase":"Implementation","Description":"This defense-in-depth technique can be used to prevent the improper usage of frames in web applications. It prioritizes the valid sources of data to be loaded into the application through the usage of declarative policies. Based on which implementation of Content Security Policy is in use, the developer should use the \"frame-ancestors\" directive or the \"frame-src\" directive to mitigate this weakness. Both directives allow for the placement of restrictions when it comes to allowing embedded content."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01803","_id":"cwe_mitigation/cwe_mitigation_01803","_rev":"_dVfOTUS--V","original_id":"1022","name":"Use of Web Link to Untrusted Target with window.opener Access","metadata":{"Phase":"Architecture and Design","Description":"Specify in the design that any linked external document must not be granted access to the location object of the calling page."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01804","_id":"cwe_mitigation/cwe_mitigation_01804","_rev":"_dVfOTUS--W","original_id":"1022","name":"Use of Web Link to Untrusted Target with window.opener Access","metadata":{"Phase":"Implementation","Description":"\n                  When creating a link to an external document using the <a> tag with a defined target, for example \"_blank\" or a named frame, provide the rel attribute with a value \"noopener noreferrer\".\n                  If opening the external document in a new window via javascript, then reset the opener by setting it equal to null.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01805","_id":"cwe_mitigation/cwe_mitigation_01805","_rev":"_dVfOTUS--X","original_id":"1022","name":"Use of Web Link to Untrusted Target with window.opener Access","metadata":{"Phase":"Implementation","Description":"\n                  Do not use \"_blank\" targets. However, this can affect the usability of the application.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01806","_id":"cwe_mitigation/cwe_mitigation_01806","_rev":"_dVfOTUS--Y","original_id":"1023","name":"Incomplete Comparison with Missing Factors","metadata":{"Phase":"Testing","Description":"Thoroughly test the comparison scheme before deploying code into production. Perform positive testing as well as negative testing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01807","_id":"cwe_mitigation/cwe_mitigation_01807","_rev":"_dVfOTUS--Z","original_id":"1024","name":"Comparison of Incompatible Types","metadata":{"Phase":"Testing","Description":"Thoroughly test the comparison scheme before deploying code into production. Perform positive testing as well as negative testing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01808","_id":"cwe_mitigation/cwe_mitigation_01808","_rev":"_dVfOTUS--a","original_id":"1025","name":"Comparison Using Wrong Factors","metadata":{"Phase":"Testing","Description":"Thoroughly test the comparison scheme before deploying code into production. Perform positive testing as well as negative testing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01810","_id":"cwe_mitigation/cwe_mitigation_01810","_rev":"_dVfOTUS--b","original_id":"1173","name":"Improper Use of Validation Framework","metadata":{"Phase":"Implementation","Description":"Properly use provided input validation frameworks."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01812","_id":"cwe_mitigation/cwe_mitigation_01812","_rev":"_dVfOTUS--c","original_id":"1189","name":"Improper Isolation of Shared Resources on System-on-a-Chip (SoC)","metadata":{"Phase":"Architecture and Design","Description":"\n                 When sharing resources, avoid mixing agents of varying trust levels.\n                 Untrusted agents should not share resources with trusted agents.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01814","_id":"cwe_mitigation/cwe_mitigation_01814","_rev":"_dVfOTUS--d","original_id":"1190","name":"DMA Device Enabled Too Early in Boot Phase","metadata":{"Phase":"Architecture and Design","Description":"Utilize an IOMMU to orchestrate IO access from\n                 the start of the boot process."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01815","_id":"cwe_mitigation/cwe_mitigation_01815","_rev":"_dVfOTUS--e","original_id":"1191","name":"On-Chip Debug and Test Interface With Improper Access Control","metadata":{"Phase":"Architecture and Design","Description":"\n\t   If feasible, the manufacturer should disable the JTAG interface or implement authentication and authorization for the JTAG interface. If authentication logic is added, it should be resistant to timing attacks. Security-sensitive data stored in registers, such as keys, etc. should be cleared when entering debug mode.\n\t "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01819","_id":"cwe_mitigation/cwe_mitigation_01819","_rev":"_dVfOTUS--f","original_id":"1192","name":"System-on-Chip (SoC) Using Components without Unique, Immutable Identifiers","metadata":{"Phase":"Architecture and Design","Description":"\n                  \n                    Every identity generated in the SoC should be unique and\n                    immutable in hardware. The actions that an IP is trusted or\n                    not trusted should be clearly defined, implemented,\n                    configured, and tested. If the definition is implemented via a\n                    policy, then the policy should be immutable or protected with\n                    clear authentication and authorization.\n                  \n                "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01820","_id":"cwe_mitigation/cwe_mitigation_01820","_rev":"_dVfOTUS--g","original_id":"1193","name":"Power-On of Untrusted Execution Core Before Enabling Fabric Access Control","metadata":{"Phase":"Architecture and Design","Description":"\n                  The boot sequence should enable fabric access controls and memory protections before enabling third-party hardware IPs and peripheral microcontrollers that use untrusted firmware.\n                "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01821","_id":"cwe_mitigation/cwe_mitigation_01821","_rev":"_dVfOTUS--h","original_id":"1204","name":"Generation of Weak Initialization Vector (IV)","metadata":{"Phase":"Implementation","Description":"Different cipher\n\t\t\t    modes have different requirements for\n\t\t\t    their IVs. When choosing and implementing\n\t\t\t    a mode, it is important to understand\n\t\t\t    those requirements in order to keep\n\t\t\t    security guarantees intact. Generally, it\n\t\t\t    is safest to generate a random IV, since\n\t\t\t    it will be both unpredictable and have a\n\t\t\t    very low chance of being non-unique. IVs\n\t\t\t    do not have to be kept secret, so if\n\t\t\t    generating duplicate IVs is a concern, a\n\t\t\t    list of already-used IVs can be kept and\n\t\t\t    checked against.\n\t\t\t    \n\t\t\t    \n\t\t\t      NIST offers recommendations on generation of IVs for modes of which they have approved. These include options for when random IVs are not practical. For CBC, CFB, and OFB, see [REF-1175]; for GCM, see [REF-1178].\n\t\t\t    \n\t\t\t    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01822","_id":"cwe_mitigation/cwe_mitigation_01822","_rev":"_dVfOTUS--i","original_id":"1209","name":"Failure to Disable Reserved Bits","metadata":{"Phase":"Architecture and Design","Description":"\n                        Include a feature to disable reserved bits.                     \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01823","_id":"cwe_mitigation/cwe_mitigation_01823","_rev":"_dVfOTUS--j","original_id":"1209","name":"Failure to Disable Reserved Bits","metadata":{"Phase":"Integration","Description":"\n                    \tAny writes to these reserve bits are blocked (e.g., ignored, access-protected, etc.), or an exception can be asserted.\n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01824","_id":"cwe_mitigation/cwe_mitigation_01824","_rev":"_dVfOTUS--k","original_id":"1220","name":"Insufficient Granularity of Access Control","metadata":{"Phase":"Architecture and Design","Description":"\n                        \n                            Access-control-policy protections must be reviewed for design inconsistency and common weaknesses.\n                            Access-control-policy definition and programming flow must be tested in pre-silicon, post-silicon testing.\n                        \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01825","_id":"cwe_mitigation/cwe_mitigation_01825","_rev":"_dVfOTUS--l","original_id":"1221","name":"Incorrect Register Defaults or Module Parameters","metadata":{"Phase":"Architecture and Design","Description":"During hardware design, all the system parameters and register defaults must be reviewed to identify security sensitive settings."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01826","_id":"cwe_mitigation/cwe_mitigation_01826","_rev":"_dVfOTUS--m","original_id":"1221","name":"Incorrect Register Defaults or Module Parameters","metadata":{"Phase":"Implementation","Description":"The default values of these security sensitive settings need to be defined as part of the design review phase."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01827","_id":"cwe_mitigation/cwe_mitigation_01827","_rev":"_dVfOTUS--n","original_id":"1221","name":"Incorrect Register Defaults or Module Parameters","metadata":{"Phase":"Testing","Description":"Testing phase should use automated tools to test that values are configured per design specifications."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01828","_id":"cwe_mitigation/cwe_mitigation_01828","_rev":"_dVfOTUS--o","original_id":"1222","name":"Insufficient Granularity of Address Regions Protected by Register Locks","metadata":{"Phase":"Architecture and Design","Description":"\n                        The defining of protected locked registers should be reviewed or tested early in the design phase with software teams to ensure software flows are not blocked by the security locks.\n                        As an alternative to using register lock control bits and fixed access control regions, the hardware design could use programmable security access control configuration so that device trusted firmware can configure and change the protected regions based on software usage and security models.\n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01829","_id":"cwe_mitigation/cwe_mitigation_01829","_rev":"_dVfOTUS--p","original_id":"1223","name":"Race Condition for Write-Once Attributes","metadata":{"Phase":"Architecture and Design","Description":"During hardware design all register write-once or sticky fields must be evaluated for proper configuration."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01830","_id":"cwe_mitigation/cwe_mitigation_01830","_rev":"_dVfOTUS--q","original_id":"1223","name":"Race Condition for Write-Once Attributes","metadata":{"Phase":"Testing","Description":"The testing phase should use automated tools to test that values are not reprogrammable and that write-once fields lock on writing zeros."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01831","_id":"cwe_mitigation/cwe_mitigation_01831","_rev":"_dVfOTUS--r","original_id":"1224","name":"Improper Restriction of Write-Once Bit Fields","metadata":{"Phase":"Architecture and Design","Description":"During hardware design all register write-once or sticky fields must be evaluated for proper configuration."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01832","_id":"cwe_mitigation/cwe_mitigation_01832","_rev":"_dVfOTUS--s","original_id":"1224","name":"Improper Restriction of Write-Once Bit Fields","metadata":{"Phase":"Testing","Description":"The testing phase should use automated tools to test that values are not reprogrammable and that write-once fields lock on writing zeros."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01833","_id":"cwe_mitigation/cwe_mitigation_01833","_rev":"_dVfOTUS--t","original_id":"1231","name":"Improper Prevention of Lock Bit Modification","metadata":{"Phase":"Architecture and Design","Description":"\n                        \n                            Security lock bit protections must be reviewed for design inconsistency and common weaknesses.\n                            Security lock programming flow and lock properties must be tested in pre-silicon and post-silicon testing.\n                        \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01835","_id":"cwe_mitigation/cwe_mitigation_01835","_rev":"_dVfOTUS--u","original_id":"1232","name":"Improper Lock Behavior After Power State Transition","metadata":{"Phase":"Architecture and Design","Description":"\n            \n              Security Lock bit protections should be reviewed for behavior across supported power state transitions.\n              Security lock programming flow and lock properties should be tested in pre-silicon and post-silicon testing including testing across power transitions.\n            \n          "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01836","_id":"cwe_mitigation/cwe_mitigation_01836","_rev":"_dVfOTUS--v","original_id":"1233","name":"Security-Sensitive Hardware Controls with Missing Lock Bit Protection","metadata":{"Phase":"Architecture and Design","Description":"\n                        \n                            Security lock bit protections must be reviewed for design inconsistency and common weaknesses.\n\t\t\t    Security lock programming flow and lock properties must be tested in pre-silicon and post-silicon testing.\n                        \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01838","_id":"cwe_mitigation/cwe_mitigation_01838","_rev":"_dVfOTUS--w","original_id":"1234","name":"Hardware Internal or Debug Modes Allow Override of Locks","metadata":{"Phase":"Architecture and Design","Description":"\n         \n          Security Lock bit protections should be reviewed for any bypass/override modes supported.\n          Any supported override modes either should be removed or protected using authenticated debug modes.\n          Security lock programming flow and lock properties should be tested in pre-silicon and post-silicon testing.\n        \n       "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01839","_id":"cwe_mitigation/cwe_mitigation_01839","_rev":"_dVfOTUS--x","original_id":"1235","name":"Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations","metadata":{"Phase":"Implementation","Description":"Use of boxed primitives should be limited to certain situations such as when calling methods with typed parameters.  Examine the use of boxed primitives prior to use. Use SparseArrays or ArrayMap instead of HashMap to avoid performance overhead."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01840","_id":"cwe_mitigation/cwe_mitigation_01840","_rev":"_dVfOTUS--y","original_id":"1236","name":"Improper Neutralization of Formula Elements in a CSV File","metadata":{"Phase":"Implementation","Description":"When generating CSV output, ensure that formula-sensitive metacharacters are effectively escaped or removed from all data before storage in the resultant CSV.  Risky characters include '=' (equal), '+' (plus), '-' (minus), and '@' (at)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01841","_id":"cwe_mitigation/cwe_mitigation_01841","_rev":"_dVfOTUS--z","original_id":"1236","name":"Improper Neutralization of Formula Elements in a CSV File","metadata":{"Phase":"Implementation","Description":"If a field starts with a formula character, prepend it with a ' (single apostrophe), which prevents Excel from executing the formula."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01842","_id":"cwe_mitigation/cwe_mitigation_01842","_rev":"_dVfOTUS--0","original_id":"1236","name":"Improper Neutralization of Formula Elements in a CSV File","metadata":{"Phase":"Architecture and Design","Description":"Certain implementations of spreadsheet software might disallow formulas from executing if the file is untrusted, or if the file is not authored by the current user."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01843","_id":"cwe_mitigation/cwe_mitigation_01843","_rev":"_dVfOTUS--1","original_id":"1239","name":"Improper Zeroization of Hardware Register","metadata":{"Phase":"Architecture and Design","Description":"Every register potentially containing sensitive information must have a policy specifying how and when information is cleared, in addition to clarifying if it is the responsibility of the hardware logic or IP user to initiate the zeroization procedure at the appropriate time."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01844","_id":"cwe_mitigation/cwe_mitigation_01844","_rev":"_dVfOTUS--2","original_id":"1240","name":"Use of a Cryptographic Primitive with a Risky Implementation","metadata":{"Phase":"Requirements","Description":"\n\t\t      Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-1226].\n\t\t  "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01845","_id":"cwe_mitigation/cwe_mitigation_01845","_rev":"_dVfOTUS--3","original_id":"1240","name":"Use of a Cryptographic Primitive with a Risky Implementation","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t      Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-1226].\n\t\t  "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01846","_id":"cwe_mitigation/cwe_mitigation_01846","_rev":"_dVfOTUS--4","original_id":"1240","name":"Use of a Cryptographic Primitive with a Risky Implementation","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t      Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. As with all cryptographic mechanisms, the source code should be available for analysis. If the algorithm may be compromised when attackers find out how it works, then it is especially weak.\n\t\t  "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01847","_id":"cwe_mitigation/cwe_mitigation_01847","_rev":"_dVfOTUS--5","original_id":"1240","name":"Use of a Cryptographic Primitive with a Risky Implementation","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t      Try not to use cryptographic algorithms in novel ways or with new modes of operation even when you \"know\" it is secure. For example, using SHA-2 chaining to create a 1-time pad for encryption might sound like a good idea, but one should not do this.\n\t\t  "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01848","_id":"cwe_mitigation/cwe_mitigation_01848","_rev":"_dVfOTUS--6","original_id":"1240","name":"Use of a Cryptographic Primitive with a Risky Implementation","metadata":{"Phase":"Architecture and Design","Description":"Ensure that the design can replace one cryptographic primitive or algorithm with another in the next generation (\"cryptographic agility\"). Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software; design the hardware at a replaceable block level."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01849","_id":"cwe_mitigation/cwe_mitigation_01849","_rev":"_dVfOTUS--7","original_id":"1240","name":"Use of a Cryptographic Primitive with a Risky Implementation","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t      Do not use outdated or non-compliant cryptography algorithms. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong [REF-267].\n\t\t  "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01850","_id":"cwe_mitigation/cwe_mitigation_01850","_rev":"_dVfOTUS--8","original_id":"1240","name":"Use of a Cryptographic Primitive with a Risky Implementation","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t      Do not use a linear-feedback shift register (LFSR) or other legacy methods as a substitute for an accepted and standard Random Number Generator.\n\t\t  "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01851","_id":"cwe_mitigation/cwe_mitigation_01851","_rev":"_dVfOTUS--9","original_id":"1240","name":"Use of a Cryptographic Primitive with a Risky Implementation","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t      Do not use a checksum as a substitute for a cryptographically generated hash.\n\t\t  "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01852","_id":"cwe_mitigation/cwe_mitigation_01852","_rev":"_dVfOTUS-_-","original_id":"1240","name":"Use of a Cryptographic Primitive with a Risky Implementation","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t      Use a vetted cryptographic library or framework. Industry-standard implementations will save development time and are more likely to avoid errors that can occur during implementation of cryptographic algorithms. However, the library/framework could be used incorrectly during implementation.\n\t\t  "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01853","_id":"cwe_mitigation/cwe_mitigation_01853","_rev":"_dVfOTUS-__","original_id":"1240","name":"Use of a Cryptographic Primitive with a Risky Implementation","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t      When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for the prevention of common attacks.\n\t\t  "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01854","_id":"cwe_mitigation/cwe_mitigation_01854","_rev":"_dVfOTUS-_A","original_id":"1240","name":"Use of a Cryptographic Primitive with a Risky Implementation","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t      Do not store keys in areas accessible to untrusted agents. Carefully manage and protect the cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography algorithm is irrelevant.\n\t\t  "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01859","_id":"cwe_mitigation/cwe_mitigation_01859","_rev":"_dVfOTUS-_B","original_id":"1241","name":"Use of Predictable Algorithm in Random Number Generator","metadata":{"Phase":"Architecture and Design","Description":"A true random number generator should be specified for cryptographic algorithms."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01860","_id":"cwe_mitigation/cwe_mitigation_01860","_rev":"_dVfOTUW---","original_id":"1241","name":"Use of Predictable Algorithm in Random Number Generator","metadata":{"Phase":"Implementation","Description":"A true random number generator should be implemented for cryptographic algorithms."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01861","_id":"cwe_mitigation/cwe_mitigation_01861","_rev":"_dVfOTUW--_","original_id":"1242","name":"Inclusion of Undocumented Features or Chicken Bits","metadata":{"Phase":"Architecture and Design","Description":"\n                        The implementation of chicken bits in a released product is highly discouraged. If implemented at all, ensure that they are disabled in production devices. All interfaces to a device should be documented.                     \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01862","_id":"cwe_mitigation/cwe_mitigation_01862","_rev":"_dVfOTUW--A","original_id":"1243","name":"Sensitive Non-Volatile Information Not Protected During Debug","metadata":{"Phase":"Architecture and Design","Description":"\n                        Disable access to security-sensitive information stored in fuses directly and also reflected from  temporary storage locations when in debug mode.                     \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01863","_id":"cwe_mitigation/cwe_mitigation_01863","_rev":"_dVfOTUW--B","original_id":"1244","name":"Internal Asset Exposed to Unsafe Debug Access Level or State","metadata":{"Phase":"Architecture and Design","Description":"\n                    For security-sensitive assets accessible over debug/test interfaces, only allow trusted agents.\n                  "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01864","_id":"cwe_mitigation/cwe_mitigation_01864","_rev":"_dVfOTUW--C","original_id":"1244","name":"Internal Asset Exposed to Unsafe Debug Access Level or State","metadata":{"Phase":"Architecture and Design","Description":"Apply blinding [REF-1219] or masking techniques in strategic areas."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01865","_id":"cwe_mitigation/cwe_mitigation_01865","_rev":"_dVfOTUW--D","original_id":"1244","name":"Internal Asset Exposed to Unsafe Debug Access Level or State","metadata":{"Phase":"Implementation","Description":"Add shielding or tamper-resistant protections to the device, which increases the difficulty and cost for accessing debug/test interfaces."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01867","_id":"cwe_mitigation/cwe_mitigation_01867","_rev":"_dVfOTUW--E","original_id":"1245","name":"Improper Finite State Machines (FSMs) in Hardware Logic","metadata":{"Phase":"Architecture and Design","Description":"Define all possible states and handle all unused states through default statements. Ensure that system defaults to a secure state."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01868","_id":"cwe_mitigation/cwe_mitigation_01868","_rev":"_dVfOTUW--F","original_id":"1246","name":"Improper Write Handling in Limited-write Non-Volatile Memories","metadata":{"Phase":"Architecture and Design","Description":"\n                        Include secure wear leveling algorithms and ensure they may not be bypassed.                     \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01869","_id":"cwe_mitigation/cwe_mitigation_01869","_rev":"_dVfOTUW--G","original_id":"1247","name":"Improper Protection Against Voltage and Clock Glitches","metadata":{"Phase":"Architecture and Design","Description":"\n            At the circuit-level, using Tunable Replica Circuits (TRCs) or special flip-flops such as Razor flip-flops helps mitigate glitch attacks. Working at the SoC or platform base, level sensors may be implemented to detect glitches. Implementing redundancy in security-sensitive code (e.g., where checks are performed)also can help with mitigation of glitch attacks.           \n          "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01874","_id":"cwe_mitigation/cwe_mitigation_01874","_rev":"_dVfOTUW--H","original_id":"1248","name":"Semiconductor Defects in Hardware Logic with Security-Sensitive Implications","metadata":{"Phase":"Testing","Description":"\n                        While semiconductor-manufacturing companies implement several mechanisms to continuously improve the semiconductor manufacturing process to ensure reduction of defects, some defects can only be fixed after manufacturing. Post-manufacturing testing of silicon die is critical. Fault models such as stuck-at-0 or stuck-at-1 must be used to develop post-manufacturing test cases and achieve good coverage. Once the silicon packaging is done, extensive post-silicon testing must be performed to ensure that hardware logic implementing security functionalities is defect-free.                     \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01875","_id":"cwe_mitigation/cwe_mitigation_01875","_rev":"_dVfOTUW--I","original_id":"1248","name":"Semiconductor Defects in Hardware Logic with Security-Sensitive Implications","metadata":{"Phase":"Operation","Description":"\n                        Operating the hardware outside device specification, such as at extremely high temperatures, voltage, etc., accelerates semiconductor degradation and results in defects.  When these defects manifest as faults in security-critical, hardware modules, it results in compromise of security guarantees. Thus, operating the device within the specification is important.                     \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01876","_id":"cwe_mitigation/cwe_mitigation_01876","_rev":"_dVfOTUW--J","original_id":"1249","name":"Application-Level Admin Tool with Inconsistent View of Underlying Operating System","metadata":{"Phase":"Architecture and Design","Description":"\n                        Ensure that the admin tool refreshes its model of the underlying OS on a regular basis, and note any inconsistencies with configuration files or other data sources that are expected to have the same data.                     \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01877","_id":"cwe_mitigation/cwe_mitigation_01877","_rev":"_dVfOTUW--K","original_id":"1251","name":"Mirrored Regions with Different Values","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t\t\t\t\tWhenever there are multiple, physically different copies of the same value that might change and the process to update them is not instantaneous and atomic, it is impossible to assert that the original and shadow copies will always be in sync - there will always be a time period when they are out of sync. To mitigate the consequential risk, the recommendations essentially are:\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\tMake this out-of-sync time period as small as possible, and\n\t\t\t\t\t\t\t\t\tMake the update process as robust as possible.\n\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01878","_id":"cwe_mitigation/cwe_mitigation_01878","_rev":"_dVfOTUW--L","original_id":"1252","name":"CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations","metadata":{"Phase":"Architecture and Design","Description":"\n                        Implement a dedicated bit that can be leveraged by the Operating System to mark data areas as non-executable. If such a bit is not available in the CPU, implement MMU/MPU (memory management unit / memory protection unit).                     \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01879","_id":"cwe_mitigation/cwe_mitigation_01879","_rev":"_dVfOTUW--M","original_id":"1252","name":"CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations","metadata":{"Phase":"Integration","Description":"\n                        If MMU/MPU are not available, then the firewalls need to be implemented in the SoC interconnect to mimic the write-exclusivity operation.                     \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01880","_id":"cwe_mitigation/cwe_mitigation_01880","_rev":"_dVfOTUW--N","original_id":"1253","name":"Incorrect Selection of Fuse Values","metadata":{"Phase":"Architecture and Design","Description":"Logic should be designed in a way that blown fuses do not put the product into an insecure state that can be leveraged by an attacker.\n        "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01881","_id":"cwe_mitigation/cwe_mitigation_01881","_rev":"_dVfOTUW--O","original_id":"1254","name":"Incorrect Comparison Logic Granularity","metadata":{"Phase":"Implementation","Description":"\n                 The hardware designer should ensure that comparison logic is implemented so as to compare in one operation instead in smaller chunks.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01882","_id":"cwe_mitigation/cwe_mitigation_01882","_rev":"_dVfOTUW--P","original_id":"1255","name":"Comparison Logic is Vulnerable to Power Side-Channel Attacks","metadata":{"Phase":"Architecture and Design","Description":"The design phase must consider each check of a security token against a standard and the amount of power consumed during the check of a good token versus a bad token. The alternative is an all at once check where a retry counter is incremented PRIOR to the check."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01883","_id":"cwe_mitigation/cwe_mitigation_01883","_rev":"_dVfOTUW--Q","original_id":"1255","name":"Comparison Logic is Vulnerable to Power Side-Channel Attacks","metadata":{"Phase":"Architecture and Design","Description":"Another potential mitigation is to parallelize shifting of secret data (see example 2 below). Note that the wider the bus the more effective the result."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01884","_id":"cwe_mitigation/cwe_mitigation_01884","_rev":"_dVfOTUe---","original_id":"1255","name":"Comparison Logic is Vulnerable to Power Side-Channel Attacks","metadata":{"Phase":"Architecture and Design","Description":"An additional potential mitigation is to add random data to each crypto operation then subtract it out afterwards. This is highly effective but costly in performance, area, and power consumption. It also requires a random number generator."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01885","_id":"cwe_mitigation/cwe_mitigation_01885","_rev":"_dVfOTUe--_","original_id":"1255","name":"Comparison Logic is Vulnerable to Power Side-Channel Attacks","metadata":{"Phase":"Implementation","Description":"If the architecture is unable to prevent the attack, using filtering components may reduce the ability to implement an attack, however, consideration must be given to the physical removal of the filter elements."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01886","_id":"cwe_mitigation/cwe_mitigation_01886","_rev":"_dVfOTUe--A","original_id":"1255","name":"Comparison Logic is Vulnerable to Power Side-Channel Attacks","metadata":{"Phase":"Integration","Description":"During integration, avoid use of a single secret for an extended period (e.g. frequent key updates). This limits the amount of data compromised but at the cost of complexity of use."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01887","_id":"cwe_mitigation/cwe_mitigation_01887","_rev":"_dVfOTUe--B","original_id":"1256","name":"Improper Restriction of Software Interfaces to Hardware Features","metadata":{"Phase":"Architecture and Design","Description":"\n                        Ensure proper access control mechanisms protect software-controllable features altering physical operating conditions such as clock frequency and voltage.                     \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01890","_id":"cwe_mitigation/cwe_mitigation_01890","_rev":"_dVfOTUe--C","original_id":"1257","name":"Improper Access Control Applied to Mirrored or Aliased Memory Regions","metadata":{"Phase":"Architecture and Design","Description":"The checks should be applied for consistency access rights between primary memory regions and any mirrored or aliased memory regions. If different memory protection units (MPU) are protecting the aliased regions, their protected range definitions and policies should be synchronized."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01891","_id":"cwe_mitigation/cwe_mitigation_01891","_rev":"_dVfOTUe--D","original_id":"1257","name":"Improper Access Control Applied to Mirrored or Aliased Memory Regions","metadata":{"Phase":"Architecture and Design","Description":"The controls that allow enabling memory aliases or changing the size of mapped memory regions should only be programmable by trusted software components."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01892","_id":"cwe_mitigation/cwe_mitigation_01892","_rev":"_dVfOTUe--E","original_id":"1258","name":"Exposure of Sensitive System Information Due to Uncleared Debug Information","metadata":{"Phase":"Architecture and Design","Description":"\n                 Whenever debug mode is enabled, all registers containing sensitive assets must be cleared.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01893","_id":"cwe_mitigation/cwe_mitigation_01893","_rev":"_dVfOTUe--F","original_id":"1259","name":"Improper Restriction of Security Token Assignment","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tSecurity Token assignment review checks for design inconsistency and common weaknesses.\n\t\t\t\t\t\t\tSecurity-Token definition and programming flow is tested in both pre-silicon and post-silicon testing.\n\t\t\t\t\t\t\n\t\t\t\t\t"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01894","_id":"cwe_mitigation/cwe_mitigation_01894","_rev":"_dVfOTUe--G","original_id":"1260","name":"Improper Handling of Overlap Between Protected Memory Ranges","metadata":{"Phase":"Architecture and Design","Description":"\n                   Ensure that memory regions are isolated as intended and that access control (read/write) policies are used by hardware to protect privileged software.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01895","_id":"cwe_mitigation/cwe_mitigation_01895","_rev":"_dVfOTUe--H","original_id":"1260","name":"Improper Handling of Overlap Between Protected Memory Ranges","metadata":{"Phase":"Implementation","Description":"\n                 For all of the programmable memory protection regions, the memory protection unit (MPU) design can define a priority scheme.\n                 For example: if three memory regions can be programmed (Region_0, Region_1, and Region_2), the design can enforce a priority scheme, such that, if a system address is within multiple regions, then the region with the lowest ID takes priority and the access-control policy of that region will be applied.  In some MPU designs, the priority scheme can also be programmed by trusted software.\n                 Hardware logic or trusted firmware can also check for region definitions and block programming of memory regions with overlapping addresses. \n                 The memory-access-control-check filter can also be designed to apply a policy filter to all of the overlapping ranges, i.e., if an address is within Region_0 and Region_1, then access to this address is only granted if both Region_0 and Region_1 policies allow the access.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01897","_id":"cwe_mitigation/cwe_mitigation_01897","_rev":"_dVfOTUe--I","original_id":"1261","name":"Improper Handling of Single Event Upsets","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t\t\t\t\tImplement triple-modular redundancy around security-sensitive modules.\n\t\t\t\t\t"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01898","_id":"cwe_mitigation/cwe_mitigation_01898","_rev":"_dVfOTUe--J","original_id":"1261","name":"Improper Handling of Single Event Upsets","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t\t\t\t\tSEUs mostly affect SRAMs.  For SRAMs storing security-critical data, implement Error-Correcting-Codes (ECC) and Address Interleaving.\n\t\t\t\t\t"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01899","_id":"cwe_mitigation/cwe_mitigation_01899","_rev":"_dVfOTUe--K","original_id":"1262","name":"Improper Access Control for Register Interface","metadata":{"Phase":"Architecture and Design","Description":"Design proper policies for hardware register access from software."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01900","_id":"cwe_mitigation/cwe_mitigation_01900","_rev":"_dVfOTUe--L","original_id":"1262","name":"Improper Access Control for Register Interface","metadata":{"Phase":"Implementation","Description":"Ensure that access control policies for register access are implemented in accordance with the specified design."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01908","_id":"cwe_mitigation/cwe_mitigation_01908","_rev":"_dVfOTUe--M","original_id":"1263","name":"Improper Physical Access Control","metadata":{"Phase":"Architecture and Design","Description":"Specific protection requirements depend strongly on contextual factors including the level of acceptable risk associated with compromise to the product's protection mechanism. Designers could incorporate anti-tampering measures that protect against or detect when the product has been tampered with."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01909","_id":"cwe_mitigation/cwe_mitigation_01909","_rev":"_dVfOTUe--N","original_id":"1263","name":"Improper Physical Access Control","metadata":{"Phase":"Testing","Description":"The testing phase of the lifecycle should establish a method for determining whether the protection mechanism is sufficient to prevent unauthorized access."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01910","_id":"cwe_mitigation/cwe_mitigation_01910","_rev":"_dVfOTUe--O","original_id":"1263","name":"Improper Physical Access Control","metadata":{"Phase":"Manufacturing","Description":"Ensure that all protection mechanisms are fully activated at the time of manufacturing and distribution."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01911","_id":"cwe_mitigation/cwe_mitigation_01911","_rev":"_dVfOTUe--P","original_id":"1264","name":"Hardware Logic with Insecure De-Synchronization between Control and Data Channels","metadata":{"Phase":"Architecture and Design","Description":"\n                 Thoroughly verify the data routing logic to ensure that any error handling or security checks effectively block illegal dataflows.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01912","_id":"cwe_mitigation/cwe_mitigation_01912","_rev":"_dVfOTUe--Q","original_id":"1265","name":"Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls","metadata":{"Phase":"Architecture and Design","Description":"When architecting a system that will execute untrusted code in response to events, consider executing the untrusted event handlers asynchronously (asynchronous message passing) as opposed to executing them synchronously at the time each event fires. The untrusted code should execute at the start of the next iteration of the thread’s message loop. In this way, calls into non-reentrant code are strictly serialized, so that each operation completes fully before the next operation begins. Special attention must be paid to all places where type coercion may result in script execution. Performing all needed coercions at the very beginning of an operation can help reduce the chance of operations executing at unexpected junctures."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01913","_id":"cwe_mitigation/cwe_mitigation_01913","_rev":"_dVfOTUe--R","original_id":"1265","name":"Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls","metadata":{"Phase":"Implementation","Description":"Make sure the code (e.g., function or class) in question is reentrant by not leveraging non-local data, not modifying its own code, and not calling other non-reentrant code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01914","_id":"cwe_mitigation/cwe_mitigation_01914","_rev":"_dVfOTUi---","original_id":"1266","name":"Improper Scrubbing of Sensitive Data from Decommissioned Device","metadata":{"Phase":"Architecture and Design","Description":"\n                 Functionality to completely scrub data from a product at the conclusion of its lifecycle should be part of the design phase. Trying to add this function on top of an existing architecture could lead to incomplete removal of sensitive information/data.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01915","_id":"cwe_mitigation/cwe_mitigation_01915","_rev":"_dVfOTUi--_","original_id":"1266","name":"Improper Scrubbing of Sensitive Data from Decommissioned Device","metadata":{"Phase":"Policy","Description":"\n                 The manufacturer should describe the location(s) where sensitive data is stored and the policies and procedures for its removal. This information may be conveyed, for example, in an Administrators Guide or a Statement of Volatility.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01916","_id":"cwe_mitigation/cwe_mitigation_01916","_rev":"_dVfOTUi--A","original_id":"1266","name":"Improper Scrubbing of Sensitive Data from Decommissioned Device","metadata":{"Phase":"Implementation","Description":"\n                 If the capability to wipe sensitive data isn't built-in, the manufacturer may need to provide a utility to scrub sensitive data from storage if that data is located in a place which is non-accessible by the administrator. One example of this could be when sensitive data is stored on an EEPROM for which there is no user/admin interface provided by the system.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01917","_id":"cwe_mitigation/cwe_mitigation_01917","_rev":"_dVfOTUi--B","original_id":"1267","name":"Policy Uses Obsolete Encoding","metadata":{"Phase":"Architecture and Design","Description":"\n      Security Token Decoders should be reviewed for design inconsistency and common weaknesses.\n      Access and programming flows should be tested in both pre-silicon and post-silicon testing.\n     "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01918","_id":"cwe_mitigation/cwe_mitigation_01918","_rev":"_dVfOTUi--C","original_id":"1268","name":"Policy Privileges are not Assigned Consistently Between Control and Data Agents","metadata":{"Phase":"Architecture and Design","Description":"Access-control-policy definition and programming flow must be sufficiently tested in pre-silicon and post-silicon testing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01919","_id":"cwe_mitigation/cwe_mitigation_01919","_rev":"_dVfOTUi--D","original_id":"1269","name":"Product Released in Non-Release Configuration","metadata":{"Phase":"Implementation","Description":"Ensure that there exists a marker for denoting the Manufacturing Complete stage and that the Manufacturing Complete marker gets updated at the Manufacturing Complete stage (i.e., the Manufacturing Complete fuse gets blown)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01920","_id":"cwe_mitigation/cwe_mitigation_01920","_rev":"_dVfOTUi--E","original_id":"1269","name":"Product Released in Non-Release Configuration","metadata":{"Phase":"Integration","Description":"Ensure that there exists a marker for denoting the Manufacturing Complete stage and that the Manufacturing Complete marker gets updated at the Manufacturing Complete stage (i.e., the Manufacturing Complete fuse gets blown)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01921","_id":"cwe_mitigation/cwe_mitigation_01921","_rev":"_dVfOTUi--F","original_id":"1269","name":"Product Released in Non-Release Configuration","metadata":{"Phase":"Manufacturing","Description":"Ensure that there exists a marker for denoting the Manufacturing Complete stage and that the Manufacturing Complete marker gets updated at the Manufacturing Complete stage (i.e., the Manufacturing Complete fuse gets blown)."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01922","_id":"cwe_mitigation/cwe_mitigation_01922","_rev":"_dVfOTUi--G","original_id":"1270","name":"Generation of Incorrect Security Tokens","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tGeneration of Security Tokens should be reviewed for design inconsistency and common weaknesses.\n\t\t\t\t\t\t\tSecurity-Token definition and programming flow should be tested in pre-silicon and post-silicon testing.\n\t\t\t\t\t\t\n\t\t\t\t\t"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01923","_id":"cwe_mitigation/cwe_mitigation_01923","_rev":"_dVfOTUi--H","original_id":"1271","name":"Uninitialized Value on Reset for Registers Holding Security Settings","metadata":{"Phase":"Implementation","Description":"Design checks should be performed to identify any uninitialized flip-flops used for security-critical functions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01924","_id":"cwe_mitigation/cwe_mitigation_01924","_rev":"_dVfOTUi--I","original_id":"1271","name":"Uninitialized Value on Reset for Registers Holding Security Settings","metadata":{"Phase":"Architecture and Design","Description":"All registers holding security-critical information should be set to a specific value on reset."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01925","_id":"cwe_mitigation/cwe_mitigation_01925","_rev":"_dVfOTUi--J","original_id":"1272","name":"Sensitive Information Uncleared Before Debug/Power State Transition","metadata":{"Phase":"Architecture and Design","Description":"During state transitions, information not needed in the next state should be removed before the transition to the next state."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01927","_id":"cwe_mitigation/cwe_mitigation_01927","_rev":"_dVfOTUi--K","original_id":"1273","name":"Device Unlock Credential Sharing","metadata":{"Phase":"Integration","Description":"Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01928","_id":"cwe_mitigation/cwe_mitigation_01928","_rev":"_dVfOTUi--L","original_id":"1273","name":"Device Unlock Credential Sharing","metadata":{"Phase":"Manufacturing","Description":"Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01929","_id":"cwe_mitigation/cwe_mitigation_01929","_rev":"_dVfOTUi--M","original_id":"1274","name":"Improper Access Control for Volatile Memory Containing Boot Code","metadata":{"Phase":"Architecture and Design","Description":"Ensure that the design of volatile-memory protections is enough to prevent modification from an adversary or untrusted code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01930","_id":"cwe_mitigation/cwe_mitigation_01930","_rev":"_dVfOTUi--N","original_id":"1274","name":"Improper Access Control for Volatile Memory Containing Boot Code","metadata":{"Phase":"Testing","Description":"Test the volatile-memory protections to ensure they are safe from modification or untrusted code."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01933","_id":"cwe_mitigation/cwe_mitigation_01933","_rev":"_dVfOTUi--O","original_id":"1275","name":"Sensitive Cookie with Improper SameSite Attribute","metadata":{"Phase":"Implementation","Description":"Set the SameSite attribute of a sensitive cookie to 'Lax' or 'Strict'. This instructs the browser to apply this cookie only to same-domain requests, which provides a good Defense in Depth against CSRF attacks. When the 'Lax' value is in use, cookies are also sent for top-level cross-domain navigation via HTTP GET, HEAD, OPTIONS, and TRACE methods, but not for other HTTP methods that are more like to cause side-effects of state mutation."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01934","_id":"cwe_mitigation/cwe_mitigation_01934","_rev":"_dVfOTUi--P","original_id":"1276","name":"Hardware Child Block Incorrectly Connected to Parent System","metadata":{"Phase":"Testing","Description":"System-level verification may be used to ensure that components are correctly connected and that design security requirements are not violated due to interactions between various IP blocks."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01935","_id":"cwe_mitigation/cwe_mitigation_01935","_rev":"_dVfOTUi--Q","original_id":"1277","name":"Firmware Not Updateable","metadata":{"Phase":"Requirements","Description":"Specify requirements to provide the ability to update the firmware."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01936","_id":"cwe_mitigation/cwe_mitigation_01936","_rev":"_dVfOTUi--R","original_id":"1277","name":"Firmware Not Updateable","metadata":{"Phase":"Architecture and Design","Description":"Design the device to allow for updating the firmware."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01937","_id":"cwe_mitigation/cwe_mitigation_01937","_rev":"_dVfOTUi--S","original_id":"1277","name":"Firmware Not Updateable","metadata":{"Phase":"Implementation","Description":"Implement the necessary functionality to allow the firmware to be updated."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01941","_id":"cwe_mitigation/cwe_mitigation_01941","_rev":"_dVfOTUi--T","original_id":"1278","name":"Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques","metadata":{"Phase":"Architecture and Design","Description":"The cost of secret extraction via IC reverse engineering should outweigh the potential value of the secrets being extracted. Threat model and value of secrets should be used to choose the technology used to safeguard those secrets. Examples include IC camouflaging and obfuscation, tamper-proof packaging, active shielding, and physical tampering detection information erasure."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01942","_id":"cwe_mitigation/cwe_mitigation_01942","_rev":"_dVfOTUi--U","original_id":"1279","name":"Cryptographic Operations are run Before Supporting Units are Ready","metadata":{"Phase":"Architecture and Design","Description":"Best practices should be used to design cryptographic systems."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01943","_id":"cwe_mitigation/cwe_mitigation_01943","_rev":"_dVfOTUi--V","original_id":"1279","name":"Cryptographic Operations are run Before Supporting Units are Ready","metadata":{"Phase":"Implementation","Description":"Continuously ensuring that cryptographic inputs are supplying valid information is necessary to ensure that the encrypted output is secure. "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01944","_id":"cwe_mitigation/cwe_mitigation_01944","_rev":"_dVfOTUi--W","original_id":"1280","name":"Access Control Check Implemented After Asset is Accessed","metadata":{"Phase":"Implementation","Description":"Implement the access control check first. Access should only be given to asset if agent is authorized. "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01945","_id":"cwe_mitigation/cwe_mitigation_01945","_rev":"_dVfOTUi--X","original_id":"1281","name":"Sequence of Processor Instructions Leads to Unexpected Behavior","metadata":{"Phase":"Testing","Description":"Implement a rigorous testing strategy that incorporates randomization to explore instruction sequences that are unlikely to appear in normal workloads in order to identify halt and catch fire instruction sequences."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01946","_id":"cwe_mitigation/cwe_mitigation_01946","_rev":"_dVfOTUi--Y","original_id":"1281","name":"Sequence of Processor Instructions Leads to Unexpected Behavior","metadata":{"Phase":"Patching and Maintenance","Description":"Patch operating system to avoid running Halt and Catch Fire type sequences or to mitigate the damage caused by unexpected behavior.  See [REF-1108]."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01947","_id":"cwe_mitigation/cwe_mitigation_01947","_rev":"_dVfOTUi--Z","original_id":"1282","name":"Assumed-Immutable Data is Stored in Writable Memory","metadata":{"Phase":"Implementation","Description":"All immutable code or data should be programmed into ROM or write-once memory."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01948","_id":"cwe_mitigation/cwe_mitigation_01948","_rev":"_dVfOTUi--a","original_id":"1283","name":"Mutable Attestation or Measurement Reporting Data","metadata":{"Phase":"Architecture and Design","Description":"\n                 Measurement data should be stored in registers that are read-only or otherwise have access controls that prevent modification by an untrusted agent.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01949","_id":"cwe_mitigation/cwe_mitigation_01949","_rev":"_dVfOTUi--b","original_id":"1284","name":"Improper Validation of Specified Quantity in Input","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01950","_id":"cwe_mitigation/cwe_mitigation_01950","_rev":"_dVfOTUi--c","original_id":"1285","name":"Improper Validation of Specified Index, Position, or Offset in Input","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01951","_id":"cwe_mitigation/cwe_mitigation_01951","_rev":"_dVfOTUi--d","original_id":"1286","name":"Improper Validation of Syntactic Correctness of Input","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01952","_id":"cwe_mitigation/cwe_mitigation_01952","_rev":"_dVfOTUi--e","original_id":"1287","name":"Improper Validation of Specified Type of Input","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01953","_id":"cwe_mitigation/cwe_mitigation_01953","_rev":"_dVfOTUi--f","original_id":"1288","name":"Improper Validation of Consistency within Input","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01954","_id":"cwe_mitigation/cwe_mitigation_01954","_rev":"_dVfOTUi--g","original_id":"1289","name":"Improper Validation of Unsafe Equivalence in Input","metadata":{"Phase":"Implementation","Description":"\n                  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.\n                  When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, \"boat\" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as \"red\" or \"blue.\"\n                  Do not rely exclusively on looking for malicious or malformed inputs.  This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.\n               "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01955","_id":"cwe_mitigation/cwe_mitigation_01955","_rev":"_dVfOTUi--h","original_id":"1290","name":"Incorrect Decoding of Security Identifiers ","metadata":{"Phase":"Architecture and Design","Description":"Security identifier decoders must be reviewed for design consistency and common weaknesses."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01956","_id":"cwe_mitigation/cwe_mitigation_01956","_rev":"_dVfOTUi--i","original_id":"1290","name":"Incorrect Decoding of Security Identifiers ","metadata":{"Phase":"Implementation","Description":"Access and programming flows must be tested in pre-silicon and post-silicon testing in order to check for this weakness."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01957","_id":"cwe_mitigation/cwe_mitigation_01957","_rev":"_dVfOTUi--j","original_id":"1291","name":"Public Key Re-Use for Signing both Debug and Production Code","metadata":{"Phase":"Implementation","Description":"Use different keys for Production and Debug"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01960","_id":"cwe_mitigation/cwe_mitigation_01960","_rev":"_dVfOTUi--k","original_id":"1292","name":"Incorrect Conversion of Security Identifiers","metadata":{"Phase":"Architecture and Design","Description":"Security identifier decoders must be reviewed for design inconsistency and common weaknesses."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01961","_id":"cwe_mitigation/cwe_mitigation_01961","_rev":"_dVfOTUi--l","original_id":"1292","name":"Incorrect Conversion of Security Identifiers","metadata":{"Phase":"Implementation","Description":"Access and programming flows must be tested in pre-silicon and post-silicon testing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01962","_id":"cwe_mitigation/cwe_mitigation_01962","_rev":"_dVfOTUi--m","original_id":"1293","name":"Missing Source Correlation of Multiple Independent Data","metadata":{"Phase":"Requirements","Description":"Design system to use a Practical Byzantine fault method, to request information from multiple sources to verify the data and report on potentially compromised information sources."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01963","_id":"cwe_mitigation/cwe_mitigation_01963","_rev":"_dVfOTUi--n","original_id":"1293","name":"Missing Source Correlation of Multiple Independent Data","metadata":{"Phase":"Implementation","Description":"Failure to use a Practical Byzantine fault method when requesting data. Lack of place to report potentially compromised information sources. Relying on non-independent information sources for integrity checking. Failure to report information sources that respond in the minority to incident response procedures."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01964","_id":"cwe_mitigation/cwe_mitigation_01964","_rev":"_dVfOTUi--o","original_id":"1294","name":"Insecure Security Identifier Mechanism","metadata":{"Phase":"Architecture and Design","Description":"Security Identifier Decoders must be reviewed for design inconsistency and common weaknesses."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01965","_id":"cwe_mitigation/cwe_mitigation_01965","_rev":"_dVfOTUi--p","original_id":"1294","name":"Insecure Security Identifier Mechanism","metadata":{"Phase":"Implementation","Description":"Access and programming flows must be tested in pre-silicon and post-silicon testing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01966","_id":"cwe_mitigation/cwe_mitigation_01966","_rev":"_dVfOTUi--q","original_id":"1295","name":"Debug Messages Revealing Unnecessary Information","metadata":{"Phase":"Implementation","Description":"Ensure that a debug message does not reveal any unnecessary information during the debug process for the intended response."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01967","_id":"cwe_mitigation/cwe_mitigation_01967","_rev":"_dVfOTUi--r","original_id":"1296","name":"Incorrect Chaining or Granularity of Debug Components","metadata":{"Phase":"Implementation","Description":"Ensure that debug components are properly chained and their granularity is maintained at different authentication levels."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01970","_id":"cwe_mitigation/cwe_mitigation_01970","_rev":"_dVfOTUi--s","original_id":"1297","name":"Unprotected Confidential Information on Device is Accessible by OSAT Vendors","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t\t\t\t\n\t\t\t\t\t\t•\tEnsure that when an OSAT vendor is allowed to access test interfaces necessary for preproduction and returned parts, the vendor only pulls the minimal information necessary. Also, architect the product in such a way that, when an “unlock device” request comes, it only unlocks that specific part and not all the parts for that product line.\n\t\t\t\t\t\t•\tEnsure that the product’s non-volatile memory (NVM) is scrubbed of all confidential information and secrets before handing it over to an OSAT.\n\t\t\t\t\t\t•\tArrange to secure all communication between an OSAT facility and the chipmaker.\n\t\t\t\t\t\t\n\t\t\t\t"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01973","_id":"cwe_mitigation/cwe_mitigation_01973","_rev":"_dVfOTUi--t","original_id":"1298","name":"Hardware Logic Contains Race Conditions","metadata":{"Phase":"Architecture and Design","Description":"Adopting design practices that encourage designers to recognize and eliminate race conditions, such as Karnaugh maps, could result in the decrease in occurrences of race conditions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01974","_id":"cwe_mitigation/cwe_mitigation_01974","_rev":"_dVfOTUi--u","original_id":"1298","name":"Hardware Logic Contains Race Conditions","metadata":{"Phase":"Implementation","Description":"Logic redundancy can be implemented along security critical paths to prevent race conditions. To avoid metastability, it is a good practice in general to default to a secure state in which access is not given to untrusted agents."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01975","_id":"cwe_mitigation/cwe_mitigation_01975","_rev":"_dVfOTUi--v","original_id":"1299","name":"Missing Protection Mechanism for Alternate Hardware Interface","metadata":{"Phase":"Requirements","Description":"Protect assets from accesses against all potential interfaces and alternate paths. "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01976","_id":"cwe_mitigation/cwe_mitigation_01976","_rev":"_dVfOTUi--w","original_id":"1299","name":"Missing Protection Mechanism for Alternate Hardware Interface","metadata":{"Phase":"Architecture and Design","Description":"Protect assets from accesses against all potential interfaces and alternate paths. "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01977","_id":"cwe_mitigation/cwe_mitigation_01977","_rev":"_dVfOTUi--x","original_id":"1299","name":"Missing Protection Mechanism for Alternate Hardware Interface","metadata":{"Phase":"Implementation","Description":"Protect assets from accesses against all potential interfaces and alternate paths. "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01978","_id":"cwe_mitigation/cwe_mitigation_01978","_rev":"_dVfOTUi--y","original_id":"1300","name":"Improper Protection of Physical Side Channels","metadata":{"Phase":"Architecture and Design","Description":"Apply blinding or masking techniques to implementations of cryptographic algorithms."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01979","_id":"cwe_mitigation/cwe_mitigation_01979","_rev":"_dVfOTUi--z","original_id":"1300","name":"Improper Protection of Physical Side Channels","metadata":{"Phase":"Implementation","Description":"Add shielding or tamper-resistant protections to the device to increase the difficulty of obtaining measurements of the side-channel."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01983","_id":"cwe_mitigation/cwe_mitigation_01983","_rev":"_dVfOTUi--0","original_id":"1301","name":"Insufficient or Incomplete Data Removal within Hardware Component","metadata":{"Phase":"Architecture and Design","Description":"Apply blinding or masking techniques to implementations of cryptographic algorithms."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01984","_id":"cwe_mitigation/cwe_mitigation_01984","_rev":"_dVfOTUi--1","original_id":"1301","name":"Insufficient or Incomplete Data Removal within Hardware Component","metadata":{"Phase":"Implementation","Description":"Alter the method of erasure, add protection of media, or destroy the media to protect the data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01985","_id":"cwe_mitigation/cwe_mitigation_01985","_rev":"_dVfOTUi--2","original_id":"1302","name":"Missing Security Identifier","metadata":{"Phase":"Architecture and Design","Description":"Transaction details must be reviewed for design inconsistency and common weaknesses."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01986","_id":"cwe_mitigation/cwe_mitigation_01986","_rev":"_dVfOTUi--3","original_id":"1302","name":"Missing Security Identifier","metadata":{"Phase":"Implementation","Description":"Security identifier definition and programming flow must be tested in pre-silicon and post-silicon testing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01987","_id":"cwe_mitigation/cwe_mitigation_01987","_rev":"_dVfOTUm---","original_id":"1303","name":"Non-Transparent Sharing of Microarchitectural Resources","metadata":{"Phase":"Architecture and Design","Description":"Microarchitectural covert channels can be addressed using a mixture of hardware and software mitigation techniques. These include partitioned caches, new barrier and flush instructions, and disabling high resolution performance counters and timers."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01988","_id":"cwe_mitigation/cwe_mitigation_01988","_rev":"_dVfOTUm--_","original_id":"1303","name":"Non-Transparent Sharing of Microarchitectural Resources","metadata":{"Phase":"Requirements","Description":"Microarchitectural covert channels can be addressed using a mixture of hardware and software mitigation techniques. These include partitioned caches, new barrier and flush instructions, and disabling high resolution performance counters and timers."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01989","_id":"cwe_mitigation/cwe_mitigation_01989","_rev":"_dVfOTUm--A","original_id":"1304","name":"Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation","metadata":{"Phase":"Architecture and Design","Description":"Inside the IP, incorporate integrity checking\n                        on the configuration state via a cryptographic\n                        hash. The hash can be protected inside the IP such as\n                        by storing it in internal registers which never lose\n                        power. Before powering down, the IP performs a hash of\n                        the configuration and saves it in these persistent\n                        registers. Upon restore, the IP performs a hash of the\n                        saved configuration and compares it with the\n                        saved hash. If they do not match, then the IP should\n                        not trust the configuration."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01990","_id":"cwe_mitigation/cwe_mitigation_01990","_rev":"_dVfOTUm--B","original_id":"1304","name":"Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation","metadata":{"Phase":"Integration","Description":"Outside the IP, incorporate integrity checking\n                        of the configuration state via a trusted agent. Before\n                        powering down, the trusted agent performs a hash of the\n                        configuration and saves the hash in persistent storage.\n                        Upon restore, the IP requests the trusted agent\n                        validate its current configuration. If the\n                        configuration hash is invalid, then the IP should not\n                        trust the configuration.\n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01991","_id":"cwe_mitigation/cwe_mitigation_01991","_rev":"_dVfOTUm--C","original_id":"1304","name":"Improperly Preserved Integrity of Hardware Configuration State During a Power Save/Restore Operation","metadata":{"Phase":"Integration","Description":"Outside the IP, incorporate a protected\n                        environment that prevents undetected modification of\n                        the configuration state by untrusted agents. Before\n                        powering down, a trusted agent saves the IP’s\n                        configuration state in this protected location that\n                        only it is privileged to. Upon restore, the trusted\n                        agent loads the saved state into the IP.\n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01992","_id":"cwe_mitigation/cwe_mitigation_01992","_rev":"_dVfOTUm--D","original_id":"1310","name":"Missing Ability to Patch ROM Code","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t\t\t\t  \n\t\t\t\t\t    1. Secure patch support to allow ROM code to be patched at next boot.\n\t\t\t\t\t    2. Support patches that can be programmed in-field or during manufacturing through hardware fuses. This feature can be used to do limited patching of device after shipping or for next batch of silicon devices manufactured without changing the full device ROM.\n\t\t\t\t\t  \n                    "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01993","_id":"cwe_mitigation/cwe_mitigation_01993","_rev":"_dVfOTUm--E","original_id":"1311","name":"Improper Translation of Security Attributes by Fabric Bridge","metadata":{"Phase":"Architecture and Design","Description":"The translation must map signals in such a way that untrusted agents cannot map to trusted agents or vice-versa."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01994","_id":"cwe_mitigation/cwe_mitigation_01994","_rev":"_dVfOTUm--F","original_id":"1311","name":"Improper Translation of Security Attributes by Fabric Bridge","metadata":{"Phase":"Implementation","Description":"Ensure that the translation maps signals in such a way that untrusted agents cannot map to trusted agents or vice-versa."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01995","_id":"cwe_mitigation/cwe_mitigation_01995","_rev":"_dVfOTUm--G","original_id":"1312","name":"Missing Protection for Mirrored Regions in On-Chip Fabric Firewall","metadata":{"Phase":"Architecture and Design","Description":"The fabric firewall should apply the same protections as the original region to the mirrored regions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01996","_id":"cwe_mitigation/cwe_mitigation_01996","_rev":"_dVfOTUm--H","original_id":"1312","name":"Missing Protection for Mirrored Regions in On-Chip Fabric Firewall","metadata":{"Phase":"Implementation","Description":"The fabric firewall should apply the same protections as the original region to the mirrored regions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01998","_id":"cwe_mitigation/cwe_mitigation_01998","_rev":"_dVfOTUm--I","original_id":"1313","name":"Hardware Allows Activation of Test or Debug Logic at Runtime","metadata":{"Phase":"Architecture and Design","Description":"Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_01999","_id":"cwe_mitigation/cwe_mitigation_01999","_rev":"_dVfOTUm--J","original_id":"1313","name":"Hardware Allows Activation of Test or Debug Logic at Runtime","metadata":{"Phase":"Implementation","Description":"Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02000","_id":"cwe_mitigation/cwe_mitigation_02000","_rev":"_dVfOTUm--K","original_id":"1313","name":"Hardware Allows Activation of Test or Debug Logic at Runtime","metadata":{"Phase":"Integration","Description":"Insert restrictions on when the hardware's test or debug features can be activated. For example, during normal operating modes, the hardware's privileged modes that allow access to such features cannot be activated. Configuring the hardware to only enter a test or debug mode within a window of opportunity such as during boot or configuration stage. The result is disablement of such test/debug features and associated modes during normal runtime operations."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02001","_id":"cwe_mitigation/cwe_mitigation_02001","_rev":"_dVfOTUm--L","original_id":"1314","name":"Missing Write Protection for Parametric Data Values","metadata":{"Phase":"Architecture and Design","Description":"Access controls for sensor blocks should ensure that only trusted software is allowed to change threshold limits and sensor parametric data."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02002","_id":"cwe_mitigation/cwe_mitigation_02002","_rev":"_dVfOTUm--M","original_id":"1315","name":"Improper Setting of Bus Controlling Capability in Fabric End-point","metadata":{"Phase":"Architecture and Design","Description":"For responder devices, the register bit in the fabric end-point that enables the bus controlling capability must be set to 0 by default. This bit should not be set during secure-boot flows. Also, writes to this register must be access-protected to prevent malicious modifications to obtain bus-controlling capability."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02003","_id":"cwe_mitigation/cwe_mitigation_02003","_rev":"_dVfOTUm--N","original_id":"1315","name":"Improper Setting of Bus Controlling Capability in Fabric End-point","metadata":{"Phase":"Implementation","Description":"For responder devices, the register bit in the fabric end-point that enables the bus controlling capability must be set to 0 by default. This bit should not be set during secure-boot flows. Also, writes to this register must be access-protected to prevent malicious modifications to obtain bus-controlling capability."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02004","_id":"cwe_mitigation/cwe_mitigation_02004","_rev":"_dVfOTUm--O","original_id":"1315","name":"Improper Setting of Bus Controlling Capability in Fabric End-point","metadata":{"Phase":"System Configuration","Description":"For responder devices, the register bit in the fabric end-point that enables the bus controlling capability must be set to 0 by default. This bit should not be set during secure-boot flows. Also, writes to this register must be access-protected to prevent malicious modifications to obtain bus-controlling capability."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02005","_id":"cwe_mitigation/cwe_mitigation_02005","_rev":"_dVfOTUm--P","original_id":"1316","name":"Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges","metadata":{"Phase":"Architecture and Design","Description":"When architecting the address map of the chip, ensure that protected and unprotected ranges are isolated and do not overlap. When designing, ensure that ranges hardcoded in Register-Transfer Level (RTL) do not overlap."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02006","_id":"cwe_mitigation/cwe_mitigation_02006","_rev":"_dVfOTUm--Q","original_id":"1316","name":"Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges","metadata":{"Phase":"Implementation","Description":"Ranges configured by firmware should not overlap. If overlaps are mandatory because of constraints such as a limited number of registers, then ensure that no assets are present in the overlapped portion."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02007","_id":"cwe_mitigation/cwe_mitigation_02007","_rev":"_dVfOTUm--R","original_id":"1316","name":"Fabric-Address Map Allows Programming of Unwarranted Overlaps of Protected and Unprotected Ranges","metadata":{"Phase":"Testing","Description":"Validate mitigation actions with robust testing."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02010","_id":"cwe_mitigation/cwe_mitigation_02010","_rev":"_dVfOTUm--S","original_id":"1317","name":"Missing Security Checks in Fabric Bridge","metadata":{"Phase":"Architecture and Design","Description":"Design includes provisions for access-control checks in the bridge for both upstream and downstream transactions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02011","_id":"cwe_mitigation/cwe_mitigation_02011","_rev":"_dVfOTUm--T","original_id":"1317","name":"Missing Security Checks in Fabric Bridge","metadata":{"Phase":"Implementation","Description":"Implement access-control checks in the bridge for both upstream and downstream transactions."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02014","_id":"cwe_mitigation/cwe_mitigation_02014","_rev":"_dVfOTUm--U","original_id":"1318","name":"Missing Support for Security Features in On-chip Fabrics or Buses","metadata":{"Phase":"Architecture and Design","Description":"If fabric does not support security features, implement security checks in a bridge or any component that is between the master and the fabric.  Alternatively, connect all fabric slaves that do not have any security assets under one such fabric and connect peripherals with security assets to a different fabric that supports security features. "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02017","_id":"cwe_mitigation/cwe_mitigation_02017","_rev":"_dVfOTUm--V","original_id":"1319","name":"Improper Protection against Electromagnetic Fault Injection (EM-FI)","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t\t\t\t  \n\t\t\t\t\t\t1. Redundancy – By replicating critical operations and comparing the two outputs can help indicate whether a fault has been injected.\n\t\t\t\t\t\t2. Error detection and correction codes - Gay, Mael, et al. proposed a new scheme that not only detects faults injected by a malicious adversary but also automatically corrects single nibble/byte errors introduced by low-multiplicity faults.\n\t\t\t\t\t\t3. Fail by default coding - When checking conditions (switch or if) check all possible cases and fail by default because the default case in a switch (or the else part of a cascaded if-else-if construct) is used for dealing with the last possible (and valid) value without checking. This is prone to fault injection because this alternative is easily selected as a result of potential data manipulation [REF-1141].\n\t\t\t\t\t\t4. Random Behavior - adding random delays before critical operations, so that timing is not predictable.\n\t\t\t\t\t\t5. Program Flow Integrity Protection – The program flow can be secured by integrating run-time checking aiming at detecting control flow inconsistencies. One such example is tagging the source code to indicate the points not to be bypassed [REF-1147].\n\t\t\t\t\t\t6. Sensors – Usage of sensors can detect variations in voltage and current.\n\t\t\t\t\t\t7. Shields – physical barriers to protect the chips from malicious manipulation.\n\t\t\t\t\t  \n\t\t\t\t\t"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02018","_id":"cwe_mitigation/cwe_mitigation_02018","_rev":"_dVfOTUm--W","original_id":"1320","name":"Improper Protection for Out of Bounds Signal Level Alerts","metadata":{"Phase":"Architecture and Design","Description":"Alert signals generated by critical events should be protected from access by untrusted agents. Only hardware or trusted firmware modules should be able to alter the alert configuration."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02019","_id":"cwe_mitigation/cwe_mitigation_02019","_rev":"_dVfOTUm--X","original_id":"1321","name":"Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')","metadata":{"Phase":"Implementation","Description":"By freezing the object prototype first (for example, Object.freeze(Object.prototype)), modification of the prototype becomes impossible."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02020","_id":"cwe_mitigation/cwe_mitigation_02020","_rev":"_dVfOTUm--Y","original_id":"1321","name":"Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')","metadata":{"Phase":"Architecture and Design","Description":"By blocking modifications of attributes that resolve to object prototype, such as proto or prototype, this weakness can be mitigated."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02021","_id":"cwe_mitigation/cwe_mitigation_02021","_rev":"_dVfOTUm--Z","original_id":"1321","name":"Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')","metadata":{"Phase":"Implementation","Description":"When handling untrusted objects, validating using a schema can be used."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02022","_id":"cwe_mitigation/cwe_mitigation_02022","_rev":"_dVfOTUm--a","original_id":"1321","name":"Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')","metadata":{"Phase":"Implementation","Description":"By using an object without prototypes (via Object.create(null) ), adding object prototype attributes by accessing the prototype via the special attributes becomes impossible, mitigating this weakness."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02023","_id":"cwe_mitigation/cwe_mitigation_02023","_rev":"_dVfOTUm--b","original_id":"1321","name":"Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')","metadata":{"Phase":"Implementation","Description":"Map can be used instead of objects in most cases. If Map methods are used instead of object attributes, it is not possible to access the object prototype or modify it."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02024","_id":"cwe_mitigation/cwe_mitigation_02024","_rev":"_dVfOTUm--c","original_id":"1322","name":"Use of Blocking Code in Single-threaded, Non-blocking Context","metadata":{"Phase":"Implementation","Description":"Generally speaking, blocking calls should be\n\t\t\t\t\treplaced with non-blocking alternatives that can be used asynchronously.\n\t\t\t\t\tExpensive computations should be passed off to worker threads, although\n\t\t\t\t\tthe correct approach depends on the framework being used."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02025","_id":"cwe_mitigation/cwe_mitigation_02025","_rev":"_dVfOTUm--d","original_id":"1322","name":"Use of Blocking Code in Single-threaded, Non-blocking Context","metadata":{"Phase":"Implementation","Description":"For expensive computations, consider breaking them up into\n\t\t\t\t\tmultiple smaller computations. Refer to the documentation of the\n\t\t\t\t\tframework being used for guidance."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02026","_id":"cwe_mitigation/cwe_mitigation_02026","_rev":"_dVfOTUm--e","original_id":"1323","name":"Improper Management of Sensitive Trace Data","metadata":{"Phase":"Implementation","Description":"Tag traces to indicate owner and debugging privilege level (designer, OEM, or end user) needed to access that trace."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02027","_id":"cwe_mitigation/cwe_mitigation_02027","_rev":"_dVfOTUm--f","original_id":"1324","name":"Sensitive Information Accessible by Physical Probing of JTAG Interface","metadata":{"Phase":"Manufacturing","Description":"Disable permanently the JTAG interface before releasing the system to untrusted users."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02028","_id":"cwe_mitigation/cwe_mitigation_02028","_rev":"_dVfOTUm--g","original_id":"1324","name":"Sensitive Information Accessible by Physical Probing of JTAG Interface","metadata":{"Phase":"Architecture and Design","Description":"Encrypt all information (traffic) on the JTAG interface using an approved algorithm (such as recommended by NIST). Encrypt the path from inside the chip to the trusted user application."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02029","_id":"cwe_mitigation/cwe_mitigation_02029","_rev":"_dVfOTUm--h","original_id":"1324","name":"Sensitive Information Accessible by Physical Probing of JTAG Interface","metadata":{"Phase":"Implementation","Description":"Block access to secret data from JTAG."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02030","_id":"cwe_mitigation/cwe_mitigation_02030","_rev":"_dVfOTUm--i","original_id":"1325","name":"Improperly Controlled Sequential Memory Allocation","metadata":{"Phase":"Implementation","Description":"Ensure multiple allocations of the same kind of object are properly tracked - possibly across multiple sessions, requests, or messages. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02031","_id":"cwe_mitigation/cwe_mitigation_02031","_rev":"_dVfOTUm--j","original_id":"1325","name":"Improperly Controlled Sequential Memory Allocation","metadata":{"Phase":"Operation","Description":"Run the program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02032","_id":"cwe_mitigation/cwe_mitigation_02032","_rev":"_dVfOTUm--k","original_id":"1326","name":"Missing Immutable Root of Trust in Hardware","metadata":{"Phase":"Architecture and Design","Description":"When architecting the system, the RoT should be designated for storage in a memory that does not allow further programming/writes."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02033","_id":"cwe_mitigation/cwe_mitigation_02033","_rev":"_dVfOTUm--l","original_id":"1326","name":"Missing Immutable Root of Trust in Hardware","metadata":{"Phase":"Implementation","Description":"During implementation and test, the RoT memory location should be demonstrated to not allow further programming/writes. "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02036","_id":"cwe_mitigation/cwe_mitigation_02036","_rev":"_dVfOTUm--m","original_id":"1327","name":"Binding to an Unrestricted IP Address","metadata":{"Phase":"System Configuration","Description":"Assign IP addresses that are not 0.0.0.0."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02037","_id":"cwe_mitigation/cwe_mitigation_02037","_rev":"_dVfOTUm--n","original_id":"1327","name":"Binding to an Unrestricted IP Address","metadata":{"Phase":"System Configuration","Description":"Unwanted connections to the configured server may be denied through a firewall or other packet filtering measures."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02038","_id":"cwe_mitigation/cwe_mitigation_02038","_rev":"_dVfOTUm--o","original_id":"1328","name":"Security Version Number Mutable to Older Versions","metadata":{"Phase":"Architecture and Design","Description":"When architecting the system, security version data should be designated for storage in registers that are either read-only or have access controls that prevent modification by an untrusted agent."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02039","_id":"cwe_mitigation/cwe_mitigation_02039","_rev":"_dVfOTUm--p","original_id":"1328","name":"Security Version Number Mutable to Older Versions","metadata":{"Phase":"Implementation","Description":"During implementation and test, security version data should be demonstrated to be read-only and access controls should be validated."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02042","_id":"cwe_mitigation/cwe_mitigation_02042","_rev":"_dVfOTUm--q","original_id":"1329","name":"Reliance on Component That is Not Updateable","metadata":{"Phase":"Requirements","Description":"Specify requirements that each component should be updateable."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02043","_id":"cwe_mitigation/cwe_mitigation_02043","_rev":"_dVfOTUm--r","original_id":"1329","name":"Reliance on Component That is Not Updateable","metadata":{"Phase":"Architecture and Design","Description":"Design the product to allow for updating of its components. Consider the infrastructure that might be necessary to support updates."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02044","_id":"cwe_mitigation/cwe_mitigation_02044","_rev":"_dVfOTUm--s","original_id":"1329","name":"Reliance on Component That is Not Updateable","metadata":{"Phase":"Implementation","Description":"Implement the necessary functionality to allow each component to be updated."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02045","_id":"cwe_mitigation/cwe_mitigation_02045","_rev":"_dVfOTUm--t","original_id":"1330","name":"Remanent Data Readable after Memory Erase","metadata":{"Phase":"Architecture and Design","Description":"\n\t\t\t\t\t\n\t\t\t\t\tSupport for secure-erase commands that apply multiple cycles of overwriting memory with known patterns and of erasing actual content.\n\t\t\t\t\tSupport for cryptographic erase in self-encrypting, memory devices.\n\t\t\t\t\tExternal, physical tools to erase memory such as ultraviolet-rays-based erase of Electrically erasable, programmable, read-only memory (EEPROM).\n\t\t\t\t\tPhysical destruction of media device. This is done for repurposed or scrapped devices that are no longer in use.\n\t\t\t\t\t\n\t\t\t\t\t"},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02048","_id":"cwe_mitigation/cwe_mitigation_02048","_rev":"_dVfOTUm--u","original_id":"1331","name":"Improper Isolation of Shared Resources in Network On Chip (NoC)","metadata":{"Phase":"Architecture and Design","Description":"Implement priority-based arbitration inside the NoC and have dedicated buffers or virtual channels for routing secret data from trusted agents."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02050","_id":"cwe_mitigation/cwe_mitigation_02050","_rev":"_dVfOTUm--v","original_id":"1332","name":"Improper Handling of Faults that Lead to Instruction Skips","metadata":{"Phase":"Architecture and Design","Description":"Design strategies for ensuring safe failure if inputs such as Vcc are modified out of acceptable ranges."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02051","_id":"cwe_mitigation/cwe_mitigation_02051","_rev":"_dVfOTUm--w","original_id":"1332","name":"Improper Handling of Faults that Lead to Instruction Skips","metadata":{"Phase":"Architecture and Design","Description":"Design strategies for ensuring safe behavior if instructions attempt to be skipped."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02052","_id":"cwe_mitigation/cwe_mitigation_02052","_rev":"_dVfOTUm--x","original_id":"1332","name":"Improper Handling of Faults that Lead to Instruction Skips","metadata":{"Phase":"Implementation","Description":"Ensure that architected fault mitigations are\n                        strong enough in practice. For example, a low power\n                        detection mechanism that takes 50 clock cycles to\n                        trigger at lower voltages may be an insufficient security mechanism if the instruction counter\n                        has already progressed with no other CPU activity occurring."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02056","_id":"cwe_mitigation/cwe_mitigation_02056","_rev":"_dVfOTUm--y","original_id":"1333","name":"Inefficient Regular Expression Complexity","metadata":{"Phase":"Architecture and Design","Description":"Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02057","_id":"cwe_mitigation/cwe_mitigation_02057","_rev":"_dVfOTUm--z","original_id":"1333","name":"Inefficient Regular Expression Complexity","metadata":{"Phase":"System Configuration","Description":"Configure backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02058","_id":"cwe_mitigation/cwe_mitigation_02058","_rev":"_dVfOTUm--0","original_id":"1333","name":"Inefficient Regular Expression Complexity","metadata":{"Phase":"Implementation","Description":"Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02059","_id":"cwe_mitigation/cwe_mitigation_02059","_rev":"_dVfOTUm--1","original_id":"1333","name":"Inefficient Regular Expression Complexity","metadata":{"Phase":"Implementation","Description":"Limit the length of the input that the regular expression will process."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02060","_id":"cwe_mitigation/cwe_mitigation_02060","_rev":"_dVfOTUm--2","original_id":"1334","name":"Unauthorized Error Injection Can Degrade Hardware Redundancy","metadata":{"Phase":"Architecture and Design","Description":"Ensure the design does not allow error injection in modes intended for normal run-time operation. Provide access controls on interfaces for injecting errors."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02061","_id":"cwe_mitigation/cwe_mitigation_02061","_rev":"_dVfOTUm--3","original_id":"1334","name":"Unauthorized Error Injection Can Degrade Hardware Redundancy","metadata":{"Phase":"Implementation","Description":"Disallow error injection in modes which are expected to be used for normal run-time operation. Provide access controls on interfaces for injecting errors."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02062","_id":"cwe_mitigation/cwe_mitigation_02062","_rev":"_dVfOTUq---","original_id":"1334","name":"Unauthorized Error Injection Can Degrade Hardware Redundancy","metadata":{"Phase":"Integration","Description":"Add an access control layer atop any unprotected interfaces for injecting errors."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02063","_id":"cwe_mitigation/cwe_mitigation_02063","_rev":"_dVfOTUq--_","original_id":"1335","name":"Incorrect Bitwise Shift of Integer","metadata":{"Phase":"Implementation","Description":"Implicitly or explicitly add checks and mitigation for negative or over-shift values."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02064","_id":"cwe_mitigation/cwe_mitigation_02064","_rev":"_dVfOTUq--A","original_id":"1336","name":"Improper Neutralization of Special Elements Used in a Template Engine","metadata":{"Phase":"Architecture and Design","Description":"Choose a template engine that offers a sandbox or restricted mode, or at least limits the power of any available expressions, function calls, or commands."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02065","_id":"cwe_mitigation/cwe_mitigation_02065","_rev":"_dVfOTUq--B","original_id":"1336","name":"Improper Neutralization of Special Elements Used in a Template Engine","metadata":{"Phase":"Implementation","Description":"Use the template engine's sandbox or restricted mode, if available."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02066","_id":"cwe_mitigation/cwe_mitigation_02066","_rev":"_dVfOTUq--C","original_id":"1338","name":"Improper Protections Against Hardware Overheating","metadata":{"Phase":"Architecture and Design","Description":"Temperature maximum and minimum limits should be enforced using thermal sensors both in silicon and at the platform level."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02067","_id":"cwe_mitigation/cwe_mitigation_02067","_rev":"_dVfOTUq--D","original_id":"1338","name":"Improper Protections Against Hardware Overheating","metadata":{"Phase":"Implementation","Description":"The platform should support cooling solutions such as fans that can be modulated based on device-operation needs to maintain a stable temperature."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02070","_id":"cwe_mitigation/cwe_mitigation_02070","_rev":"_dVfOTUq--E","original_id":"1339","name":"Insufficient Precision or Accuracy of a Real Number","metadata":{"Phase":"Implementation","Description":"The developer or maintainer can move to a more accurate representation of real numbers.  In extreme cases, the programmer can move to representations such as ratios of BigInts which can represent real numbers to extremely fine precision. The programmer can also use the concept of an Unum real. The memory and CPU tradeoffs of this change must be examined. Since floating point reals are used in many programs and many locations, they are implemented in hardware and most format changes will cause the calculations to be moved into software resulting in slower programs. "},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02071","_id":"cwe_mitigation/cwe_mitigation_02071","_rev":"_dVfOTUq--F","original_id":"1341","name":"Multiple Releases of Same Resource or Handle","metadata":{"Phase":"Implementation","Description":"When closing a resource, set the associated variable to NULL or equivalent value for the given language. Some APIs will ignore this null value or lead to application crashes or exceptions, which may be preferable to data/memory corruption."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02072","_id":"cwe_mitigation/cwe_mitigation_02072","_rev":"_dVfOTUq--G","original_id":"1341","name":"Multiple Releases of Same Resource or Handle","metadata":{"Phase":"Implementation","Description":"Implementing a flag that is set when the resource is opened and cleared when it is closed and checked before closing can be effective at prevention."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02075","_id":"cwe_mitigation/cwe_mitigation_02075","_rev":"_dVfOTUq--H","original_id":"1342","name":"Information Exposure through Microarchitectural State after Transient Execution","metadata":{"Phase":"Architecture and Design","Description":"Hardware ensures that no illegal data flows from faulting micro-ops exists at the microarchitectural level."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02076","_id":"cwe_mitigation/cwe_mitigation_02076","_rev":"_dVfOTUq--I","original_id":"1342","name":"Information Exposure through Microarchitectural State after Transient Execution","metadata":{"Phase":"Build and Compilation","Description":"Include instructions that explicitly remove traces of unneeded computations from software interactions with microarchitectural elements e.g. lfence, sfence, mfence, clflush."},"datatype":"cwe_mitigation"},{"_key":"cwe_mitigation_02077","_id":"cwe_mitigation/cwe_mitigation_02077","_rev":"_dVfOTUq--J","original_id":"1351","name":"Improper Handling of Hardware Behavior in Exceptionally Cold Environments","metadata":{"Phase":"Architecture and Design","Description":"The system should account for security primitive behavior when cooled outside standard temperatures."},"datatype":"cwe_mitigation"}]