apache_struts.ldjson

{"ranking": [[{"circl": 2}]], "last-modified": "2017-03-29T21:59:01.940-04:00", "Modified": "2017-03-10T21:59:00.183-05:00", "cvss": "10.0", "capec": [{"name": "Embedding Scripts in Non-Script Elements", "prerequisites": ["Target client software must be a client that allows script execution based on scripts generated by remote hosts."], "summary": ["This attack is a form of Cross-Site Scripting (XSS) where malicious scripts are embedded in elements that are not expected to host scripts such as image tags (<img>), comments in XML documents (< !-CDATA->), etc. These tags may not be subject to the same input validation, output validation, and other content filtering and checking routines, so this can create an opportunity for an attacker to tunnel through the application's elements and launch a XSS attack through other elements.", "As with all remote attacks, it is important to differentiate the ability to launch an attack (such as probing an internal network for unpatched servers) and the ability of the remote attacker to collect and interpret the output of said attack."], "related_weakness": ["79", "80", "83", "84", "82", "348", "96", "20", "116", "184", "86", "350", "692", "697", "713", "71"], "id": "18", "solutions": ["Design: Use browser technologies that do not allow client side scripting.", "Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.", "Implementation: Perform input validation for all remote content.", "Implementation: Perform output validation for all remote content.", "Implementation: Disable scripting languages such as JavaScript in browser", "Implementation: Session tokens for specific host", "Implementation: Service provider should not use the XMLHttpRequest method to create a local proxy for content from other sites, because the client will not be able to discern what content comes from which host."]}, {"name": "Flash Injection", "prerequisites": ["The target must be capable of running Flash applications. In some cases, the victim must follow an attacker-supplied link."], "summary": ["An attacker tricks a victim to execute malicious flash content that executes commands or makes flash calls specified by the attacker. One example of this attack is cross-site flashing, an attacker controlled parameter to a reference call loads from content specified by the attacker."], "related_weakness": ["20", "184", "697"], "id": "182", "solutions": ["Implementation: remove sensitive information such as user name and password in the SWF file.", "Implementation: use validation on both client and server side.", "Implementation: remove debug information.", "Implementation: use SSL when loading external data", "Implementation: use crossdomain.xml file to allow the application domain to load stuff or the SWF file called by other domain."]}, {"name": "Cross-Site Scripting Using Alternate Syntax", "prerequisites": ["Target client software must allow scripting such as JavaScript."], "summary": ["The attacker uses alternate forms of keywords or commands that result in the same action as the primary form but which may not be caught by filters. For example, many keywords are processed in a case insensitive manner. If the site's web filtering algorithm does not convert all tags into a consistent case before the comparison with forbidden keywords it is possible to bypass filters (e.g., incomplete black lists) by using an alternate case structure. For example, the \"script\" tag using the alternate forms of \"Script\" or \"ScRiPt\" may bypass filters where \"script\" is the only form tested. Other variants using different syntax representations are also possible as well as using pollution meta-characters or entities that are eventually ignored by the rendering engine. The attack can result in the execution of otherwise prohibited functionality."], "related_weakness": ["79", "87", "85", "20", "86", "692", "697", "713", "71"], "id": "199", "solutions": ["Design: Use browser technologies that do not allow client side scripting.", "Design: Utilize strict type, character, and encoding enforcement", "Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.", "Implementation: Ensure all content coming from the client is using the same encoding; if not, the server-side application must canonicalize the data before applying any filtering.", "Implementation: Perform input validation for all remote content, including remote and user-generated content", "Implementation: Perform output validation for all remote content.", "Implementation: Disable scripting languages such as JavaScript in browser", "Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this."]}, {"name": "Exploiting Trust in Client (aka Make the Client Invisible)", "prerequisites": ["Server software must rely on client side formatted and validated values, and not reinforce these checks on the server side."], "summary": ["An attack of this type exploits a programs' vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client.", "An attacker executes this type of attack by placing themselves in the communication channel between client and server such that communication directly to the server is possible where the server believes it is communicating only with a valid client.", "There are numerous variations of this type of attack."], "related_weakness": ["290", "287", "20", "200", "693"], "id": "22", "solutions": ["Design: Ensure that client process and/or message is authenticated so that anonymous communications and/or messages are not accepted by the system.", "Design: Do not rely on client validation or encoding for security purposes.", "Design: Utilize digital signatures to increase authentication assurance.", "Design: Utilize two factor authentication to increase authentication assurance.", "Implementation: Perform input validation for all remote content."]}, {"name": "XML Nested Payloads", "prerequisites": ["An application uses an XML parser to perform transformation on user-controllable data.", "An application does not perform sufficient validation to ensure that user-controllable data is safe for an XML parser."], "summary": ["Applications often need to transform data in and out of the XML format by using an XML parser. It may be possible for an attacker to inject data that may have an adverse effect on the XML parser when it is being processed. By nesting XML data and causing this data to be continuously self-referential, an attacker can cause the XML parser to consume more resources while processing, causing excessive memory consumption and CPU utilization. An attacker's goal is to leverage parser failure to his or her advantage. In most cases this type of an attack will result in a denial of service due to an application becoming unstable, freezing, or crash. However it may be possible to cause a crash resulting in arbitrary code execution, leading to a jump from the data plane to the control plane [R.230.1]."], "related_weakness": ["112", "20", "19", "674", "770"], "id": "230", "solutions": ["Carefully validate and sanitize all user-controllable data prior to passing it to the XML parser routine. Ensure that the resultant data is safe to pass to the XML parser.", "Perform validation on canonical data.", "Pick a robust implementation of an XML parser.", "Validate XML against a valid schema or DTD prior to parsing."]}, {"name": "XML Oversized Payloads", "prerequisites": ["An application uses an XML parser to perform transformation on user-controllable data.", "An application does not perform sufficient validation to ensure that user-controllable data is safe for an XML parser."], "summary": ["Applications often need to transform data in and out of the XML format by using an XML parser. It may be possible for an attacker to inject data that may have an adverse effect on the XML parser when it is being processed. By supplying oversized payloads in input vectors that will be processed by the XML parser, an attacker can cause the XML parser to consume more resources while processing, causing excessive memory consumption and CPU utilization, and potentially cause execution of arbitrary code. An attacker's goal is to leverage parser failure to his or her advantage. In many cases this type of an attack will result in a denial of service due to an application becoming unstable, freezing, or crash. However it is possible to cause a crash resulting in arbitrary code execution, leading to a jump from the data plane to the control plane [R.231.1]."], "related_weakness": ["112", "20", "19", "674", "770"], "id": "231", "solutions": ["Carefully validate and sanitize all user-controllable data prior to passing it to the XML parser routine. Ensure that the resultant data is safe to pass to the XML parser.", "Perform validation on canonical data.", "Pick a robust implementation of an XML parser.", "Validate XML against a valid schema or DTD prior to parsing."]}, {"name": "Filter Failure through Buffer Overflow", "prerequisites": ["Ability to control the length of data passed to an active filter."], "summary": ["In this attack, the idea is to cause an active filter to fail by causing an oversized transaction. An attacker may try to feed overly long input strings to the program in an attempt to overwhelm the filter (by causing a buffer overflow) and hoping that the filter does not fail securely (i.e. the user input is let into the system unfiltered)."], "related_weakness": ["120", "119", "118", "74", "20", "680", "733", "697"], "id": "24", "solutions": ["Make sure that ANY failure occurring in the filtering or input validation routine is properly handled and that offending input is NOT allowed to go through. Basically make sure that the vault is closed when failure occurs.", "Pre-design: Use a language or compiler that performs automatic bounds checking.", "Pre-design through Build: 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.", "Operational: Use OS-level preventative functionality. Not a complete solution.", "Design: Use an abstraction library to abstract away risky APIs. Not a complete solution."]}, {"name": "Cross-Site Scripting via Encoded URI Schemes ", "prerequisites": ["Target client software must allow scripting such as JavaScript and allows executable content delivered using a data URI scheme."], "summary": ["An attack of this type exploits the ability of most browsers to interpret \"data\", \"javascript\" or other URI schemes as client-side executable content placeholders. This attack consists of passing a malicious URI in an anchor tag HREF attribute or any other similar attributes in other HTML tags. Such malicious URI contains, for example, a base64 encoded HTML content with an embedded cross-site scripting payload. The attack is executed when the browser interprets the malicious content i.e., for example, when the victim clicks on the malicious link."], "related_weakness": ["79", "84", "85", "20", "86", "692", "697", "713", "71"], "id": "244", "solutions": ["Design: Use browser technologies that do not allow client side scripting.", "Design: Utilize strict type, character, and encoding enforcement.", "Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.", "Implementation: Ensure all content coming from the client is using the same encoding; if not, the server-side application must canonicalize the data before applying any filtering.", "Implementation: Perform input validation for all remote content, including remote and user-generated content", "Implementation: Perform output validation for all remote content.", "Implementation: Disable scripting languages such as JavaScript in browser", "Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this."]}, {"name": "XML Injection", "prerequisites": ["XML queries used to process user input and retrieve information stored in XML documents", "User-controllable input not properly sanitized"], "summary": ["An attacker utilizes crafted XML user-controllable input to probe, attack, and inject data into the XML database, using techniques similar to SQL injection. The user-controllable input can allow for unauthorized viewing of data, bypassing authentication or the front-end application for direct XML database access, and possibly altering database information."], "related_weakness": ["91", "74", "20", "390", "713", "707"], "id": "250", "solutions": ["Use of custom error pages - Attackers can glean information about the nature of queries from descriptive error messages. Input validation must be coupled with customized error pages that inform about an error without disclosing information about the database or application."]}, {"name": "Environment Variable Manipulation", "prerequisites": ["The targeted application must rely on external variables in such a way that malicious manipulation of them can subvert functionality."], "summary": ["An attacker manipulates environment variables used by an application to perform a variety of possible attacks. Changing variable values is usually undertaken as part of another attack; for example, a path traversal (inserting relative path modifiers) or buffer overflow (enlarging a variable value beyond an application's ability to store it)."], "related_weakness": ["471", "20"], "id": "264", "solutions": ["Design: Ensure that variables that should not be manipulated by a user are not accessible to them."]}, {"name": "Global variable manipulation", "prerequisites": ["The targeted application must rely on external variables in such a way that malicious manipulation of them can subvert functionality."], "summary": ["An attacker manipulates global variables used by an application to perform a variety of possible attacks. Changing variable values is usually undertaken as part of another attack; for example, a path traversal (inserting relative path modifiers) or buffer overflow (enlarging a variable value beyond an application's ability to store it)."], "related_weakness": ["471", "20"], "id": "265", "solutions": ["Design: Range, size and value and consistency verification for any arguments supplied to application from external sources and devise appropriate error response.", "Design: Ensure that variables that should not be manipulated by a user are not accessible to them."]}, {"name": "Leverage Alternate Encoding", "prerequisites": ["The application's decoder accepts and interprets encoded characters. Data canonicalization, input filtering and validating is not done properly leaving the door open to harmful characters for the target host."], "summary": ["This attack leverages the possibility to encode potentially harmful input and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult."], "related_weakness": ["173", "172", "180", "181", "171", "73", "21", "74", "20", "697", "692"], "id": "267", "solutions": ["Assume all input might use an improper representation. Use canonicalized data inside the application; all data must be converted into the representation used inside the application (UTF-8, UTF-16, etc.)", "Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system. Test your decoding process against malicious input."]}, {"name": "Fuzzing", "prerequisites": [], "summary": ["Fuzzing is a software testing method that feeds randomly constructed input to the system and looks for an indication that a failure in response to that input has occurred. Fuzzing treats the system as a black box and is totally free from any preconceptions or assumptions about the system.", "An attacker can leverage fuzzing to try to identify weaknesses in the system. For instance fuzzing can help an attacker discover certain assumptions made in the system about user input. Fuzzing gives an attacker a quick way of potentially uncovering some of these assumptions without really knowing anything about the internals of the system. These assumptions can then be turned against the system by specially crafting user input that may allow an attacker to achieve his goals."], "related_weakness": ["74", "388", "20", "728"], "id": "28", "solutions": ["Test to ensure that the software behaves as per specification and that there are no unintended side effects. Ensure that no assumptions about the validity of data are made.", "Use fuzz testing during the software QA process to uncover any surprises, uncover any assumptions or unexpected behavior."]}, {"name": "Using Leading 'Ghost' Character Sequences to Bypass Input Filters", "prerequisites": ["The targeted API must ignore the leading ghost characters that are used to get past the filters for the semantics to be the same."], "summary": ["An attacker intentionally introduces leading characters that enable getting the input past the filters. The API that is being targeted, ignores the leading \"ghost\" characters, and therefore processes the attackers' input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.", "Some APIs will strip certain leading characters from a string of parameters. Perhaps these characters are considered redundant, and for this reason they are removed. Another possibility is the parser logic at the beginning of analysis is specialized in some way that causes some characters to be removed. The attacker can specify multiple types of alternative encodings at the beginning of a string as a set of probes.", "One commonly used possibility involves adding ghost characters--extra characters that don't affect the validity of the request at the API layer. If the attacker has access to the API libraries being targeted, certain attack ideas can be tested directly in advance. Once alternative ghost encodings emerge through testing, the attacker can move from lab-based API testing to testing real-world service implementations."], "related_weakness": ["173", "41", "172", "171", "179", "180", "181", "183", "184", "20", "74", "697", "707"], "id": "3", "solutions": ["Perform white list rather than black list input validation.", "Canonicalize all data prior to validation.", "Take an iterative approach to input validation (defense in depth)."]}, {"name": "Accessing/Intercepting/Modifying HTTP Cookies", "prerequisites": ["Target server software must be a HTTP daemon that relies on cookies."], "summary": ["This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems.", "The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein.", "The second form of this attack involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the attacker to impersonate the remote user/session.", "The third form is when the cookie's content is modified by the attacker before it is sent back to the server. Here the attacker seeks to convince the target server to operate on this falsified information."], "related_weakness": ["565", "302", "311", "113", "539", "20", "315", "384", "472", "724", "602", "642"], "id": "31", "solutions": ["Design: Use input validation for cookies", "Design: Generate and validate MAC for cookies", "Implementation: Use SSL/TLS to protect cookie in transit", "Implementation: Ensure the web server implements all relevant security patches, many exploitable buffer overflows are fixed in patches issued for the software."]}, {"name": "Embedding Scripts in HTTP Query Strings", "prerequisites": ["Target client software must allow scripting such as JavaScript. Server software must allow display of remote generated HTML without sufficient input or output validation."], "summary": ["A variant of cross-site scripting called \"reflected\" cross-site scripting, the HTTP Query Strings attack consists of passing a malicious script inside an otherwise valid HTTP request query string. This is of significant concern for sites that rely on dynamic, user-generated content such as bulletin boards, news sites, blogs, and web enabled administration GUIs. The malicious script may steal session data, browse history, probe files, or otherwise execute attacks on the client side. Once the attacker has prepared the malicious HTTP query it is sent to a victim user (perhaps by email, IM, or posted on an online forum), who clicks on a normal looking link that contains a poison query string. This technique can be made more effective through the use of services like http://tinyurl.com/, which makes very small URLs that will redirect to very large, complex ones. The victim will not know what he is really clicking on."], "related_weakness": ["79", "84", "85", "20", "86", "692", "697", "713", "71"], "id": "32", "solutions": ["Design: Use browser technologies that do not allow client side scripting.", "Design: Utilize strict type, character, and encoding enforcement", "Design: Server side developers should not proxy content via XHR or other means, if a http proxy for remote content is setup on the server side, the client's browser has no way of discerning where the data is originating from.", "Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.", "Implementation: Perform input validation for all remote content, including remote and user-generated content", "Implementation: Perform output validation for all remote content.", "Implementation: Disable scripting languages such as JavaScript in browser", "Implementation: Session tokens for specific host", "Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this.", "Implementation: Privileges are constrained, if a script is loaded, ensure system runs in chroot jail or other limited authority mode"]}, {"name": "MIME Conversion", "prerequisites": ["The target system uses a mail server.", "Mail server vendor has not released a patch for the MIME conversion routine, the patch itself has a security hole or does not fix the original problem, or the patch has not been applied to the user's system."], "summary": ["An attacker exploits a weakness in the MIME conversion routine to cause a buffer overflow and gain control over the mail server machine. The MIME system is designed to allow various different information formats to be interpreted and sent via e-mail. Attack points exist when data are converted to MIME compatible format and back."], "related_weakness": ["120", "119", "74", "20"], "id": "42", "solutions": ["Stay up to date with third party vendor patches", "From \"Exploiting Software\", please see reference below.", "Use the sendmail restricted shell program (smrsh)", "Use mail.local"]}, {"name": "Exploiting Multiple Input Interpretation Layers", "prerequisites": ["User input is used to construct a command to be executed on the target system or as part of the file name.", "Multiple parser passes are performed on the data supplied by the user."], "summary": ["An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a \"layer\" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps.", "The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application:", "In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop."], "related_weakness": ["171", "179", "181", "184", "183", "77", "78", "74", "20", "697", "707"], "id": "43", "solutions": ["An iterative approach to input validation may be required to ensure that no dangerous characters are present. It may be necessary to implement redundant checking across different input validation layers. Ensure that invalid data is rejected as soon as possible and do not continue to work with it.", "Make sure to perform input validation on canonicalized data (i.e. data that is data in its most standard form). This will help avoid tricky encodings getting past the filters.", "Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system."]}, {"name": "Buffer Overflow via Symbolic Links", "prerequisites": ["The attacker can create symbolic link on the target host.", "The target host does not perform correct boundary checking while consuming data from a resources."], "summary": ["This type of attack leverages the use of symbolic links to cause buffer overflows. An attacker can try to create or manipulate a symbolic link file such that its contents result in out of bounds data. When the target software processes the symbolic link file, it could potentially overflow internal buffers with insufficient bounds checking."], "related_weakness": ["120", "285", "302", "118", "119", "74", "20", "680", "697"], "id": "45", "solutions": ["Pay attention to the fact that the resource you read from can be a replaced by a Symbolic link. You can do a Symlink check before reading the file and decide that this is not a legitimate way of accessing the resource.", "Because Symlink can be modified by an attacker, make sure that the ones you read are located in protected directories.", "Pay attention to the resource pointed to by your symlink links (See attack pattern named \"Forced Symlink race\"), they can be replaced by malicious resources.", "Always check the size of the input data before copying to a buffer.", "Use a language or compiler that performs automatic bounds checking.", "Use an abstraction library to abstract away risky APIs. Not a complete solution.", "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.", "Use OS-level preventative functionality. Not a complete solution."]}, {"name": "Overflow Variables and Tags", "prerequisites": ["The target program consumes user-controllable data in the form of tags or variables.", "The target program does not perform sufficient boundary checking."], "summary": ["This type of attack leverages the use of tags or variables from a formatted configuration data to cause buffer overflow. The attacker crafts a malicious HTML page or configuration file that includes oversized strings, thus causing an overflow."], "related_weakness": ["120", "118", "119", "74", "20", "680", "733", "697"], "id": "46", "solutions": ["Use a language or compiler that performs automatic bounds checking.", "Use an abstraction library to abstract away risky APIs. Not a complete solution.", "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.", "Use OS-level preventative functionality. Not a complete solution.", "Do not trust input data from user. Validate all user input."]}, {"name": "Buffer Overflow via Parameter Expansion", "prerequisites": ["The program expands one of the parameters passed to a function with input controlled by the user, but a later function making use of the expanded parameter erroneously considers the original, not the expanded size of the parameter.", "The expanded parameter is used in the context where buffer overflow may become possible due to the incorrect understanding of the parameter size (i.e. thinking that it is smaller than it really is)."], "summary": ["In this attack, the target software is given input that the attacker knows will be modified and expanded in size during processing. This attack relies on the target software failing to anticipate that the expanded data may exceed some internal limit, thereby creating a buffer overflow."], "related_weakness": ["120", "119", "118", "130", "131", "74", "20", "680", "697"], "id": "47", "solutions": ["Ensure that when parameter expansion happens in the code that the assumptions used to determine the resulting size of the parameter are accurate and that the new size of the parameter is visible to the whole system"]}, {"name": "Signature Spoof", "prerequisites": ["The victim or victim system is dependent upon a cryptographic signature-based verification system for validation of one or more security events or actions.", "The validation can be bypassed via an attacker-provided signature that makes it appear that the legitimate authoritative or reputable source provided the signature."], "summary": ["An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions."], "related_weakness": ["20", "327", "290"], "id": "473", "solutions": []}, {"name": "XML Client-Side Attack", "prerequisites": ["An application uses an XML parser to perform transformation on user-controllable data.", "An application does not perform sufficient validation to ensure that user-controllable data is safe for an XML parser."], "summary": ["Client applications such as web browsers that process HTML data often need to transform data in and out of the XML format by using an XML parser. It may be possible for an attacker to inject data that may have an adverse effect on the XML parser when it is being processed. These adverse effects may include the parser crashing, consuming too much of a resource, executing too slowly, executing code supplied by an attacker, allowing usage of unintended system functionality, etc. An attacker's goal is to leverage parser failure to his or her advantage. In some cases it may be possible to jump from the data plane to the control plane via bad data being passed to an XML parser. [R.484.1]"], "related_weakness": ["112", "20", "19"], "id": "484", "solutions": ["Carefully validate and sanitize all user-controllable data prior to passing it to the XML parser routine. Ensure that the resultant data is safe to pass to the XML parser.", "The client software should have the latest patches and should be audited for vulnerabilities before being used to communicate with potentially hostile servers."]}, {"name": "Embedding NULL Bytes", "prerequisites": ["The program does not properly handle postfix NULL terminators"], "summary": ["An attacker embeds one or more null bytes in input to the target software. This attack relies on the usage of a null-valued byte as a string terminator in many environments. The goal is for certain components of the target software to stop processing the input when it encounters the null byte(s)."], "related_weakness": ["158", "172", "173", "171", "74", "20", "697", "707"], "id": "52", "solutions": ["Properly handle the NULL characters supplied as part of user input prior to doing anything with the data."]}, {"name": "Postfix, Null Terminate, and Backslash", "prerequisites": ["Null terminators are not properly handled by the filter."], "summary": ["If a string is passed through a filter of some kind, then a terminal NULL may not be valid. Using alternate representation of NULL allows an attacker to embed the NULL mid-string while postfixing the proper data so that the filter is avoided. One example is a filter that looks for a trailing slash character. If a string insertion is possible, but the slash must exist, an alternate encoding of NULL in mid-string may be used."], "related_weakness": ["158", "172", "173", "171", "74", "20", "697", "707"], "id": "53", "solutions": ["Properly handle Null characters. Make sure canonicalization is properly applied. Do not pass Null characters to the underlying APIs.", "Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system."]}, {"name": "Simple Script Injection", "prerequisites": ["Target client software must be a client that allows scripting communication from remote hosts, such as a JavaScript-enabled Web Browser"], "summary": ["An attacker embeds malicious scripts in content that will be served to web browsers. The goal of the attack is for the target software, the client-side browser, to execute the script with the users' privilege level.", "An attack of this type exploits a programs' vulnerabilities that are brought on by allowing remote hosts to execute code and scripts. Web browsers, for example, have some simple security controls in place, but if a remote attacker is allowed to execute scripts (through injecting them in to user-generated content like bulletin boards) then these controls may be bypassed. Further, these attacks are very difficult for an end user to detect."], "related_weakness": ["79", "20", "184", "96", "113", "348", "116", "350", "86", "602", "692", "697", "713", "71"], "id": "63", "solutions": ["Design: Use browser technologies that do not allow client side scripting.", "Design: Utilize strict type, character, and encoding enforcement", "Design: Server side developers should not proxy content via XHR or other means, if a http proxy for remote content is setup on the server side, the client's browser has no way of discerning where the data is originating from.", "Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.", "Implementation: Perform input validation for all remote content.", "Implementation: Perform output validation for all remote content.", "Implementation: Session tokens for specific host", "Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this."]}, {"name": "Using Slashes and URL Encoding Combined to Bypass Validation Logic", "prerequisites": ["The application accepts and decodes URL string request.", "The application performs insufficient filtering/canonicalization on the URLs."], "summary": ["This attack targets the encoding of the URL combined with the encoding of the slash characters. An attacker can take advantage of the multiple way of encoding an URL and abuse the interpretation of the URL. An URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc."], "related_weakness": ["177", "171", "173", "172", "73", "21", "22", "74", "20", "697", "707"], "id": "64", "solutions": ["Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system. Test your decoding process against malicious input.", "Be aware of the threat of alternative method of data encoding and obfuscation technique such as IP address encoding.", "When client input is required from web-based forms, avoid using the \"GET\" method to submit data, as the method causes the form data to be appended to the URL and is easily manipulated. Instead, use the \"POST method whenever possible.", "Any security checks should occur after the data has been decoded and validated as correct data format. Do not repeat decoding process, if bad character are left after decoding process, treat the data as suspicious, and fail the validation process.", "Refer to the RFCs to safely decode URL.", "Regular expression can be used to match safe URL patterns. However, that may discard valid URL requests if the regular expression is too restrictive.", "There are tools to scan HTTP requests to the server for valid URL such as URLScan from Microsoft (http://www.microsoft.com/technet/security/tools/urlscan.mspx)."]}, {"name": "SQL Injection", "prerequisites": ["SQL queries used by the application to store, retrieve or modify data.", "User-controllable input that is not properly validated by the application as part of SQL queries."], "summary": ["This attack exploits target software that constructs SQL statements based on user input. An attacker crafts input strings so that when the target software constructs SQL statements based on the input, the resulting SQL statement performs actions other than those the application intended.", "SQL Injection results from failure of the application to appropriately validate input. When specially crafted user-controlled input consisting of SQL syntax is used without proper validation as part of SQL queries, it is possible to glean information from the database in ways not envisaged during application design. Depending upon the database and the design of the application, it may also be possible to leverage injection to have the database execute system-related commands of the attackers' choice. SQL Injection enables an attacker to talk directly to the database, thus bypassing the application completely. Successful injection can cause information disclosure as well as ability to add or modify data in the database. In order to successfully inject SQL and retrieve information from a database, an attacker:"], "related_weakness": ["89", "74", "20", "390", "697", "713", "707"], "id": "66", "solutions": ["Strong input validation - All user-controllable input must be validated and filtered for illegal characters as well as SQL content. Keywords such as UNION, SELECT or INSERT must be filtered in addition to characters such as a single-quote(') or SQL-comments (--) based on the context in which they appear.", "Use of parameterized queries or stored procedures - Parameterization causes the input to be restricted to certain domains, such as strings or integers, and any input outside such domains is considered invalid and the query fails. Note that SQL Injection is possible even in the presence of stored procedures if the eventual query is constructed dynamically.", "Use of custom error pages - Attackers can glean information about the nature of queries from descriptive error messages. Input validation must be coupled with customized error pages that inform about an error without disclosing information about the database or application."]}, {"name": "String Format Overflow in syslog()", "prerequisites": ["The format string argument of the Syslog function can be tainted with user supplied data."], "summary": ["This attack targets the format string vulnerabilities in the syslog() function. An attacker would typically inject malicious input in the format string parameter of the syslog function. This is a common problem, and many public vulnerabilities and associated exploits have been posted."], "related_weakness": ["120", "134", "74", "20", "680", "697"], "id": "67", "solutions": ["The following code shows a vulnerable usage of Syslog():"]}, {"name": "Blind SQL Injection", "prerequisites": ["SQL queries used by the application to store, retrieve or modify data.", "User-controllable input that is not properly validated by the application as part of SQL queries."], "summary": ["Blind SQL Injection results from an insufficient mitigation for SQL Injection. Although suppressing database error messages are considered best practice, the suppression alone is not sufficient to prevent SQL Injection. Blind SQL Injection is a form of SQL Injection that overcomes the lack of error messages. Without the error messages that facilitate SQL Injection, the attacker constructs input strings that probe the target through simple Boolean SQL expressions. The attacker can determine if the syntax and structure of the injection was successful based on whether the query was executed or not. Applied iteratively, the attacker determines how and where the target is vulnerable to SQL Injection.", "For example, an attacker may try entering something like \"username' AND 1=1; --\" in an input field. If the result is the same as when the attacker entered \"username\" in the field, then the attacker knows that the application is vulnerable to SQL Injection. The attacker can then ask yes/no questions from the database server to extract information from it. For example, the attacker can extract table names from a database using the following types of queries:", "If the above query executes properly, then the attacker knows that the first character in a table name in the database is a letter between m and z. If it doesn't, then the attacker knows that the character must be between a and l (assuming of course that table names only contain alphabetic characters). By performing a binary search on all character positions, the attacker can determine all table names in the database. Subsequently, the attacker may execute an actual attack and send something like:"], "related_weakness": ["89", "209", "74", "20", "390", "697", "713", "707"], "id": "7", "solutions": ["Security by Obscurity is not a solution to preventing SQL Injection. Rather than suppress error messages and exceptions, the application must handle them gracefully, returning either a custom error page or redirecting the user to a default page, without revealing any information about the database or the application internals.", "Strong input validation - All user-controllable input must be validated and filtered for illegal characters as well as SQL content. Keywords such as UNION, SELECT or INSERT must be filtered in addition to characters such as a single-quote(') or SQL-comments (--) based on the context in which they appear."]}, {"name": "Using Unicode Encoding to Bypass Validation Logic", "prerequisites": ["Filtering is performed on data that has not be properly canonicalized."], "summary": ["An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly."], "related_weakness": ["176", "171", "179", "180", "173", "172", "184", "183", "74", "20", "697", "692"], "id": "71", "solutions": ["Ensure that the system is Unicode aware and can properly process Unicode data. Do not make an assumption that data will be in ASCII.", "Ensure that filtering or input validation is applied to canonical data.", "Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system."]}, {"name": "URL Encoding", "prerequisites": ["The application should accepts and decodes URL input.", "The application performs insufficient filtering/canonicalization on the URLs."], "summary": ["This attack targets the encoding of the URL. An attacker can take advantage of the multiple way of encoding an URL and abuse the interpretation of the URL. An URL may contain special character that need special syntax handling in order to be interpreted. Special characters are represented using a percentage character followed by two digits representing the octet code of the original character (%HEX-CODE). For instance US-ASCII space character would be represented with %20. This is often referred as escaped ending or percent-encoding. Since the server decodes the URL from the requests, it may restrict the access to some URL paths by validating and filtering out the URL requests it received. An attacker will try to craft an URL with a sequence of special characters which once interpreted by the server will be equivalent to a forbidden URL. It can be difficult to protect against this attack since the URL can contain other format of encoding such as UTF-8 encoding, Unicode-encoding, etc. The attacker could also subvert the meaning of the URL string request by encoding the data being sent to the server through a GET request. For instance an attacker may subvert the meaning of parameters used in a SQL request and sent through the URL string (See Example section)."], "related_weakness": ["173", "177", "171", "172", "73", "21", "74", "20"], "id": "72", "solutions": ["Refer to the RFCs to safely decode URL.", "Regular expression can be used to match safe URL patterns. However, that may discard valid URL requests if the regular expression is too restrictive.", "There are tools to scan HTTP requests to the server for valid URL such as URLScan from Microsoft (http://www.microsoft.com/technet/security/tools/urlscan.mspx).", "Any security checks should occur after the data has been decoded and validated as correct data format. Do not repeat decoding process, if bad character are left after decoding process, treat the data as suspicious, and fail the validation process.", "Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system. Test your decoding process against malicious input.", "Be aware of the threat of alternative method of data encoding and obfuscation technique such as IP address encoding. (See related guideline section)", "When client input is required from web-based forms, avoid using the \"GET\" method to submit data, as the method causes the form data to be appended to the URL and is easily manipulated. Instead, use the \"POST method whenever possible."]}, {"name": "User-Controlled Filename", "prerequisites": ["The victim must trust the name and locale of user controlled filenames."], "summary": ["An attack of this type involves an attacker inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities."], "related_weakness": ["20", "184", "96", "348", "116", "350", "86", "697"], "id": "73", "solutions": ["Design: Use browser technologies that do not allow client side scripting.", "Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.", "Implementation: Perform input validation for all remote content.", "Implementation: Perform output validation for all remote content.", "Implementation: Disable scripting languages such as JavaScript in browser", "Implementation: Scan dynamically generated content against validation specification"]}, {"name": "Using Escaped Slashes in Alternate Encoding", "prerequisites": ["The application accepts the backlash character as escape character.", "The application server does incomplete input data decoding, filtering and validation."], "summary": ["This attack targets the use of the backslash in alternate encoding. An attacker can provide a backslash as a leading character and causes a parser to believe that the next character is special. This is called an escape. By using that trick, the attacker tries to exploit alternate ways to encode the same character which leads to filter problems and opens avenues to attack."], "related_weakness": ["180", "181", "173", "171", "172", "73", "21", "22", "74", "20", "697", "707"], "id": "78", "solutions": ["Verify that the user-supplied data does not use backslash character to escape malicious characters.", "Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system.", "Be aware of the threat of alternative method of data encoding.", "Regular expressions can be used to filter out backslash. Make sure you decode before filtering and validating the untrusted input data.", "In the case of path traversals, use the principle of least privilege when determining access rights to file systems. Do not allow users to access directories/files that they should not access.", "Any security checks should occur after the data has been decoded and validated as correct data format. Do not repeat decoding process, if bad character are left after decoding process, treat the data as suspicious, and fail the validation process.", "Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names."]}, {"name": "Using Slashes in Alternate Encoding", "prerequisites": ["The application server accepts paths to locate resources.", "The application server does insufficient input data validation on the resource path requested by the user.", "The access right to resources are not set properly."], "summary": ["This attack targets the encoding of the Slash characters. An attacker would try to exploit common filtering problems related to the use of the slashes characters to gain access to resources on the target host. Directory-driven systems, such as file systems and databases, typically use the slash character to indicate traversal between directories or other container components. For murky historical reasons, PCs (and, as a result, Microsoft OSs) choose to use a backslash, whereas the UNIX world typically makes use of the forward slash. The schizophrenic result is that many MS-based systems are required to understand both forms of the slash. This gives the attacker many opportunities to discover and abuse a number of common filtering problems. The goal of this pattern is to discover server software that only applies filters to one version, but not the other."], "related_weakness": ["173", "171", "180", "181", "20", "74", "73", "21", "22", "185", "200", "697", "707"], "id": "79", "solutions": ["Any security checks should occur after the data has been decoded and validated as correct data format. Do not repeat decoding process, if bad character are left after decoding process, treat the data as suspicious, and fail the validation process. Refer to the RFCs to safely decode URL.", "When client input is required from web-based forms, avoid using the \"GET\" method to submit data, as the method causes the form data to be appended to the URL and is easily manipulated. Instead, use the \"POST method whenever possible.", "There are tools to scan HTTP requests to the server for valid URL such as URLScan from Microsoft (http://www.microsoft.com/technet/security/tools/urlscan.mspx)", "Be aware of the threat of alternative method of data encoding and obfuscation technique such as IP address encoding. (See related guideline section)", "Test your path decoding process against malicious input.", "In the case of path traversals, use the principle of least privilege when determining access rights to file systems. Do not allow users to access directories/files that they should not access.", "Assume all input is malicious. Create a white list that defines all valid input to the application based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system."]}, {"name": "Buffer Overflow in an API Call", "prerequisites": ["The target host exposes an API to the user.", "One or more API functions exposed by the target host has a buffer overflow vulnerability."], "summary": ["This attack targets libraries or shared code modules which are vulnerable to buffer overflow attacks. An attacker who has access to an API may try to embed malicious code in the API function call and exploit a buffer overflow vulnerability in the function's implementation. All clients that make use of the code library thus become vulnerable by association. This has a very broad effect on security across a system, usually affecting more than one software process."], "related_weakness": ["120", "119", "118", "74", "20", "680", "733", "697"], "id": "8", "solutions": ["Use a language or compiler that performs automatic bounds checking.", "Use secure functions not vulnerable to buffer overflow.", "If you have to use dangerous functions, make sure that you do boundary checking.", "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.", "Use OS-level preventative functionality. Not a complete solution."]}, {"name": "Using UTF-8 Encoding to Bypass Validation Logic", "prerequisites": ["The application's UTF-8 decoder accepts and interprets illegal UTF-8 characters or non-shortest format of UTF-8 encoding.", "Input filtering and validating is not done properly leaving the door open to harmful characters for the target host."], "summary": ["This attack is a specific variation on leveraging alternate encodings to bypass validation logic. This attack leverages the possibility to encode potentially harmful input in UTF-8 and submit it to applications not expecting or effective at validating this encoding standard making input filtering difficult. UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. Legal UTF-8 characters are one to four bytes long. However, early version of the UTF-8 specification got some entries wrong (in some cases it permitted overlong characters). UTF-8 encoders are supposed to use the \"shortest possible\" encoding, but naive decoders may accept encodings that are longer than necessary. According to the RFC 3629, a particularly subtle form of this attack can be carried out against a parser which performs security-critical validity checks against the UTF-8 encoded form of its input, but interprets certain illegal octet sequences as characters."], "related_weakness": ["173", "172", "180", "181", "171", "73", "21", "74", "20", "697", "692"], "id": "80", "solutions": ["The Unicode Consortium recognized multiple representations to be a problem and has revised the Unicode Standard to make multiple representations of the same code point with UTF-8 illegal. The UTF-8 Corrigendum lists the newly restricted UTF-8 range (See references). Many current applications may not have been revised to follow this rule. Verify that your application conform to the latest UTF-8 encoding specification. Pay extra attention to the filtering of illegal characters.", "Another consideration is error recovery. To guarantee correct recovery after corrupt or lost bytes, decoders must be able to recognize the difference between lead and trail bytes, rather than just assuming that bytes will be of the type allowed in their position.", "For security reasons, a UTF-8 decoder must not accept UTF-8 sequences that are longer than necessary to encode a character. If you use a parser to decode the UTF-8 encoding, make sure that parser filter the invalid UTF-8 characters (invalid forms or overlong forms).", "Look for overlong UTF-8 sequences starting with malicious pattern. You can also use a UTF-8 decoder stress test to test your UTF-8 parser (See Markus Kuhn's UTF-8 and Unicode FAQ in reference section)", "Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system. Test your decoding process against malicious input."]}, {"name": "Web Logs Tampering", "prerequisites": ["Target server software must be a HTTP server that performs web logging."], "summary": ["Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to \"Log Injection-Tampering-Forging\" except that in this case, the attack is targeting the logs of the web server and not the application."], "related_weakness": ["117", "93", "92", "221", "96", "20", "150", "276", "279", "116", "713"], "id": "81", "solutions": ["Design: Use input validation before writing to web log", "Design: Validate all log data before it is output"]}, {"name": "XPath Injection", "prerequisites": ["XPath queries used to retrieve information stored in XML documents", "User-controllable input not properly sanitized before being used as part of XPath queries"], "summary": ["An attacker can craft special user-controllable input consisting of XPath expressions to inject the XML database and bypass authentication or glean information that he normally would not be able to. XPath Injection enables an attacker to talk directly to the XML database, thus bypassing the application completely. XPath Injection results from the failure of an application to properly sanitize input used as part of dynamic XPath expressions used to query an XML database. In order to successfully inject XML and retrieve information from a database, an attacker:"], "related_weakness": ["91", "74", "20", "390", "713", "707"], "id": "83", "solutions": ["Strong input validation - All user-controllable input must be validated and filtered for illegal characters as well as content that can be interpreted in the context of an XPath expression. Characters such as a single-quote(') or operators such as or (|), and (&) and such should be filtered if the application does not expect them in the context in which they appear. If such content cannot be filtered, it must at least be properly escaped to avoid them being interpreted as part of XPath expressions.", "Use of parameterized XPath queries - Parameterization causes the input to be restricted to certain domains, such as strings or integers, and any input outside such domains is considered invalid and the query fails.", "Use of custom error pages - Attackers can glean information about the nature of queries from descriptive error messages. Input validation must be coupled with customized error pages that inform about an error without disclosing information about the database or application."]}, {"name": "AJAX Fingerprinting", "prerequisites": ["The user must allow JavaScript to execute in their browser"], "summary": ["This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. In many XSS attacks the attacker must get a \"hole in one\" and successfully exploit the vulnerability on the victim side the first time, once the client is redirected the attacker has many chances to engage in follow on probes, but there is only one first chance. In a widely used web application this is not a major problem because 1 in a 1,000 is good enough in a widely used application.", "A common first step for an attacker is to footprint the environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on."], "related_weakness": ["79", "113", "348", "96", "20", "116", "184", "86", "712", "692"], "id": "85", "solutions": ["Design: Use browser technologies that do not allow client side scripting.", "Design: Utilize strict type, character, and encoding enforcement", "Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.", "Implementation: Perform input validation for all remote content.", "Implementation: Perform output validation for all remote content.", "Implementation: Disable scripting languages such as JavaScript in browser", "Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this."]}, {"name": "Embedding Script (XSS) in HTTP Headers", "prerequisites": ["Target software must be a client that allows scripting communication from remote hosts, and attacker must control a remote site of some sort to redirect client and data to."], "summary": ["An attack of this type exploits web applications that generate web content, such as links in a HTML page, based on unvalidated or improperly validated data submitted by other actors. XSS in HTTP Headers attacks target the HTTP headers which are hidden from most users and may not be validated by web applications."], "related_weakness": ["79", "184", "348", "96", "20", "116", "86", "692", "697", "713", "71"], "id": "86", "solutions": ["Design: Use browser technologies that do not allow client side scripting.", "Design: Utilize strict type, character, and encoding enforcement", "Design: Server side developers should not proxy content via XHR or other means, if a http proxy for remote content is setup on the server side, the client's browser has no way of discerning where the data is originating from.", "Implementation: Ensure all content that is delivered to client is sanitized against an acceptable content specification.", "Implementation: Perform input validation for all remote content.", "Implementation: Perform output validation for all remote content.", "Implementation: Disable scripting languages such as JavaScript in browser", "Implementation: Session tokens for specific host", "Implementation: Patching software. There are many attack vectors for XSS on the client side and the server side. Many vulnerabilities are fixed in service packs for browser, web servers, and plug in technologies, staying current on patch release that deal with XSS countermeasures mitigates this."]}, {"name": "OS Command Injection", "prerequisites": ["User controllable input used as part of commands to the underlying operating system."], "summary": ["In this type of an attack, an adversary injects operating system commands into existing application functions. An application that uses untrusted input to build command strings is vulnerable. An adversary can leverage OS command injection in an application to elevate privileges, execute arbitrary commands and compromise the underlying operating system."], "related_weakness": ["78", "88", "20", "697", "713"], "id": "88", "solutions": ["Use language APIs rather than relying on passing data to the operating system shell or command line. Doing so ensures that the available protection mechanisms in the language are intact and applicable.", "Filter all incoming data to escape or remove characters or strings that can be potentially misinterpreted as operating system or shell commands", "All application processes should be run with the minimal privileges required. Also, processes must shed privileges as soon as they no longer require them."]}, {"name": "Buffer Overflow in Local Command-Line Utilities", "prerequisites": ["The target host exposes a command-line utility to the user.", "The command-line utility exposed by the target host has a buffer overflow vulnerability that can be exploited."], "summary": ["This attack targets command-line utilities available in a number of shells. An attacker can leverage a vulnerability found in a command-line utility to escalate privilege to root."], "related_weakness": ["120", "118", "119", "74", "20", "680", "733", "697"], "id": "9", "solutions": ["Carefully review the service's implementation before making it available to user. For instance you can use manual or automated code review to uncover vulnerabilities such as buffer overflow.", "Use a language or compiler that performs automatic bounds checking.", "Use an abstraction library to abstract away risky APIs. Not a complete solution.", "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.", "Operational: Use OS-level preventative functionality. Not a complete solution.", "Apply the latest patches to your user exposed services. This may not be a complete solution, especially against a zero day attack.", "Do not unnecessarily expose services."]}, {"name": "XSS in IMG Tags", "prerequisites": ["Application permitting the inclusion or use of IMG tags"], "summary": ["Image tags are an often overlooked, but convenient, means for a Cross Site Scripting attack. The attacker can inject script contents into an image (IMG) tag in order to steal information from a victim's browser and execute malicious scripts."], "related_weakness": ["82", "79", "74", "20", "692", "697", "713", "71"], "id": "91", "solutions": ["In addition to the traditional input fields, all other user controllable inputs, such as image tags within messages or the likes, must also be subjected to input validation. Such validation should ensure that content that can be potentially interpreted as script by the browser is appropriately filtered.", "All output displayed to clients must be properly escaped. Escaping ensures that the browser interprets special scripting characters literally and not as script to be executed."]}, {"name": "XML Parser Attack", "prerequisites": ["An application uses an XML parser to perform transformation on user-controllable data.", "An application does not perform sufficient validation to ensure that user-controllable data is safe for an XML parser."], "summary": ["Applications often need to transform data in and out of the XML format by using an XML parser. It may be possible for an attacker to inject data that may have an adverse effect on the XML parser when it is being processed. These adverse effects may include the parser crashing, consuming too much of a resource, executing too slowly, executing code supplied by an attacker, allowing usage of unintended system functionality, etc. An attacker's goal is to leverage parser failure to his or her advantage. In some cases it may be possible to jump from the data plane to the control plane via bad data being passed to an XML parser. [R.99.1]"], "related_weakness": ["112", "20", "19", "674", "770"], "id": "99", "solutions": ["Carefully validate and sanitize all user-controllable data prior to passing it to the XML parser routine. Ensure that the resultant data is safe to pass to the XML parser.", "Perform validation on canonical data.", "Pick a robust implementation of an XML parser.", "Validate XML against a valid schema or DTD prior to parsing."]}, {"name": "Buffer Overflow via Environment Variables", "prerequisites": ["The application uses environment variables.", "An environment variable exposed to the user is vulnerable to a buffer overflow.", "The vulnerable environment variable uses untrusted data.", "Tainted data used in the environment variables is not properly validated. For instance boundary checking is not done before copying the input data to a buffer."], "summary": ["This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables."], "related_weakness": ["120", "302", "118", "119", "74", "99", "20", "680", "733", "697"], "id": "10", "solutions": ["Do not expose environment variable to the user.", "Do not use untrusted data in your environment variables.", "Use a language or compiler that performs automatic bounds checking", "There are tools such as Sharefuzz [R.10.3] which is an environment variable fuzzer for Unix that support loading a shared library. You can use Sharefuzz to determine if you are exposing an environment variable vulnerable to buffer overflow."]}, {"name": "Subverting Environment Variable Values", "prerequisites": ["An environment variable is accessible to the user.", "An environment variable used by the application can be tainted with user supplied data.", "Input data used in an environment variable is not validated properly.", "The variables encapsulation is not done properly. For instance setting a variable as public in a class makes it visible and an attacker may attempt to manipulate that variable."], "summary": ["The attacker directly or indirectly modifies environment variables used by or controlling the target software. The attacker's goal is to cause the target software to deviate from its expected operation in a manner that benefits the attacker."], "related_weakness": ["353", "285", "302", "74", "15", "73", "20", "200"], "id": "13", "solutions": ["Protect environment variables against unauthorized read and write access.", "Protect the configuration files which contain environment variables against illegitimate read and write access.", "Assume all input is malicious. Create a white list that defines all valid input to the software system based on the requirements specifications. Input that does not match against the white list should not be permitted to enter into the system.", "Apply the least privilege principles. If a process has no legitimate reason to read an environment variable do not give that privilege."]}, {"name": "Format String Injection", "prerequisites": ["The target application must accept a strings as user input, fail to sanitize string formatting characters in the user input, and process this string using functions that interpret string formatting characters."], "summary": ["An attacker includes formatting characters in a string input field on the target application. Most applications assume that users will provide static text and may respond unpredictably to the presence of formatting character. For example, in certain functions of the C programming languages such as printf, the formatting character %s will print the contents of a memory location expecting this location to identify a string and the formatting character %n prints the number of DWORD written in the memory. An attacker can use this to read or write to memory locations or files, or simply to manipulate the value of the resulting text in unexpected ways. Reading or writing memory may result in program crashes and writing memory could result in the execution of arbitrary code if the attacker can write to the program stack."], "related_weakness": ["134", "20", "74", "133"], "id": "135", "solutions": ["Limit the usage of formatting string functions.", "Strong input validation - All user-controllable input must be validated and filtered for illegal formatting characters."]}, {"name": "LDAP Injection", "prerequisites": ["The target application must accept a string as user input, fail to sanitize characters that have a special meaning in LDAP queries in the user input, and insert the user-supplied string in an LDAP query which is then processed."], "summary": ["An attacker manipulates or crafts an LDAP query for the purpose of undermining the security of the target. Some applications use user input to create LDAP queries that are processed by an LDAP server. For example, a user might provide their username during authentication and the username might be inserted in an LDAP query during the authentication process. An attacker could use this input to inject additional commands into an LDAP query that could disclose sensitive information. For example, entering a * in the aforementioned query might return information about all users on the system. This attack is very similar to an SQL injection attack in that it manipulates a query to gather additional information or coerce a particular return value."], "related_weakness": ["77", "90", "20"], "id": "136", "solutions": ["Strong input validation - All user-controllable input must be validated and filtered for illegal characters as well as LDAP content.", "Use of custom error pages - Attackers can glean information about the nature of queries from descriptive error messages. Input validation must be coupled with customized error pages that inform about an error without disclosing information about the LDAP or application."]}, {"name": "Relative Path Traversal", "prerequisites": ["The target application must accept a string as user input, fail to sanitize combinations of characters in the input that have a special meaning in the context of path navigation, and insert the user-supplied string into path navigation commands."], "summary": ["An attacker exploits a weakness in input validation on the target by supplying a specially constructed path utilizing dot and slash characters for the purpose of obtaining access to arbitrary files or resources. An attacker modifies a known path on the target in order to reach material that is not available through intended channels. These attacks normally involve adding additional path separators (/ or \\) and/or dots (.), or encodings thereof, in various combinations in order to reach parent directories or entirely separate trees of the target's directory structure."], "related_weakness": ["22", "20"], "id": "139", "solutions": ["Design: Input validation. Assume that user inputs are malicious. Utilize strict type, character, and encoding enforcement", "Implementation: Perform input validation for all remote content, including remote and user-generated content.", "Implementation: Validate user input by only accepting known good. Ensure all content that is delivered to client is sanitized against an acceptable content specification -- whitelisting approach.", "Implementation: Prefer working without user input when using file system calls", "Implementation: Use indirect references rather than actual file names.", "Implementation: Use possible permissions on file access when developing and deploying web applications."]}, {"name": "Client-side Injection-induced Buffer Overflow", "prerequisites": ["The targeted client software communicates with an external server.", "The targeted client software has a buffer overflow vulnerability."], "summary": ["This type of attack exploits a buffer overflow vulnerability in targeted client software through injection of malicious content from a custom-built hostile service."], "related_weakness": ["120", "353", "118", "119", "74", "20", "680", "697", "713"], "id": "14", "solutions": ["The client software should not install untrusted code from a non-authenticated server.", "The client software should have the latest patches and should be audited for vulnerabilities before being used to communicate with potentially hostile servers.", "Perform input validation for length of buffer inputs.", "Use a language or compiler that performs automatic bounds checking.", "Use an abstraction library to abstract away risky APIs. Not a complete solution.", "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.", "Ensure all buffer uses are consistently bounds-checked.", "Use OS-level preventative functionality. Not a complete solution."]}, {"name": "Variable Manipulation", "prerequisites": ["The targeted application must rely on external variables (e.g. environment variables) or user-controlled variables (e.g. call parameters) in such a way that malicious manipulation of them can subvert functionality."], "summary": ["An attacker manipulates variables used by an application to perform a variety of possible attacks. This can either be performed through the manipulation of function call parameters or by manipulating external variables, such as environment variables, that are used by an application. Changing variable values is usually undertaken as part of another attack; for example, a path traversal (inserting relative path modifiers) or buffer overflow (enlarging a variable value beyond an application's ability to store it)."], "related_weakness": ["471", "20"], "id": "171", "solutions": ["Design: Range, size and value and consistency verification for any arguments supplied to application from external sources and devise appropriate error response.", "Design: Ensure that variables that should not be manipulated by a user are not accessible to them."]}, {"name": "Server Side Include (SSI) Injection", "prerequisites": ["A web server that supports server side includes and has them enabled", "User controllable input that can carry include directives to the web server"], "summary": ["An attacker can use Server Side Include (SSI) Injection to send code to a web application that then gets executed by the web server. Doing so enables the attacker to achieve similar results to Cross Site Scripting, viz., arbitrary code execution and information disclosure, albeit on a more limited scale, since the SSI directives are nowhere near as powerful as a full-fledged scripting language. Nonetheless, the attacker can conveniently gain access to sensitive files, such as password files, and execute shell commands."], "related_weakness": ["97", "74", "20", "713"], "id": "101", "solutions": ["Set the OPTIONS IncludesNOEXEC in the global access.conf file or local .htaccess (Apache) file to deny SSI execution in directories that do not need them", "All user controllable input must be appropriately sanitized before use in the application. This includes omitting, or encoding, certain characters or strings that have the potential of being interpreted as part of an SSI directive", "Server Side Includes must be enabled only if there is a strong business reason to do so. Every additional component enabled on the web server increases the attack surface as well as administrative overhead"]}, {"name": "Cross Zone Scripting", "prerequisites": ["The target must be using a zone-aware browser."], "summary": ["An attacker is able to cause a victim to load content into their web-browser that bypasses security zone controls and gain access to increased privileges to execute scripting code or other web objects such as unsigned ActiveX controls or applets. This is a privilege elevation attack targeted at zone-based web-browser security. In a zone-based model, pages belong to one of a set of zones corresponding to the level of privilege assigned to that page. Pages in an untrusted zone would have a lesser level of access to the system and/or be restricted in the types of executable content it was allowed to invoke. In a cross-zone scripting attack, a page that should be assigned to a less privileged zone is granted the privileges of a more trusted zone. This can be accomplished by exploiting bugs in the browser, exploiting incorrect configuration in the zone controls, through a cross-site scripting attack that causes the attackers' content to be treated as coming from a more trusted page, or by leveraging some piece of system functionality that is accessible from both the trusted and less trusted zone. This attack differs from \"Restful Privilege Escalation\" in that the latter correlates to the inadequate securing of RESTful access methods (such as HTTP DELETE) on the server, while cross-zone scripting attacks the concept of security zones as implemented by a browser."], "related_weakness": ["250", "638", "285", "116", "20"], "id": "104", "solutions": ["Disable script execution.", "Ensure that sufficient input validation is performed for any potentially untrusted data before it is used in any privileged context or zone", "Limit the flow of untrusted data into the privileged areas of the system that run in the higher trust zone", "Limit the sites that are being added to the local machine zone and restrict the privileges of the code running in that zone to the bare minimum", "Ensure proper HTML output encoding before writing user supplied data to the page"]}, {"name": "Cross Site Scripting through Log Files", "prerequisites": ["The system uses a web based interface", "The system does not cleanse / validate user supplied data before writing it to logs", "Information from logs is displayed in a web based interface", "The web based log interface does not HTML output encode the log data prior to displaying it in the administrator console."], "summary": ["An attacker may leverage a system weakness where logs are susceptible to log injection to insert scripts into the system's logs. If these logs are later viewed by an administrator through a thin administrative interface and the log data is not properly HTML encoded before being written to the page, the attackers' scripts stored in the log will be executed in the administrative interface with potentially serious consequences. This attack pattern is really a combination of two other attack patterns: log injection and stored cross site scripting."], "related_weakness": ["79", "117", "74", "20"], "id": "106", "solutions": ["Cleanse all user supplied data before placing it in the logs. Reject all bad data. Ensure that the data is in the expected form.", "Use proper HTML output encoding techniques to strip the log data of potentially dangerous scripting characters before displaying it in the administrative console", "If possible, disable script execution in the administrative interface."]}, {"name": "Command Line Execution through SQL Injection", "prerequisites": ["The application does not properly validate data before storing in the database", "Backend application implicitly trusts the data stored in the database", "Malicious data is used on the backend as a command line argument"], "summary": ["An attacker uses standard SQL injection methods to inject data into the command line for execution. This could be done directly through misuse of directives such as MSSQL_xp_cmdshell or indirectly through injection of data into the database that would be interpreted as shell commands. Sometime later, an unscrupulous backend application (or could be part of the functionality of the same application) fetches the injected data stored in the database and uses this data as command line arguments without performing proper validation. The malicious data escapes that data plane by spawning new commands to be executed on the host."], "related_weakness": ["89", "74", "20", "78", "114"], "id": "108", "solutions": ["Disable MSSQL xp_cmdshell directive on the database", "Properly validate the data (syntactically and semantically) before writing it to the database.", "Do not implicitly trust the data stored in the database. Re-validate it prior to usage to make sure that it is safe to use in a given context (e.g. as a command line argument)."]}, {"name": "Object Relational Mapping Injection", "prerequisites": ["An application uses data access layer generated by an ORM tool or framework", "An application uses user supplied data in queries executed against the database", "The separation between data plane and control plane is not ensured, through either developer error or an underlying weakness in the data access layer code generation framework"], "summary": ["An attacker leverages a weakness present in the database access layer code generated with an Object Relational Mapping (ORM) tool or a weakness in the way that a developer used a persistence framework to inject his or her own SQL commands to be executed against the underlying database. The attack here is similar to plain SQL injection, except that the application does not use JDBC to directly talk to the database, but instead it uses a data access layer generated by an ORM tool or framework (e.g. Hibernate). While most of the time code generated by an ORM tool contains safe access methods that are immune to SQL injection, sometimes either due to some weakness in the generated code or due to the fact that the developer failed to use the generated access methods properly, SQL injection is still possible."], "related_weakness": ["20", "100", "89", "564"], "id": "109", "solutions": ["Remember to understand how to use the data access methods generated by the ORM tool / framework properly in a way that would leverage the built-in security mechanisms of the framework", "Ensure to keep up to date with security relevant updates to the persistence framework used within your application."]}, {"name": "SQL Injection through SOAP Parameter Tampering", "prerequisites": ["SOAP messages are used as a communication mechanism in the system", "SOAP parameters are not properly validated at the service provider", "The service provider does not properly utilize parameter binding when building SQL queries"], "summary": ["An attacker modifies the parameters of the SOAP message that is sent from the service consumer to the service provider to initiate a SQL injection attack. On the service provider side, the SOAP message is parsed and parameters are not properly validated before being used to access a database in a way that does not use parameter binding, thus enabling the attacker to control the structure of the executed SQL query. This pattern describes a SQL injection attack with the delivery mechanism being a SOAP message."], "related_weakness": ["89", "20"], "id": "110", "solutions": ["Properly validate and sanitize/reject user input at the service provider.", "Ensure that prepared statements or other mechanism that enables parameter binding is used when accessing the database in a way that would prevent the attackers' supplied data from controlling the structure of the executed query.", "At the database level, ensure that the database user used by the application in a particular context has the minimum needed privileges to the database that are needed to perform the operation. When possible, run queries against pre-generated views rather than the tables directly."]}], "references": ["http://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html", "http://blog.trendmicro.com/trendlabs-security-intelligence/cve-2017-5638-apache-struts-vulnerability-remote-code-execution/", "http://www.eweek.com/security/apache-struts-vulnerability-under-attack.html", "http://www.securityfocus.com/bid/96729", "https://arstechnica.com/security/2017/03/critical-vulnerability-under-massive-attack-imperils-high-impact-sites/", "https://cwiki.apache.org/confluence/display/WW/S2-045", "https://exploit-db.com/exploits/41570", "https://git1-us-west.apache.org/repos/asf?p=struts.git;a=commit;h=352306493971e7d5a756d61780d57a76eb1f519a", "https://git1-us-west.apache.org/repos/asf?p=struts.git;a=commit;h=6b8272ce47160036ed120a48345d9aa884477228", "https://github.com/mazen160/struts-pwn", "https://github.com/rapid7/metasploit-framework/issues/8064", "https://isc.sans.edu/diary/22169", "https://nmap.org/nsedoc/scripts/http-vuln-cve2017-5638.html", "https://packetstormsecurity.com/files/141494/S2-45-poc.py.txt", "https://support.lenovo.com/us/en/product_security/len-14200", "https://twitter.com/theog150/status/841146956135124993", "https://www.imperva.com/blog/2017/03/cve-2017-5638-new-remote-code-execution-rce-vulnerability-in-apache-struts-2/"], "Published": "2017-03-10T21:59:00.150-05:00", "vulnerable_configuration_cpe_2_2": ["cpe:/a:apache:struts:2.3.10", "cpe:/a:apache:struts:2.3.11", "cpe:/a:apache:struts:2.3.12", "cpe:/a:apache:struts:2.3.13", "cpe:/a:apache:struts:2.3.14", "cpe:/a:apache:struts:2.3.14.1", "cpe:/a:apache:struts:2.3.14.2", "cpe:/a:apache:struts:2.3.14.3", "cpe:/a:apache:struts:2.3.15", "cpe:/a:apache:struts:2.3.15.1", "cpe:/a:apache:struts:2.3.15.2", "cpe:/a:apache:struts:2.3.15.3", "cpe:/a:apache:struts:2.3.16", "cpe:/a:apache:struts:2.3.16.1", "cpe:/a:apache:struts:2.3.16.2", "cpe:/a:apache:struts:2.3.16.3", "cpe:/a:apache:struts:2.3.17", "cpe:/a:apache:struts:2.3.19", "cpe:/a:apache:struts:2.3.20", "cpe:/a:apache:struts:2.3.20.1", "cpe:/a:apache:struts:2.3.20.2", "cpe:/a:apache:struts:2.3.20.3", "cpe:/a:apache:struts:2.3.21", "cpe:/a:apache:struts:2.3.22", "cpe:/a:apache:struts:2.3.23", "cpe:/a:apache:struts:2.3.24", "cpe:/a:apache:struts:2.3.24.1", "cpe:/a:apache:struts:2.3.24.2", "cpe:/a:apache:struts:2.3.24.3", "cpe:/a:apache:struts:2.3.25", "cpe:/a:apache:struts:2.3.26", "cpe:/a:apache:struts:2.3.27", "cpe:/a:apache:struts:2.3.28", "cpe:/a:apache:struts:2.3.28.1", "cpe:/a:apache:struts:2.3.29", "cpe:/a:apache:struts:2.3.30", "cpe:/a:apache:struts:2.3.31", "cpe:/a:apache:struts:2.3.5", "cpe:/a:apache:struts:2.3.6", "cpe:/a:apache:struts:2.3.7", "cpe:/a:apache:struts:2.3.8", "cpe:/a:apache:struts:2.3.9", "cpe:/a:apache:struts:2.5.3", "cpe:/a:apache:struts:2.5.4", "cpe:/a:apache:struts:2.5.6", "cpe:/a:apache:struts:2.5.7", "cpe:/a:apache:struts:2.5.9", "cpe:/a:apache:struts:2.5", "cpe:/a:apache:struts:2.5.1", "cpe:/a:apache:struts:2.5.2", "cpe:/a:apache:struts:2.5.5", "cpe:/a:apache:struts:2.5.8", "cpe:/a:apache:struts:2.5.10"], "summary": "The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 mishandles file upload, which allows remote attackers to execute arbitrary commands via a #cmd= string in a crafted Content-Type HTTP header, as exploited in the wild in March 2017.", "cwe": "CWE-20", "id": "CVE-2017-5638", "vulnerable_configuration": [{"id": "cpe:2.3:a:apache:struts:2.3.10", "title": "cpe:2.3:a:apache:struts:2.3.10"}, {"id": "cpe:2.3:a:apache:struts:2.3.11", "title": "cpe:2.3:a:apache:struts:2.3.11"}, {"id": "cpe:2.3:a:apache:struts:2.3.12", "title": "Apache Software Foundation Struts 2.3.12"}, {"id": "cpe:2.3:a:apache:struts:2.3.13", "title": "cpe:2.3:a:apache:struts:2.3.13"}, {"id": "cpe:2.3:a:apache:struts:2.3.14", "title": "Apache Software Foundation Struts 2.3.14"}, {"id": "cpe:2.3:a:apache:struts:2.3.14.1", "title": "Apache Software Foundation Struts 2.3.14.1"}, {"id": "cpe:2.3:a:apache:struts:2.3.14.2", "title": "Apache Software Foundation Struts 2.3.14.2"}, {"id": "cpe:2.3:a:apache:struts:2.3.14.3", "title": "Apache Software Foundation Struts 2.3.14.3"}, {"id": "cpe:2.3:a:apache:struts:2.3.15", "title": "Apache Software Foundation Struts 2.3.15"}, {"id": "cpe:2.3:a:apache:struts:2.3.15.1", "title": "Apache Software Foundation Struts 2.3.15.1"}, {"id": "cpe:2.3:a:apache:struts:2.3.15.2", "title": "Apache Software Foundation Struts 2.3.15.2"}, {"id": "cpe:2.3:a:apache:struts:2.3.15.3", "title": "Apache Software Foundation Struts 2.3.15.3"}, {"id": "cpe:2.3:a:apache:struts:2.3.16", "title": "Apache Software Foundation Struts 2.3.16"}, {"id": "cpe:2.3:a:apache:struts:2.3.16.1", "title": "Apache Software Foundation Struts 2.3.16.1"}, {"id": "cpe:2.3:a:apache:struts:2.3.16.2", "title": "Apache Software Foundation Struts 2.3.16.2"}, {"id": "cpe:2.3:a:apache:struts:2.3.16.3", "title": "Apache Software Foundation Struts 2.3.16.3"}, {"id": "cpe:2.3:a:apache:struts:2.3.17", "title": "cpe:2.3:a:apache:struts:2.3.17"}, {"id": "cpe:2.3:a:apache:struts:2.3.19", "title": "cpe:2.3:a:apache:struts:2.3.19"}, {"id": "cpe:2.3:a:apache:struts:2.3.20", "title": "Apache Software Foundation Struts 2.3.20"}, {"id": "cpe:2.3:a:apache:struts:2.3.20.1", "title": "Apache Software Foundation Struts 2.3.20.1"}, {"id": "cpe:2.3:a:apache:struts:2.3.20.2", "title": "cpe:2.3:a:apache:struts:2.3.20.2"}, {"id": "cpe:2.3:a:apache:struts:2.3.20.3", "title": "cpe:2.3:a:apache:struts:2.3.20.3"}, {"id": "cpe:2.3:a:apache:struts:2.3.21", "title": "cpe:2.3:a:apache:struts:2.3.21"}, {"id": "cpe:2.3:a:apache:struts:2.3.22", "title": "cpe:2.3:a:apache:struts:2.3.22"}, {"id": "cpe:2.3:a:apache:struts:2.3.23", "title": "cpe:2.3:a:apache:struts:2.3.23"}, {"id": "cpe:2.3:a:apache:struts:2.3.24", "title": "cpe:2.3:a:apache:struts:2.3.24"}, {"id": "cpe:2.3:a:apache:struts:2.3.24.1", "title": "cpe:2.3:a:apache:struts:2.3.24.1"}, {"id": "cpe:2.3:a:apache:struts:2.3.24.2", "title": "cpe:2.3:a:apache:struts:2.3.24.2"}, {"id": "cpe:2.3:a:apache:struts:2.3.24.3", "title": "Apache Struts 2.3.24.3"}, {"id": "cpe:2.3:a:apache:struts:2.3.25", "title": "cpe:2.3:a:apache:struts:2.3.25"}, {"id": "cpe:2.3:a:apache:struts:2.3.26", "title": "cpe:2.3:a:apache:struts:2.3.26"}, {"id": "cpe:2.3:a:apache:struts:2.3.27", "title": "cpe:2.3:a:apache:struts:2.3.27"}, {"id": "cpe:2.3:a:apache:struts:2.3.28", "title": "Apache Software Foundation Struts 2.3.28"}, {"id": "cpe:2.3:a:apache:struts:2.3.28.1", "title": "Apache Struts 2.3.28.1"}, {"id": "cpe:2.3:a:apache:struts:2.3.29", "title": "cpe:2.3:a:apache:struts:2.3.29"}, {"id": "cpe:2.3:a:apache:struts:2.3.30", "title": "cpe:2.3:a:apache:struts:2.3.30"}, {"id": "cpe:2.3:a:apache:struts:2.3.31", "title": "Apache Software Foundation Struts 2.3.31"}, {"id": "cpe:2.3:a:apache:struts:2.3.5", "title": "cpe:2.3:a:apache:struts:2.3.5"}, {"id": "cpe:2.3:a:apache:struts:2.3.6", "title": "cpe:2.3:a:apache:struts:2.3.6"}, {"id": "cpe:2.3:a:apache:struts:2.3.7", "title": "Apache Software Foundation Struts 2.3.7"}, {"id": "cpe:2.3:a:apache:struts:2.3.8", "title": "Apache Software Foundation Struts 2.3.8"}, {"id": "cpe:2.3:a:apache:struts:2.3.9", "title": "cpe:2.3:a:apache:struts:2.3.9"}, {"id": "cpe:2.3:a:apache:struts:2.5.3", "title": "cpe:2.3:a:apache:struts:2.5.3"}, {"id": "cpe:2.3:a:apache:struts:2.5.4", "title": "cpe:2.3:a:apache:struts:2.5.4"}, {"id": "cpe:2.3:a:apache:struts:2.5.6", "title": "cpe:2.3:a:apache:struts:2.5.6"}, {"id": "cpe:2.3:a:apache:struts:2.5.7", "title": "cpe:2.3:a:apache:struts:2.5.7"}, {"id": "cpe:2.3:a:apache:struts:2.5.9", "title": "cpe:2.3:a:apache:struts:2.5.9"}, {"id": "cpe:2.3:a:apache:struts:2.5", "title": "Apache Struts 2.5"}, {"id": "cpe:2.3:a:apache:struts:2.5.1", "title": "Apache Software Foundation Struts 2.5.1"}, {"id": "cpe:2.3:a:apache:struts:2.5.2", "title": "Apache Software Foundation Struts 2.5.2"}, {"id": "cpe:2.3:a:apache:struts:2.5.5", "title": "Apache Software Foundation Struts 2.5.5"}, {"id": "cpe:2.3:a:apache:struts:2.5.8", "title": "Apache Software Foundation Struts 2.5.8"}, {"id": "cpe:2.3:a:apache:struts:2.5.10", "title": "Apache Software Foundation Struts 2.5.10"}]}