Applies To:

Show Versions Show Versions

Manual Chapter: Security Policy Violations
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Security policy violations (or just violations) occur when some aspect of a request or response does not comply with the security policy for a web application. This appendix describes each of the violations.
You can view detailed descriptions of each violation to learn what causes that type of violation, and the type of security risk it could be related to.
1.
On the Main tab, expand Application Security, point to Policy, then click Blocking.
The Policy Blocking Settings screen opens listing all the violations and blocking settings for the current policy.
1.
Click the icon preceding the violation you are interested in.
A popup screen shows the violation description, risks, and examples, if available.
Figure A.1 shows a portion of the Policy Blocking Settings screen, and Figure A.2 shows the description that you see when you click the icon for the Illegal file type violation.
The Application Security Manager reports RFC violations when the format of an HTTP request violates the HTTP RFCs. RFC documents are the general specifications that summarize the standards used across the Internet and networking engineering community. RFCs, as they are commonly known, are published by the International Engineering Task Force (IETF). For more information on RFCs, see http://www.ietf.org/rfc.
Table A.1 lists the RFC violations, describes the event that triggers the violation, and specifies the attack type (if one is associated with the violation). An attack type of None means the violation is associated with no one type of attack, but could be caused by multiple types.
Table A.1 RFC violations 
The cookie header in the request does not comply with the formatting standards as specified in the RFC for HTTP state management.
The content of the request contains encoding or formatting that represents an attempt to bypass attack signature detection.
The following subviolation checks can occur:
Directory traversals
The request includes directory traversal commands such as ../.
Multiple decoding n decoding passes
The URI or parameter values are encoded multiple times and may indicate an attack. You can set the number of decoding passes (2, 3, 4, or 5) at which to issue the violation.
%u decoding
The system performs Microsoft %u unicode decoding to check for various attacks.
IIS backslashes
The system normalizes backslashes to slashes to prevent attackers from requesting files.
IIS Unicode codepoints
The system handles the mapping of IIS-specific non-ASCII codepoints.
Bare byte decoding
The system detects ASCII bytes higher than 127.
Apache whitespace
The system detects the following characters in the URI: 0x09, 0x11, 0x12, and 0x13.
Bad unescape
The system detects illegal HEX encoding and reports unescaping errors (such as %RR).
The request does not comply with one of the following HTTP protocol compliance checks:
The request does not contain an HTTP header specified as mandatory by the security policy.
Access violations occur when an HTTP request tries to gain access to an area of a web application, and the system detects a reference to one or more entities that are not allowed (or are specifically disallowed) in the security policy. Table A.2 lists the access violations, describes the event that triggers the violation, and specifies the attack type (if one is associated with the violation). An attack type of None means the violation is associated with no one type of attack, but could be caused by multiple types.
Table A.2 Access violations 
The user is accessing the web application from a geographic location that is not allowed according to the security policy.
The system detected that the number of violations from the same user, session, or IP address within a certain time frame is above the threshold specified in the session tracking configuration.
The request is coming from an IP address that is listed in the IP Address Intelligence database (a continuously updated blacklist). The IP addresses in the database are associated with high risk, such as anonymous proxies, Tor exits, phishing proxies, botnets, and scanners.
The request is not legitimate and comes from a clicked link, embedded malicious HTML, or JavaScript in another application, and may involve transmission of unauthorized commands through an authenticated user. Cross-Site Request Forgery (CSRF) is suspected.
The system injects a CSRF session cookie into responses. If you configured an expiration time for CSRF protection, and the request was sent after the CSRF session cookie expired, the system issues this violation.
The incoming request references a file type that is not specified on the allowed file types list or is specified on the disallowed file types list in the security policy.
The server response contains an HTTP status code that is not defined in the security policy.
The incoming request includes a parameter that contains a meta character that is not allowed in the security policy.
The incoming request includes a URL that contains a meta character that is not allowed in the security policy.
The incoming request references a HTTP method that is not defined in the security policy.
The system checks that the request contains a session ID value that matches the session ID value that the server set for this session.
Illegal URL
(also called Non-existent URL)
The incoming request references a URL that is not specified on the allowed URLs list or is specified on the disallowed URLs list in the security policy.
The incoming request tried to access the web application without going through the login URL.
The incoming request is for an authenticated URL whose valid access time has passed.
The incoming request is larger than the buffer for the Security Enforcer parser. When the system receives a request that triggers this violation, it stops validating the request for other violations.
Length violations occur when an HTTP request contains an entity that exceeds the length setting that is defined in the security policy. Table A.3 lists the length violations, describes the event that triggers the violation, and specifies the attack type. Note that all length violations are buffer overflow attacks.
Table A.3 Length violations 
The incoming request includes a cookie header that exceeds the acceptable length as specified in the security policy.
The incoming request includes an HTTP header that exceeds the acceptable length as specified in the security policy.
The incoming request contains POST data whose length exceeds the acceptable length as specified in the security policy.
The incoming request contains a query string whose length exceeds the acceptable length as specified in the security policy.
The incoming request length exceeds the acceptable length as specified in the security policy.
The incoming request references a URL whose length exceeds the acceptable length as specified in the security policy.
Input violations occur when an HTTP request includes a parameter or header that contains data or information that does not match, or comply with, the security policy. Input violations most often occur when the security policy contains defined user-input parameters.
Table A.4 lists the input violations, describes the event that triggers the violation, and specifies the attack type (if one is associated with the violation). An attack type of None means the violation is associated with no one type of attack, but could be caused by multiple types.
Table A.4 Input violations 
Brute Force: Maximum login attempts are exceeded
The user attempted to upload a binary executable file, which is not allowed by the security policy.
The incoming request contains a character that does not comply with the encoding of the web application (the character set of the security policy), and the Security Enforcer cannot convert the character to the current encoding.
The incoming request contains a SOAP message in which there is an attachment that is not permitted by the security policy.
The incoming request contains a dynamic parameter whose value may have been changed illegally on the client side. If the change was legal, on the learning screen, you can change the parameter to one that is not dynamic.
The incoming request contains a parameter whose value is empty when it must contain a value.
The incoming request includes a header whose value contains a meta character that is not allowed in the security policy. Note that if you accept the meta character that caused the violation, the Application Security Manager updates the character set for header values to allow the meta character.
The incoming request includes a parameter, XML element, or JSON data whose value contains a meta character that is not allowed in the security policy. Note that if you accept the meta character that caused the violation, the Application Security Manager updates the character set values to allow the meta character.
The incoming request contains either too few or too many mandatory parameters on a flow. Note that only flows can contain mandatory parameters.
The incoming request contains a parameter that is not defined in the security policy.
The incoming request contains a parameter for which the data type does not match the data type that is defined in the security policy. This violation applies to user-input parameters, which may be defined in the security policy as either integer, alpha-numeric, decimal, phone, or email.
The incoming request contains a parameter whose value is not in the range of decimal or integer values defined in the security policy.
The incoming request contains a parameter whose value length does not match the value length that is defined in the security policy. Note that this violation is relevant only for user input parameters.
The incoming request contains a query string or POST data that is not allowed in a flow.
The request contains multiple parameters with the same name, and may indicate an HTTP parameter pollution attack. If this behavior is permitted, you can allow repeated occurrences when creating parameters.
The URL in the security policy is set to disallow the request either by matching a specific HTTP header or because the default is set to Disallow and no other header from the list was matched.
The incoming request contains a static parameter whose value is not defined in the security policy.
Parameter tampering. Also can result in various attacks, like injection flaws, buffer overflows, and breaking the business logic
JSON data does not comply with format settings
The incoming request contains JSON data that does not comply with the defense configuration in the security policys JSON profile (for example, the message size is too long or illegal meta characters occur in the parameter value).
Illegal request payload, data manipulation, buffer overflow, denial of service, and application functionality abuse
The incoming request contains XML data that is not well-formed, according to W3C standards.
The incoming multi-part request has a parameter that contains a binary NULL (0x00) value and the content-type header parameter type is binary when the parameter is defined in the security policy as user-input alpha-numeric.
Parameter value does not comply with regular expression
The incoming request contains an alphanumeric parameter value that does not match the expected pattern specified by the regular-expression field for that parameter.
The incoming request contains a SOAP method that is not permitted by the security policy.
The incoming request looks like it is from a non-human, automated source, or illegal web robot.
The request contains one of the following web services security errors:
Internal Error
Malformed Error
Certificate Expired
Certificate Error
Decryption Error
Encryption Error
Signing Error
Verification Error
Missing Timestamp
Invalid Timestamp
Expired Timestamp
Timestamp expiration is too far in the future
Unsigned Timestamp
The incoming request contains XML data that does not comply with the defense configuration in the XML profile.
XML data does not comply with schema or WSDL document
The incoming request contains XML data that does not match the schema file or WSDL document that is part of the XML profile.
Cookie violations occur when the cookie values in the HTTP request do not comply with the security policy. Cookie violations may indicate malicious attempts to hijack private information. Table A.5 lists the cookie violations and describes the event that triggers the violation. None of the cookie violations is associated with an attack type.
ASM Cookie Hijacking (also called Wrong message key)
The incoming request contains an Application Security Manager cookie that was created in another session.
The time stamp in the HTTP cookie is old, which indicates either the malicious reuse of an outdated cookie, or that a client has been idle for too long, or.
The incoming request contains an Application Security Manager cookie that has been modified or tampered with.
The domain cookies in the HTTP request do not match the original domain cookies, or are not defined as allowed modified domain cookies in the security policy.
Negative security violations occur when an incoming request contains a string pattern that matches an attack signature in one of the security policys attack signature sets, or when a response contains exposed user data, for example, a credit card number.
Table A.6 lists the negative security violations, describes the event that triggers the violation, and specifies the attack type (if one is associated with the violation).
The incoming request, or the response, contains a pattern that matches an attack signature.
Note: The Attack signature detected violation does not appear on the Requests screen for signatures that are in staging.
Attack type depends on which attack signature triggered the violation
Data Guard: Information leakage detected
The response contains sensitive user data. The Data Guard feature determines what data is considered sensitive (for details, see Protecting sensitive data).
If you see an Attack signature detected violation associated with a request, you can determine the type of attack that caused the violation.
1.
On the Main tab, expand Application Security, then click Reporting.
The Requests screen opens.
2.
3.
In the Requests List, click the illegal request. (A red flag indicates that the request is illegal.)
The screen displays the violations associated with the illegal request.
4.
If one of the violations listed is Attack signature detected, click that violation hyperlink.
A popup screen opens and shows the name of the attack signature that caused the violation.
5.
In the popup screen, click the signature name.
A new screen opens and shows details about the attack signature, including the attack type, with links to additional documentation.
On the Requests screen, you can filter the display of requests by attack type. An attack type is a category of security breach. Refer to Types of attacks that attack signatures detect, for descriptions of each attack type.
1.
On the Main tab, expand Application Security, then click Reporting.
The Requests screen opens.
2.
If the filter options are not visible, click Show Filter Details.
The screen displays the advanced filter options.
3.
For the Attack Type, select the type of attack by which to filter the list of requests.
4.
Click Go.
If you have illegal requests of that attack type, the screen displays them in the Requests List.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)