Protect Against SQL Attack Assertion

The Protect Against SQL Attack assertion allows you to configure the to help protect a web service against specific, common SQL injection threats. When added to a policy, this assertion inspects the request message for the specific patterns of characters or keywords that are associated with these potential SQL injection attacks. If a match is found in the message, then the request is blocked from further processing.
gateway90
The Protect Against SQL Attack assertion allows you to configure the
API Gateway
to help protect a web service against specific, common SQL injection threats. When added to a policy, this assertion inspects the request message for the specific patterns of characters or keywords that are associated with these potential SQL injection attacks. If a match is found in the message, then the request is blocked from further processing.
To learn about selecting the target message for this assertion, see Select a Target Message.
When scanning a message element (for example, with the Evaluate Request XPath or Evaluate Response XPath assertions), select the "Invasive SQL Attack Protection" option (the "standard" protection is not sufficient). (3) The assertion does not examine attachments to messages. Protection for attachments is provided by the optional Scan using Symantec Antivirus Assertion.
SQL Injections Detected
The Protect Against SQL Attack assertion will respond as follows to these SQL injections:
Injection Type
Desired Response
Assertion Response
Single Tick Only
Detect a parameter value in requests and inbound HTTP headers that consists of only one single tick ('); this can be used to initiate an injection attack.
Select the
Invasive SQL Injection Attack Protection
check box to check the entire message body (excluding HTTP headers) for these meta characters:
' # --
If any of the non-Invasive protection options are selected, only the text and CDATA portions of a message will be checked for the above characters.
Single Tick Start
Detect a parameter value in requests and inbound HTTP headers that start with a single tick ('); this can be used to initiate an injection attack.
Same as above.
SQL Commands
Detect and block any request message containing standard SQL commands, including ALTER DATABASE, ALTER TABLE, ALTER VIEW, CREATE DATABASE, CREATE PROCEDURE, CREATE SCHEMA, CREATE TABLE, CREATE VIEW, DELETE FROM, DROP DATABASE, DROP PROCEDURE, DROP TABLE, DROP VIEW.
The assertion does not search for any of the listed commands.
SQLServer 2000
Detect and block any request message containing the default stored procedures included with SQLServer 2000.
The assertion searches for EXEC procedure when MS SQL Server is enabled.
SQLTABLE
Detect SQL Server 2000 Master database default table names in request messages.
The assertion does not search for any specific table names.
Oracle
Detect and block any request message containing the system tables, default stored procedures, or factory passwords included with Oracle.
In the Oracle case, the assertion searches for the strings 'to_timestamp_tz', 'tz_offset', 'bfilename'. No search for other table names and or default stored procedures.
XML Entity
Expansion (encoded)
Detect and block any request message containing the "<!ENTITY" XML entity expansion sequence.
SOAP services scan for and deny any DOCTYPE declaration, so the ENTITY item will not pass. However, XML/REST services will let this pass.
XML Entity
Expansion (unencoded)
Detects and blocks any message containing an XML "<!ENTITY" element.
Run this rule on requests. When a match is found, log an event and reject the message
Same response as above — encoding '<' as '&lt;' does not change the
API Gateway
response.
SQLTABLE_Updated
Allow commonly used words in request messages such as: VIEWS, TABLES, ROUTINES, DOMAINS, PARAMETERS and COLUMNS.
No checking is done for any of these SQL keywords.
Using the Assertion
  1. Do one of the following:
    • To add the assertion to the Policy Development window, see Add an Assertion.
    • To change the configuration of an existing assertion, proceed to step 2 below.
  2. When adding the assertion, the 
    SQL Attack Protection Properties
     automatically appear; when modifying the assertion, right-click 
    <target>:
     Protect against SQL Attack 
    in the policy window and select 
    SQL Attack Protection Properties
     or double-click the assertion in the policy window. The assertion properties are displayed. 
  3. Select the protection.
    WARNING:
    The following options are a minimal starting point for protecting against common SQL attacks. More effective protection with fewer false positives can be obtained by customizing the policy to the specific vulnerabilities of the service being protected. For example, the Validate XML Schema assertion can be used to block SQL metacharacters from only those elements that are known to be at risk of being misused by the back-end service. Each threat protection option requires a separate inspection of the request message; thus, selecting multiple options may increase the message processing time. Do not select the product-specific protections—MS SQL Server or Oracle exploit protection—unless the associated product is used by the protected service. 
    Setting
    Description
    Apply Protection to:
    Specify where to apply the protection:
    • URL Path:
      Select this to protect the URL Path.
    • URL Query String:
      Select this to protect the query parameters in the URL.
    • Body:
      Select this to protect the body of the message.
    Known MS SQL Server Exploits Protection
    Block messages that contain patterns recognized as potential MS SQL Server exploits.
    Known Oracle Exploit Protection
    Block messages that contain patterns recognized as potential Oracle SQL exploits
    Standard SQL Attack Protection
    Block messages that contain a single-quote ('), hash mark (#), or string (--) inside the element text or CDATA section (the characters are permitted in message attributes).
    This option effectively protects against many SQL injection attacks but may result in a small number of false positives. For example, a message containing the name "O'Reilly" will be rejected as a possible attack due to the " ' " character.
    If the service being protected is potentially vulnerable to altered XML attributes (for example, it uses XML attributes in SQL statements), then the Standard SQL Attack Protection may not be sufficient.
    Invasive SQL Attack Protection
    Block messages that contain a single-quote ('), hash mark (#), or string (--) anywhere within the message.
    This option effectively protects against many SQL injection attacks, but will result in a large number of false positives that cause messages to be incorrectly rejected. For example, any message containing a shorthand XPointer reference will be rejected, as will most messages containing signed XML (e.g., WSS Signature).
    The Invasive SQL Attack Protection option is a "catch all" approach that should only be used when a potentially vulnerable service must be well-protected and where lower performance and a higher false positive rate are acceptable.
  4. Click [
    OK
    ] when done.