Graph This view (graph) attempts to classify weaknesses based on their inherent characteristics, in a way that is as independent of particular languages, technologies, and frameworks as possible. Ideally, it will only cover weakness-to-weakness relationships, with minimal overlap. Its development is borrowing from - and contributing to - vulnerability theory, which will help CWE become more consistent. Once stable, this hierarchy should be useful in mapping to CWE and identifying theoretical gaps. Implicit_Slice This view (slice) covers all the elements in CWE. true() Explicit_Slice CWE nodes in this view (slice) have been deprecated. There should be a reference pointing to the replacement in each deprecated weakness. Explicit_Slice CWE nodes in this view (slice) are associated with the OWASP Top Ten. Explicit_Slice CWE nodes in this view (slice) are being focused on by SAMATE. http://samate.nist.gov/index.php/Source_Code_Security_Analysis Graph CWE nodes in this view (graph) occur when the application handles particular system resources. Explicit_Slice CWE nodes in this view (slice) are used by NIST to categorize vulnerabilities within NVD. Implicit_Slice This view (slice) covers issues that are found in C that are not common to all languages. .//Applicable_Platforms/Platform='C' Implicit_Slice This view (slice) covers issues that are found in C++ that are not common to all languages. .//Applicable_Platforms/Platform='C++' Implicit_Slice This view (slice) covers issues that are found in Java that are not common to all languages. .//Applicable_Platforms/Platform='Java' Implicit_Slice This view (slice) covers issues that are found in PHP that are not common to all languages. .//Applicable_Platforms/Platform='PHP' Implicit_Slice This view (slice) displays only weakness base elements. .//@Weakness_Abstraction='Base' Implicit_Slice This view (slice) displays only composite weaknesses. .//@Compound_Element_Structure='Composite' Implicit_Slice This view (slice) displays only weakness elements that are part of a chain. (.//Relationship_Nature='CanPrecede') or (@*[contains(name(),'ID')] = //Relationship_Target_ID[../Relationship_Nature='CanPrecede']) Weaknesses in this category are organized based on which phase they are introduced during the software development and deployment process. 1000 View ChildOf 1000 ASP.NET framework/language related environment issues with security implications. 1000 Category ChildOf 519 Weaknesses in this category are related to the creation and modification of strings. 1000 Weakness ChildOf 119 Weaknesses in this category are caused by improper data type transformation or improper handling of multiple data types. 1000 Category ChildOf 19 Weaknesses in this category are introduced when inserting or converting data from one representation into another. 1000 Category ChildOf 19 Every language has its own special elements such as characters and reserved words. The following weaknesses (under this category) are expressed in general terms. Technology-specific problems that involve special elements, such as cross-site scripting and SQL injection, are covered in another CWE node. non-specific, parsing Developers should anticipate that special elements (e.g. delimiters, symbols) will be injected into input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. Some of these types of special chars have been observed at one point or another, but it's difficult to find suitable examples after the fact. In an attempt to be complete about what kinds of "special characters" exist, some types may have been added to this list without any publicly reported vulnerability for those types. 1000 Weakness ChildOf 138 General Special Element Problems All Weaknesses in this category are typically introduced during the configuration of the software. 1000 Category ChildOf 1 635 View ChildOf 635 Weaknesses in this category are related to improper handling of special elements within particular technologies. Developers should anticipate that technology-specific special elements will be injected/removed/manipulated in the input vectors of their software system. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. Note that special elements problems can arise from designs or languages that (1) do not separate "code" from "data" or (2) mix meta-information with information. 1000 Weakness ChildOf 138 Technology-Specific Special Elements All Weaknesses in this category are typically introduced during code development, including specification, design, and implementation. 1000 Category ChildOf 1 Weaknesses in this category are related to improper handling of data within protection mechanisms that attempt to perform sanity checks for untrusted data. Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid, expected and appropriate input is processed by the system. For example, valid input may be in the form of an absolute pathname(s). You can also limit pathnames to exist on selected drives, have the format specified to include only separator characters (forward or backward slashes) and alphanumeric characters, and follow a naming convention such as having a maximum of 32 characters followed by a '.' and ending with specified extensions. 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). M. Howard D. LeBlanc Writing Secure Code 2nd Edition Microsoft 2003 1000 Category ChildOf 137 1000 Weakness CanPrecede 289 Cleansing, Canonicalization, and Comparison Errors All 80 79 71 53 72 64 3 78 52 43 Weaknesses in this category are typically found within source code. 1000 Category ChildOf 17 Source Code Weaknesses in this category are related to improper calculation or conversion of numbers. 1000 Category ChildOf 19 635 View ChildOf 635 Numeric Errors All Weaknesses in this category are typically found in functionality that processes data. 1000 Category ChildOf 18 100 99 Integer coercion refers to a set of flaws pertaining to the type casting, extension, or truncation of primitive data types. Medium Availability: Integer coercion often leads to undefined states of execution resulting in infinite loops or crashes. Access Control: In some cases, integer coercion errors can lead to exploitable buffer overflow conditions, resulting in the execution of arbitrary code. Integrity: Integer coercion errors result in an incorrect value being stored for the variable in question. Requirements specification: A language which throws exceptions on ambiguous data casts might be chosen. Design: Design objects and program flow such that multiple or complex casts are unnecessary Implementation: Ensure that any data type casting that you must used is entirely understood in order to reduce the plausibility of error in use. See the Examples section of the problem type Unsigned to signed conversion error for an example of integer coercion errors. Several flaws fall under the category of integer coercion errors. For the most part, these errors in and of themselves result only in availability and data integrity issues. However, in some circumstances, they may result in other, more complicated security related flaws, such as buffer overflow conditions. 1000 Category ChildOf 189 1000 Weakness CanAlsoBe 195 1000 Weakness CanAlsoBe 196 1000 Weakness CanAlsoBe 197 1000 Weakness CanAlsoBe 194 Integer coercion error C C++ Java .NET Implementation Weaknesses in this category are related to improper handling of sensitive information. 1000 Category ChildOf 19 All Weaknesses in this category are typically introduced during unexpected environmental conditions. 1000 Category ChildOf 1 Functions that manipulate strings encourage buffer overflows. Memory Windows provides the _mbs family of functions to perform various operations on multibyte strings. When these functions are passed a malformed multibyte string, such as a string containing a valid leading byte followed by a single null byte, they can read or write past the end of the string buffer causing a buffer overflow. The following functions all pose a risk of buffer overflow: _mbsinc _mbsdec _mbsncat _mbsncpy _mbsnextc _mbsnset _mbsrev _mbsset _mbsstr _mbstok _mbccpy _mbslen 1000 Category ChildOf 133 630 View ChildOf 630 631 Category ChildOf 633 Often Misused: Strings C C++ Software security is not security software. Here we're concerned with topics like authentication, access control, confidentiality, cryptography, and privilege management. 1000 Category ChildOf 18 Security Features Weaknesses in this category are related to the management of credentials. 1000 Category ChildOf 254 635 View ChildOf 635 All Weaknesses in this category are related to the management of permissions, privileges, and other security features that are used to perform access control. Follow the principle of least privilege when assigning access rights to entities in a software system. 1000 Category ChildOf 254 635 View ChildOf 635 Permissions, Privileges, and ACLs All 35 17 76 58 5 69 A variety of vulnerabilities occur with improper handling, assignment, or management of privileges. These are especially present in sandbox environments, although it could be argued that any privilege problem occurs within the context of some sort of sandbox. Note: can heavily overlap authorization errors Very carefully manage the setting, management and handling of privileges. Explicitly manage trust zones in the software. Follow the principle of least privilege when assigning access rights to entities in a software system. Many of the following concepts require deeper study. Most privilege problems are not classified at such a low level of detail, and terminology is very sparse. Certain classes of software, such as web browsers and software bug trackers, provide a rich set of examples for further research; operating systems have matured to the point that these kinds of weaknesses are rare. 1000 Category ChildOf 264 Privilege / sandbox errors Weaknesses in this category are related to improper assignment or handling of permissions. File processing, non-specific. File/Directory 1000 Category ChildOf 264 631 Category ChildOf 632 Permission errors 35 17 A certificate is a token that associates an identity (principle) to a cryptographic key. Certificates can be used to check if a public key belongs to the assumed owner. Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key. M. Bishop Computer Security: Art and Science Addison-Wesley 2003 1000 Weakness ChildOf 287 All Weaknesses in this category are typically introduced during unexpected environmental conditions in particular technologies. 1000 Category ChildOf 2 Weaknesses in this category are related to the use of cryptography. Cryptography This category is incomplete and needs refinement, as there is good documentation of cryptographic flaws and related attacks. Note: some of these can be resultant. 1000 Category ChildOf 254 635 View ChildOf 635 Cryptographic Issues All Weaknesses in this category are related to errors in the management of cryptographic keys. CVE-2005-2146 insecure permissions when generating secret key, allowing spoofing CVE-2001-1527 administration passwords in cleartext in executable CVE-2000-0762 default installation of product uses a default encryption key, allowing others to spoof the administrator CVE-2002-1947 static key / global shared key -- "global shared key" - product uses same SSL key for all installations, allowing attackers to eavesdrop or hijack session. CVE-2005-4002 static key / global shared key -- "global shared key" - product uses same secret key for all installations, allowing attackers to decrypt data. CVE-2005-2196 static key / global shared key -- Product uses default WEP key when not connected to a known or trusted network, which can cause it to automatically connect to a malicious network. Overlaps: default. CVE-2005-1794 Exposed or accessible private key (overlaps information leak) -- Private key stored in executable CVE-2001-0072 Exposed or accessible private key (overlaps information leak) -- Crypto program imports both public and private keys but does not tell the user about the private keys, possibly breaking the web of trust. CVE-2005-3256 Misc -- Encryption product accidentally selects the wrong key if the key doesn't have additional fields that are normally expected, leading to infoleak to the owner of that wrong key This category should probably be split into multiple sub-categories. 1000 Category ChildOf 310 Key Management Errors All Weaknesses in this category are related to or introduced in the User Interface (UI). User interface errors that are relevant to security have not been studied at a high level. 1000 Category ChildOf 254 (UI) User Interface Errors All Distributed computation is about time and state. That is, in order for more than one component to communicate, state must be shared, and all that takes time. Most programmers anthropomorphize their work. They think about one thread of control carrying out the entire program in the same way they would if they had to do the job themselves. Modern computers, however, switch between tasks very quickly, and in multi-core, multi-CPU, or distributed systems, two events may take place at exactly the same time. Defects rush to fill the gap between the programmer's model of how a program executes and what happens in reality. These defects are related to unexpected interactions between threads, processes, time, and information. These interactions happen through shared state: semaphores, variables, the file system, and, basically, anything that can store information. 1000 Category ChildOf 18 Time and State 61 Weaknesses in this category are related to improper management of system state. 1000 Category ChildOf 361 74 Weaknesses in this category are related to improper handling of temporary files. File/Directory 1000 Category ChildOf 361 631 Category ChildOf 632 Weaknesses in this category are related to improper handling of time or state within particular technologies. 1000 Category ChildOf 361 Weaknesses in this category are related to improper handling of time or state within J2EE. 1000 Category ChildOf 380 Error handling problems occur when an application does not properly handle errors that occur during processing. An attacker may discover this type of error, as forcing these errors can occur with a variety of corrupt input. Generally, the consequences of improper error handling are the disclosure of the internal workings of the application to the attacker, providing details to use in further attacks. Web applications that do not properly handle error conditions frequently generate error messages such as stack traces, detailed diagnostics, and other inner details of the application. Use a standard exception handling mechanism to be sure that your application properly handles all types of processing errors. All error messages sent to the user should contain as little detail as necessary to explain what happened. If the error was caused by unexpected and likely malicious input, it may be appropriate to send the user no error message other than a simple "could not process the request" response. The details of the error and its cause should be recorded in a detailed diagnostic log for later analysis. Do not allow the application to throw errors up to the application container, generally the web application server. Be sure that the container is properly configured to handle errors if you choose to let any errors propagate up to it. 1000 Category ChildOf 18 Error Handling 28 If a function in a product does not generate the correct return/status codes, or if the product does not handle all possible return/status codes that could be generated by a function, then security issues may result. This type of problem is most often found in conditions that are rarely encountered during the normal operation of the product. Presumably, most bugs related to common conditions are found and eliminated during development and testing. In some cases, the attacker can directly control or influence the environment to trigger the rare conditions. This category is often primary to a variety of other weaknesses. Many researchers focus on the resultant weaknesses and do not necessarily diagnose whether a rare condition is the primary factor. However, since 2005 it seems to be reported more frequently than in the past. This subject needs more study. 1000 Category ChildOf 388 Error Conditions, Return Values, Status Codes All Weaknesses in this category are related to improper management of system resources. Resource management errors can lead to consumption, exhaustion, etc. Often a resultant vulnerability 1000 Weakness ChildOf 398 635 View ChildOf 635 Resource Management Errors All J2EE framework related environment issues with security implications. 1000 Category ChildOf 3 Weaknesses in this category are related to improper handling of locks that are used to control access to resources. 1000 Category ChildOf 399 Resource Locking problems Weaknesses in this category are related to improper handling of communication channels and access paths. A number of vulnerabilities are specifically related to problems in creating, managing, or removing alternate channels and alternate paths. Some of these can overlap virtual file problems (CHAP.VIRTFILE), and they can are commonly used in "bypass" attacks, such as those that exploit authentication errors. Most of these issues are probably under-studied. Only a handful of public reports exist. 1000 Weakness ChildOf 398 Channel and Path Errors All Weaknesses in this category are related to improper handling of communication channels. 1000 Category ChildOf 417 Channel Errors All Weaknesses in this category are related to improper management of handlers. May be resultant This concept is under-defined and needs more research. 1000 Weakness ChildOf 398 Handler Errors Weaknesses in this category are related to unexpected behaviors from code that an application uses. 1000 Weakness ChildOf 435 Behavioral problems Weaknesses in this category involve interaction errors that are specific to WWW technology. 1000 Weakness ChildOf 435 Web problems Weaknesses in this category occur within the user interface. User interface errors that are relevant to security have not been studied at a high level. 1000 Weakness ChildOf 398 (UI) User Interface Errors All Weaknesses in this category occur in behaviors that are used for initialization and breakdown. Most of these initialization errors are significant factors in other weaknesses. Researchers tend to ignore these, concentrating instead on the resultant weaknesses, so their frequency is uncertain, at least based on published vulnerabilities. 1000 Weakness ChildOf 398 Initialization and Cleanup Errors All Weaknesses in this category are related to improper handling of specific data structures. 1000 Weakness ChildOf 398 Weaknesses in this category are related to improper handling of pointers. 1000 Weakness ChildOf 398 Weaknesses in this category are frequently found in mobile code. 1000 Weakness ChildOf 485 Weaknesses in this category are typically found within byte code or object code. 1000 Category ChildOf 17 Object Code This category intends to capture the motivations and intentions of developers that lead to weaknesses that are found within CWE. 1000 View ChildOf 1000 Genesis Weaknesses in this category were intentionally introduced by the developer, typically as a result of prioritizing other aspects of the program over security, such as maintenance. Characterizing intention is tricky: some features intentionally placed in programs can at the same time inadvertently introduce security flaws. For example, a feature that facilitates remote debugging or system maintenance may at the same time provide a trapdoor to a system. Where such cases can be distinguished, they are categorized as intentional but nonmalicious. Not wishing to endow programs with intentions, we nevertheless use the terms "malicious flaw," "malicious code," and so on, as shorthand for flaws, code, etc., that have been introduced into a system by an individual with malicious intent. Although some malicious flaws could be disguised as inadvertent flaws, this distinction can be easy to make in practice. Inadvertently created Trojan horse programs are hardly likely, although an intentionally-introduced buffer overflow might plausibly seem to be an error. 1000 Category ChildOf 504 Intentional Nonmalicious introduction of weaknesses into software can still render it vulnerable to various attacks. 1000 Category ChildOf 505 Nonmalicious Other kinds of intentional but nonmalicious security flaws are possible. Functional requirements that are written without regard to security requirements can lead to such flaws; one of the flaws exploited by the "Internet worm" [3] (case U10) could be placed in this category. 1000 Category ChildOf 513 Other Inadvertent flaws may occur in requirements; they may also find their way into software during specification and coding. Although many of these are detected and removed through testing, some flaws can remain undetected and later cause problems during operation and maintenance of the software system. For a software system composed of many modules and involving many programmers, flaws are often difficult to find and correct because module interfaces are inadequately documented and global variables are used. The lack of documentation is especially troublesome during maintenance when attempts to fix existing flaws often generate new flaws because maintainers lack understanding of the system as a whole. Although inadvertent flaws do not usually pose an immediate threat to the security of the system, the weakness resulting from a flaw may be exploited by an intruder (see case D1). 1000 Category ChildOf 504 Inadvertent Requirements Architecture and Design Implementation This category lists weaknesses related to environmental problems in .NET framework applications. 1000 Category ChildOf 3 Weaknesses in this category are related to concurrent use of shared resources. 1000 Category ChildOf 361 1000 Weakness CanAlsoBe 362 1000 Category PeerOf 371 Weaknesses in this category are related to improper use of arguments or parameters within function calls. This category is closely related to CWE-628, Incorrectly Specified Arguments, and might be the same. However, CWE-628 is a base weakness, not a category. 1000 Weakness ChildOf 227 Weaknesses in this category are related to incorrectly written expressions within code. 1000 Weakness ChildOf 398 Weaknesses in this category are related to improper handling of links within Unix-based operating systems. 1000 Weakness ChildOf 59 UNIX Path Link problems All Weaknesses in this category are related to improper handling of links within Windows-based operating systems. 1000 Weakness ChildOf 59 All Weaknesses in this category affect file or directory resources. 631 View ChildOf 631 Weaknesses in this category affect memory resources. 631 View ChildOf 631 Weaknesses in this category affect system process resources during process invocation or inter-process communication (IPC). 631 View ChildOf 631 Weaknesses in this category are related to improper handling of virtual files within Windows-based operating systems. 1000 Weakness ChildOf 66 Windows Virtual File problems All Weaknesses in this category are related to improper handling of virtual files within Mac-based operating systems. File/Directory 1000 Weakness ChildOf 66 631 Category ChildOf 632 Mac Virtual File problems All Weaknesses in this category are caused by inadequately implemented input validation within particular technologies. 1000 Weakness ChildOf 20 Weaknesses in this category are caused by inadequately implemented protection schemes that use the STRUTS framework. 1000 Weakness ChildOf 100 Java The application uses multiple validation forms with the same name, which might cause the Struts Validator to validate a form that the programmer does not expect. This could introduce other weaknesses and indicates that validation logic is not up-to-date. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Two validation forms with the same name.

...

...

]]> It is critically important that validation logic be maintained and kept in sync with the rest of the application. If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations. Moreover, it indicates that the validation logic is not being maintained, and can indicate that other, more subtle validation errors are present. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities can all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Duplicate Validation Forms Java The application has a validator form that either fails to define a validate() method, or defines a validate() method but fails to call super.validate(). This could introduce other weaknesses related to missing input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) The Struts Validator uses a form's validate() method to check the contents of the form properties against the constraints specified in the associated validation form. That means the following classes have a validate() method that is part of the validation framework: ValidatorForm, ValidatorActionForm, DynaValidatorForm, and DynaValidatorActionForm. If you create a class that extends one of these classes, and if your class implements custom validation logic by overriding the validate() method, you must call super.validate() in your validate() implementation. If you do not, the Validation Framework cannot check the contents of the form against a validation form. In other words, the validation framework will be disabled for the given form. Disabling the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Erroneous validate() Method Java If a form bean does not extend an ActionForm subclass of the Validator framework, it can expose the application to other weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) In order to use the Struts Validator, a form must extend one of the following: ValidatorForm, ValidatorActionForm, DynaValidatorActionForm, and DynaValidatorForm. You must extend one of these classes because the Struts Validator ties in to your application by implementing the validate() method in these classes. Forms derived from the ActionForm and DynaActionForm classes cannot use the Struts Validator. Bypassing the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is an important component of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Form Bean Does Not Extend Validation Class Java The application has a form field that is not validated by a corresponding validation form, which can introduce other weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Ensure that you validate all form fields. If a field is unused, it is still important to constrain them so that they are empty or undefined. Omitting validation for even a single input field may give attackers the leeway they need to compromise your application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities can stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. Some applications use the same ActionForm for more than one purpose. In situations like this, some fields may go unused under some action mappings. It is critical that unused fields be validated too. Preferably, unused fields should be constrained so that they can only be empty or undefined. If unused fields are not validated, shared business logic in an action may allow attackers to bypass the validation checks that are performed for other uses of the form. 1000 Weakness ChildOf 101 Struts: Form Field Without Validator Java When an application does not use an input validation framework such as the Struts Validator, there is a greater risk of introducing weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Unchecked input is the leading cause of vulnerabilities in J2EE applications. Unchecked input leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. To prevent such attacks, use the Struts Validator to check all program input before it is processed by the application. Ensure that there are no holes in your configuration of the Struts Validator. Example uses of the validator include checking to ensure that: * Phone number fields contain only valid characters in phone numbers * Boolean values are only "T" or "F" * Free-form strings are of a reasonable length and composition 1000 Weakness ChildOf 101 Struts: Plug-in Framework Not In Use Java An unused validation form indicates that validation logic is not up-to-date. Resultant (Weakness is typically related to the presence of some other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the presence of an unused validation form. 1000 Weakness ChildOf 101 Struts: Unused Validation Form Java Every Action Form must have a corresponding validation form. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) If a Struts Action Form Mapping specifies a form, it must have a validation form defined under the Struts Validator. If an action form mapping does not have a validation form defined, it may be vulnerable to a number of attacks that rely on unchecked input. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 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 checking. Without this approach, it is difficult, and often impossible, to establish with a high level of confidence that all input is validated. 1000 Weakness ChildOf 101 Struts: Unvalidated Action Form Java Automatic filtering via a Struts bean has been turned off, which disables the Struts Validator and custom validation logic. This exposes the application to other weaknesses related to insufficient input validation. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Ensure that an action form mapping enables validation. An action form mapping that disables validation. ]]> Disabling validation exposes this action to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. The Action Form mapping in the demonstrative example disables the form's validate() method. The Struts bean: write tag automatically filters special HTML characters, replacing a < with &lt and a > with &gt. This action can be disabled by specifying filter="false" as an attribute of the tag to disable specified JSP pages. However, being disabled makes these pages susceptible to cross-site scripting attacks. An attacker may be able to insert malicious scripts as user input to write to these JSP pages. 1000 Weakness ChildOf 101 Struts: Validator Turned Off Java Debugging messages help attackers learn about the system and plan a form of attack. Avoid releasing debug binaries into the production environment. ASP .NET applications can be configured to produce debug binaries. These binaries give detailed debugging messages and should not be used in production environments. The debug attribute of the <compilation> tag defines whether compiled binaries should include debugging information. The use of debug binaries causes an application to provide as much information about itself as possible to the user. Debug binaries are meant to be used in a development or testing environment and can pose a security risk if they are deployed to production. Attackers can leverage the additional information they gain from debugging output to mount attacks targeted on the framework, database, or other resources used by the application. 1000 Category ChildOf 10 ASP.NET Misconfiguration: Creating Debug Binary .NET Validation fields that do not appear in forms they are associated with indicate that the validation logic is out of date. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Example 1.a: An action form with two fields. Example 1.a shows an action form that has two fields, startDate and endDate. Example 1.b: A validation form with a third field. ]]> Example 1.b lists a validation form for the action form. The validation form lists a third field: scale. The presence of the third field suggests that DateRangeForm was modified without taking validation into account. It is easy for developers to forget to update validation logic when they make changes to an ActionForm class. One indication that validation logic is not being properly maintained is inconsistencies between the action form and the validation form. It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack. 1000 Weakness ChildOf 101 Struts: Validator Without Form Field Java When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) The following code defines a class named Echo. The class declares one native method (defined below), which uses C to echo commands entered on the console back to the user. class Echo { public native void runEcho(); static { System.loadLibrary("echo"); } public static void main(String[] args) { new Echo().runEcho(); } } The following C code defines the native method implemented in the Echo class: Java #include "Echo.h"//the java class above compiled with javah #include JNIEXPORT void JNICALL Java_Echo_runEcho(JNIEnv *env, jobject obj) { char buf[64]; gets(buf); printf(buf); }]]> Because the example is implemented in Java, it may appear that it is immune to memory issues like buffer overflow vulnerabilities. Although Java does do a good job of making memory operations safe, this protection does not extend to vulnerabilities occurring in source code written in other languages that are accessed using the Java Native Interface. Despite the memory protections offered in Java, the C code in this example is vulnerable to a buffer overflow because it makes use of gets(), which does not perform any bounds checking on its input. The Sun Java(TM) Tutorial provides the following description of JNI [See Reference]: The JNI framework lets your native method utilize Java objects in the same way that Java code uses these objects. A native method can create Java objects, including arrays and strings, and then inspect and use these objects to perform its tasks. A native method can also inspect and use objects created by Java application code. A native method can even update Java objects that it created or that were passed to it, and these updated objects are available to the Java application. Thus, both the native language side and the Java side of an application can create, update, and access Java objects and then share these objects between them. The vulnerability in the example above could easily be detected through a source code audit of the native method implementation. This may not be practical or possible depending on the availability of the C source code and the way the project is built, but in many cases it may suffice. However, the ability to share objects between Java and native methods expands the potential risk to much more insidious cases where improper data handling in Java may lead to unexpected vulnerabilities in native code or unsafe operations in native code corrupt data structures in Java. Vulnerabilities in native code accessed through a Java application are typically exploited in the same manner as they are in applications written in the native language. The only challenge to such an attack is for the attacker to identify that the Java application uses native code to perform certain operations. This can be accomplished in a variety of ways, including identifying specific behaviors that are often implemented with native code or by exploiting a system information leak in the Java application that exposes its use of JNI [See Reference]. Native code is unprotected by the security features enforced by the runtime environment, such as strong typing and array bounds checking. Many safety features that programmers may take for granted simply do not apply for native code, so you must carefully review all such code for potential problems. Other programming languages that may be more susceptible to buffer overflows and other attacks, such as C or C++, usually implement native code. Language-based encapsulation is broken. Fortify Software Fortify Descriptions http://vulncat.fortifysoftware.com B. Stearns The Java™ Tutorial: The Java Native Interface Sun Microsystems 2005 http://java.sun.com/docs/books/tutorial/native1.1/ 1000 Weakness ChildOf 100 Unsafe JNI Java Failure to enable validation when parsing XML gives an attacker the opportunity to supply malicious input. Primary (Weakness exists independent of other weaknesses) Explicit (This is an explicit weakness resulting from behavior of the developer) Always validate XML input against a known XML Schema or DTD. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. Most successful attacks begin with a violation of the programmer's assumptions. By accepting an XML document without validating it against a DTD or XML schema, the programmer leaves a door open for attackers to provide unexpected, unreasonable, or malicious input. It is not possible for an XML parser to validate all aspects of a document's content; 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. 1000 Weakness ChildOf 20 Missing XML Validation All 99 The software fails to adequately filter HTTP headers for CR and LF characters. Including unvalidated data in an HTTP header allows an attacker to specify the entirety of the HTTP response rendered by the browser. When an HTTP request contains unexpected CR and LF characters the server may respond with an output stream that is interpreted as two different HTTP responses (instead of one). An attacker can control the second response and mount attacks such as cross-site scripting and cache poisoning attacks. Construct HTTP headers very carefully, avoiding the use of non-validated input data. Assume all input is malicious. Use an appropriate combination of black lists and white lists to ensure only valid and expected input is processed by the system. Input (specifically, unexpected CRLFs) that is not appropriate should not be processed into HTTP headers. The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response. Assuming a string consisting of standard alpha-numeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form: HTTP/1.1 200 OK ... Set-Cookie: author=Jane Smith ... However, because the value of the cookie is formed of unvalidated user input the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", then the HTTP response would be split into two responses of the following form: HTTP/1.1 200 OK ... Set-Cookie: author=Wiley Hacker HTTP/1.1 200 OK ... Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: cross-user defacement, web and browser cache poisoning, cross-site scripting and page hijacking. Others examples: Cross-User Defacement: An attacker can make a single request to a vulnerable server that will cause the sever to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the sever. This can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server. In the best case, an attacker can leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application. In the worst case, an attacker may provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker. Cache Poisoning: The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although the user of the local browser instance will be affected. Cross-Site Scripting: Once attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users. Cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data like cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site. The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account. Page Hijacking: In addition to using a vulnerable application to send malicious content to a user, the same root vulnerability can also be leveraged to redirect sensitive content generated by the server and intended for the user to the attacker instead. By submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker can cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server for the user to the attacker. Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim. CVE-2005-1951 Application accepts CRLF in an object ID, allowing HTTP response splitting. CVE-2004-2146 Application accepts CRLF in an object ID, allowing HTTP response splitting. CVE-2004-1620 HTTP response splitting via CRLF in parameter related to URL. CVE-2004-1656 HTTP response splitting via CRLF in parameter related to URL. CVE-2004-1687 HTTP response splitting via CRLF in parameter related to URL. CVE-2005-2060 Bulletin board allows response splitting via CRLF in parameter. CVE-2005-2065 Bulletin board allows response splitting via CRLF in parameter. CVE-2004-2512 Response splitting via CRLF in PHPSESSID. CVE-2005-1951 Chain: Application accepts CRLF in an object ID, allowing HTTP response splitting. CVE-2004-1687 Chain: HTTP response splitting via CRLF in parameter related to URL. HTTP response splitting vulnerabilities occur when: 1. Data enters a web application through an untrusted source, most frequently an HTTP request. 2. The data is included in an HTTP response header sent to a web user without being validated for malicious characters. As with many software security vulnerabilities, HTTP response splitting is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header. To mount a successful exploit, the application