HTML SQL injection check

Many web applications have web forms that use SQL to communicate with relational database servers. Malicious code or a hacker can use an insecure web form to send SQL commands to the web server. The Web App Firewall HTML SQL Injection check provides special defenses against injection of unauthorized SQL code that might break security. If the Web App Firewall detects unauthorized SQL code in a user request, it either transforms the request, to render the SQL code inactive, or blocks the request. The Web App Firewall examines the request payload for injected SQL code in three locations: 1) POST body, 2) headers, and 3) cookies. To examine a query portion in requests for injected SQL code, please configure an application firewall profile setting ‘InspectQueryContentTypes’ for the specific content-types.

A default set of keywords and special characters provides known keywords and special characters that are commonly used to launch SQL attacks. You can add new patterns, and you can edit the default set to customize the SQL check inspection. The Web App Firewall offers various action options for implementing SQL Injection protection. In addition to theBlock,Log,StatsandLearnactions, the Web App Firewall profile also offers the option totransform SQL special charactersto render an attack harmless.

In addition to actions, there are several parameters that can be configured for SQL injection processing. You can check forSQL wildcard characters. You can change the SQL Injection type and select one of the 4 options (SQLKeyword,SQLSplChar,SQLSplCharANDKeyword,SQLSplCharORKeyword) to indicate how to evaluate the SQL keywords and SQL special characters when processing the payload. TheSQL Comments Handling parametergives you an option to specify the type of comments that need to be inspected or exempted during SQL Injection detection.

You can deploy relaxations to avoid false positives. The Web App Firewall learning engine can provide recommendations for configuring relaxation rules.

The following options are available for configuring an optimized SQL Injection protection for your application:

Block—The block action is triggered only if the input matches the SQL injection type specification. For example, ifSQLSplCharANDKeywordis configured as the SQL injection type, a request is not blocked if it contains no key words, even if SQL special characters are detected in the input. Such a request is blocked if the SQL injection type is set to eitherSQLSplChar, orSQLSplCharORKeyword.

Log—If you enable the log feature, the SQL Injection check generates log messages indicating the actions that it takes. If the block action is disabled, a separate log message is generated for each input field in which the SQL violation was detected. However, only one message is generated when the request is blocked. Similarly, one log message per request is generated for the transform operation, even when SQL special characters are transformed in multiple fields. You can monitor the logs to determine whether responses to legitimate requests are getting blocked. A large increase in the number of log messages can indicate attempts to launch an attack.

Stats如果启用,统计特性收集统计数据about violations and logs. An unexpected surge in the stats counter might indicate that your application is under attack. If legitimate requests are getting blocked, you might have to revisit the configuration to see if you need to configure new relaxation rules or modify the existing ones.

Learn—If you are not sure which SQL relaxation rules might be ideally suited for your application, you can use the learn feature to generate recommendations based on the learned data. The Web App Firewall learning engine monitors the traffic and provides SQL learning recommendations based on the observed values. To get optimal benefit without compromising performance, you might want to enable the learn option for a short time to get a representative sample of the rules, and then deploy the rules and disable learning.

Transform SQL special characters—The Web App Firewall considers three characters, Single straight quote (‘), Backslash(\), and Semicolon (;) as special characters for SQL security check processing. The SQL Transformation feature modifies the SQL Injection code in an HTML request to ensure that the request is rendered harmless. The modified HTML request is then sent to the server. All default transformation rules are specified in the /netscaler/default_custom_settings.xml file.

The transform operation renders the SQL code inactive by making the following changes to the request:

• Single straight quote (‘) to double straight quote (“).
• Backslash(\)to double backslash(\).
• Semicolon (;) is dropped completely.

These three characters (special strings) are necessary to issue commands to an SQL server. Unless an SQL command is prefaced with a special string, most SQL servers ignore that command. Therefore, the changes that the Web App Firewall performs when transformation is enabled prevent an attacker from injecting active SQL. After these changes are made, the request can safely be forwarded to your protected website. When web forms on your protected website can legitimately contain SQL special strings, but the web forms do not rely on the special strings to operate correctly, you can disable blocking and enable transformation to prevent blocking of legitimate web form data without reducing the protection that the Web App Firewall provides to your protected websites.

变换操作的独立工作SQL Injection Typesetting. If transform is enabled and the SQL Injection type is specified as the SQL keyword, SQL special characters are transformed even if the request does not contain any keywords.

Tip

You normally enable either transformation or blocking, but not both. If the block action is enabled, it takes precedence over the transform action. If you have blocking enabled, enabling transformation is redundant.

Check for SQL Wildcard Characters—Wild card characters can be used to broaden the selections of a SQL (SQL-SELECT) statement. These wild card operators can be used withLIKEandNOT LIKEoperators to compare a value to similar values. The percent (%), and underscore (_) characters are frequently used as wild cards. The percent sign is analogous to the asterisk (*) wildcard character used with MS-DOS and to match zero, one, or multiple characters in a field. The underscore is similar to the MS-DOS question mark (?) wildcard character. It matches a single number or character in an expression.

For example, you can use the following query to do a string search to find all customers whose names contain the D character.

SELECT * from customer WHERE name like “%D%”:

The following example combines the operators to find any salary values that have 0 in the second and third place.

SELECT * from customer WHERE salary like ‘_00%’:

Different DBMS vendors have extended the wildcard characters by adding extra operators. The Citrix Web App Firewall can protect against attacks that are launched by injecting these wildcard characters. The 5 default Wildcard characters are percent (%), underscore (_), caret (^), opening bracket ([), and closing bracket (]). This protection applies to both HTML and XML profiles.

The default wildcard chars are a list of literals specified in the*Default Signatures:

• %
• _
• ^
• [
• ]

Wildcard characters in an attack can be PCRE, like [^A-F]. The Web App Firewall also supports PCRE wildcards, but the literal wildcard chars above are sufficient to block most attacks.

Note:

The SQL wildcard character check is different from the SQL special character check. This option must be used with caution to avoid false positives.

Check Request Containing SQL Injection Type—The Web App Firewall provides 4 options to implement the desired level of strictness for SQL Injection inspection, based on the individual need of the application. The request is checked against the injection type specification for detecting SQL violations. The 4 SQL injection type options are:

• SQL Special Character and Keyword—Both an SQL keyword and an SQL special character must be present in the input to trigger SQL violation. This least restrictive setting is also the default setting.
• SQL Special Character—At least one of the special characters must be present in the input to trigger SQL violation.
• SQL key word—At least one of the specified SQL keywords must be present in the input to trigger an SQL violation. Do not select this option without due consideration. To avoid false positives, make sure that none of the keywords are expected in the inputs.
• SQL Special Character or Keyword—Either the key word or the special character string must be present in the input to trigger the security check violation.

Tip:

If you configure the Web App Firewall to check for inputs that contain an SQL special character, the Web App Firewall skips web form fields that do not contain any special characters. Since most SQL servers do not process SQL commands that are not preceded by a special character, enabling this option can significantly reduce the load on the Web App Firewall and speed up processing without placing your protected websites at risk.

SQL comments handling—By default, the Web App Firewall checks all SQL comments for injected SQL commands. Many SQL servers ignore anything in a comment, however, even if preceded by an SQL special character. For faster processing, if your SQL server ignores comments, you can configure the Web App Firewall to skip comments when examining requests for injected SQL. The SQL comments handling options are:

• ANSI—Skip ANSI-format SQL comments, which are normally used by UNIX-based SQL databases. For example:

  • – (Two Hyphens) - This is a comment that begins with two hyphens and ends with end of line.

  • {} - Braces (Braces enclose the comment. The { precedes the comment, and the } follows it. Braces can delimit single- or multiple-line comments, but comments cannot be nested)

  • /* */ : C style comments (Does not allow nested comments). Please note /*! */

  • MySQL Server supports some variants of C-style comments. These enable you to write code that includes MySQL extensions, but is still portable, by using comments of the following form:/*! MySQL-specific code */

  • . #: Mysql comments: This is a comment that begins with # character.

• Nested—Skip nested SQL comments, which are normally used by Microsoft SQL Server. For example; – (Two Hyphens), and/* */(Allows nested comments)
• ANSI/Nested—Skip comments that adhere to both the ANSI and nested SQL comment standards. Comments that match only the ANSI standard, or only the nested standard, are still checked for injected SQL.
• Check all Comments—Check the entire request for injected SQL without skipping anything. This is the default setting.

Tip

Usually, you must not choose the Nested or the ANSI/Nested option unless your back-end database runs on Microsoft SQL Server. Most other types of SQL server software do not recognize nested comments. If nested comments appear in a request directed to another type of SQL server, they might indicate an attempt to breach security on that server.

Check Request headers—Enable this option if, in addition to examining the input in the form fields, you want to examine the request headers for HTML SQL Injection attacks. If you use the GUI, you can enable this parameter in theAdvanced Settings->Profile Settingspane of the Web App Firewall profile.

Note:

If you enable the Check Request header flag, you might have to configure a relaxation rule for theUser-Agentheader. Presence of the SQL keywordlikeand SQL special character semi-colon (;) might trigger false positive and block requests that contain this header.Warning

If you enable both request header checking and transformation, any SQL special characters found in the headers are also transformed. The Accept, Accept-Charset, Accept-Encoding, Accept-Language, Expect, and User-Agent headers normally contain semicolons (;). Enabling both Request header checking and transformation simultaneously might cause errors.

InspectQueryContentTypes— Configure this option if you want to examine the request query portion for SQL Injection attacks for the specific content-types. If you use the GUI, you can configure this parameter in theAdvanced Settings->Profile Settingspane of the App Firewall profile.

SQL Fine grained Relaxations

网络App Firewall gives you an option to exempt a specific form field, header, or Cookie from the SQL Injection inspection check. You can completely bypass the inspection for one or more of these fields by configuring the relaxation rules for the SQL Injection check.

网络App Firewall allows you to implement tighter security by fine-tuning the relaxation rules. An application might require the flexibility to allow specific patterns, but configuring a relaxation rule to bypass the security inspection might make the application vulnerable to attacks, because the target field is exempted from inspection for any SQL attack patterns. SQL fine grained relaxation provides the option to allow specific patterns and block the rest. For example, the Web App Firewall currently has a default set of more than 100 SQL keywords. Because hackers can use these keywords in SQL Injection attacks, the Web App Firewall flags them as potential threats. You can relax one or more keywords that are considered safe for the specific location. The rest of the potentially dangerous SQL keywords are still checked for the target location and continue to trigger the security check violations. You now have much tighter control.

The commands used in relaxations have optional parameters forValue TypeandValue Expression. You can specify whether the value expression is a regular expression or a literal string. The value type can be left blank or you have an option to selectKeywordorSpecialStringorWildChar.

Warning:

Regular expressions are powerful. Especially if you are not thoroughly familiar with PCRE-format regular expressions, double-check any regular expressions you write. Make sure that they define exactly the URL that you want to add as an exception, and nothing else. Careless use of wildcards, and especially of the dot-asterisk (.*) metacharacter or wildcard combination, can have results that you do not want, such as blocking access to web content that you did not intend to block or allowing an attack that the HTML SQL Injection check would otherwise have blocked.

Points to Consider:

• Value expression is an optional argument. A field name might not have any value expression.
• A field name can be bound to multiple value expressions.
• Value expressions must be assigned a value type. The SQL value type can be: 1) Keyword, 2) SpecialString, or 3) WildChar.
• You can have multiple relaxation rules per field name/URL combination.

Using the Command Line to Configure the SQL Injection Check

To configure SQL Injection actions and other parameters by using the command line:

In the command line interface, you can use either theset appfw profilecommand or theadd appfw profilecommand to configure the SQL Injection protections. You can enable the block, learn, log, stats actions and specify whether you want to transform the special characters used in SQL Injection attack strings to disable the attack. Select the type of SQL attack pattern (key words, wildcard characters, special strings) you want to detect in the payloads, and indicate whether you want the Web App Firewall to also inspect the request Headers for SQL Injection violations. Use theunset appfw profilecommand to revert the configured settings back to their defaults. Each of the following commands sets only one parameter, but you can include multiple parameters in a single command:

• 设置应用程序防火墙配置文件“Parameter descriptions provided at the bottom of the page.”
• -SQLInjectionAction (([block] [learn] [log] [stats]) | [none])
• 设置应用程序防火墙配置文件“Parameter descriptions provided at the bottom of the page.”
• -SQLInjectionTransformSpecialChars (**ON** | OFF)
• 设置应用程序防火墙配置文件“Parameter descriptions provided at the bottom of the page.”
• -**SQLInjectionCheckSQLWildChars** (**ON** |**OFF**)
• 设置应用程序防火墙配置文件“Parameter descriptions provided at the bottom of the page.”
• ** -**SQLInjectionType** ([**SQLKeyword**] | [**SQLSplChar**] | [**SQLSplCharANDKeyword**] | [**SQLSplCharORKeyword**])
• 设置应用程序防火墙配置文件“Parameter descriptions provided at the bottom of the page.”
• -**SQLInjectionParseComments** ([**checkall**] | [**ansi|nested**] | [**ansinested**])
• **设置应用程序防火墙配置文件“Parameter descriptions provided at the bottom of the page.”
• -CheckRequestHeaders (ON | OFF)Parameter descriptions provided at the bottom of the page.
• - CheckRequestQueryNonHtml (ON | OFF)Parameter descriptions provided at the bottom of the page.

To configure a SQL Injection relaxation rule by using the command interface

Use the bind or unbind command to add or delete binding, as follows:

• bind appfw profile -SQLInjection [isRegex(REGEX| NOTREGE)] [-location ] [-valueType (Keywor|SpecialString|Wildchar) [][-isValueRegex (REGEX | NOTREGEX) ]]

• 解开appfw概要文件<名称> -SQLInjection <字符串> [-location ] [-valueTyp (Keyword|SpecialString|Wildchar) []]

Note:

You can find the list of SQL keywords from the default signature file contents by viewing the view signature object, which has list of SQL key words and SQL special characters.

Using the GUI to Configure the SQL Injection Security Check

In the GUI, you can configure the SQL Injection security check in the pane for the profile associated with your application.

To configure or modify the SQL Injection check by using the GUI

1. Navigate toApplication Firewall > Profiles, highlight the target profile, and clickEdit.
2. In theAdvanced Settingspane, clickSecurity Checks.

The security check table displays the currently configured action settings for all the security checks. You have 2 options for configuration:

a. If you want to enable or disable Block, Log, Stats, and Learn actions for HTML SQL Injection, you can select or clear check boxes in the table, clickOK, and then clickSave and Closeto close theSecurity Checkpane.

b. If you want to configure more options for this security check, double click HTML SQL Injection, or select the row and clickAction Settings, to display the following options:

Transform SQL Special character—Transform any SQL Special characters in the request.

Check for SQL Wildcard Characters—Consider SQL Wildcard characters in the payload to be attack patterns.

Check Request Containing—Type of SQL injection (SQLKeyword, SQLSplChar, SQLSplCharANDKeyword, or SQLSplCharORKeyword) to check.

SQL Comments Handling—Type of comments (Check All Comments, ANSI, Nested, or ANSI/Nested) to check.

After changing any of the above settings, clickOKto save the changes and return to the Security Checks table. You can proceed to configure other security checks if needed. ClickOKto save all the changes you have made in the Security Checks section, and then clickSave and Closeto close the Security Check pane.

To configure an SQL Injection relaxation rule by using the GUI

• Navigate toApplication Firewall>Profiles, highlight the target profile, and clickEdit.
• In theAdvanced Settingspane, clickRelaxation Rules.
• In the Relaxation Rules table, double-click theHTML SQL Injectionentry, or select it and clickEdit.
• In theHTML SQL Injection Relaxation Rulesdialogue box, performAdd,Edit,Delete,Enable, orDisableoperations for relaxation rules.

Note

When you add a new rule, theValue Expressionfield is not displayed unless you selectKeywordorSpecialStringorWildCharoption in theValue TypeField.

To manage SQL injection relaxation rules by using the visualizer

For a consolidated view of all the relaxation rules, you can highlight theHTML SQL Injectionrow and clickVisualizer. The visualizer for deployed relaxations offers you the option toAdda new rule orEditan existing one. You can alsoEnableorDisablea group of rules by selecting a node and clicking the corresponding buttons in the relaxation visualizer.

View or customize injection patterns by using the GUI

You can use the GUI to view or customize the injection patterns.

The default SQL patterns are specified in the default signatures file. If you do not bind any signature object to your profile, the default Injection patterns specified in the default signatures object will be used by the profile for the command injection security check processing. The rules and patterns, specified in the default signatures object, are read-only. You cannot edit or modify them. If you want to modify or change these patterns, make a copy of the default sSignatures object to create a User-Defined signature object. Make changes in the command injection patterns in the new User-defined signature object and use this signature object in your profile that is processing the traffic for which you want to use these customized patterns.

For more information, seeSignatures

To view the default injection patterns by using the GUI:

1. Navigate toApplication Firewall > Signatures, select*Default Signatures, and clickEdit.

1. ClickManage CMD/SQL/XSS patterns. TheManage SQL/cross-site scripting pathstable shows patterns pertaining to CMD/SQL/XS injection:

1. Select a row and clickManage Elementsto display the corresponding injection patterns (keywords, special strings, transformation rules or the wildcard characters) used by the Web App Firewall command injection check.

Using the Learn Feature with the SQL Injection Check

When the learn action is enabled, the Web App Firewall learning engine monitors the traffic and learns the triggered violations. You can periodically inspect these learned rules. After due consideration, you can deploy the learned rule as an SQL Injection relaxation rule.

SQL Injection Learning enhancement—An Web App Firewall learning enhancement was introduced in release 11.0 of the Citrix ADC software. To deploy fine grained SQL Injection relaxation, the Web App Firewall offers fine grained SQL Injection learning. The learning engine makes recommendations regarding the observed Value Type (keyword, SpecialString, Wildchar) and the corresponding Value expression observed in the input fields. In addition to checking the blocked requests to determine whether the current rule is too restrictive and needs to be relaxed, you can review the rules generated by the learning engine to determine which value type and value expressions are triggering violations and need to be addressed in the relaxation rules.

Important

网络App Firewall’s learning engine can distinguish only the first 128 bytes of the name. If a form has multiple fields with names that match for the first 128 bytes, the learning engine might not be able to distinguish between them. Similarly, the deployed relaxation rule might inadvertently relax all such fields from SQL Injection inspection.

NoteTo bypass the SQL check-in the User-Agent header, use the following relaxation rule:

bind appfw profile your_profile_name -SQLInjection User-Agent " .*" -location HEADER

To view or use learned data by using the command line interface

At the command prompt, type one of the following commands:

• show appfw learningdata SQLInjection
• rm appfw learningdata -SQLInjection [] [ ]
• 出口appfw learningdata < profilename > SQLInjection

To view or use learned data by using the GUI

1. Navigate toApplication Firewall > Profiles, highlight the target profile, and clickEdit.

2. In theAdvanced Settingspane, clickLearned Rules. You can select theHTML SQL Injectionentry in the Learned Rules table and double-click it to access the learned rules. You can deploy the learned rules or edit a rule before deploying it as a relaxation rule. To discard a rule, you can select it and click theSkipbutton. You can edit only one rule at a time, but you can select multiple rules to deploy or skip.

You also have the option to show a summarized view of the learned relaxations by selecting theHTML SQL Injectionentry in the Learned Rules table and clickingVisualizerto get a consolidated view of all the learned violations. The visualizer makes it easy to manage the learned rules. It presents a comprehensive view of the data on one screen and facilitates taking action on a group of rules with one click. The biggest advantage of the visualizer is that it recommends regular expressions to consolidate multiple rules. You can select a subset of these rules, based on the delimiter and Action URL. You can display 25, 50, or 75 rules in the visualizer, by selecting the number from a drop-down list. The visualizer for learned rules offers the option to edit the rules and deploy them as relaxations. Or you can skip the rules to ignore them.

Using the Log Feature with the SQL Injection Check

When the log action is enabled, the HTML SQL Injection security check violations are logged in the audit log asAPPFW_SQLviolations. The Web App Firewall supports both Native and CEF log formats. You can also send the logs to a remote syslog server.

To access the log messages by using the command line

Switch to the shell and tail the ns.logs in the/var/log/folder to access the log messages pertaining to the SQL Injection violations:

> Shell

# tail -f /var/log/ns.log | grep APPFW_SQL

Example of an HTML SQL Injection log message when the request is transformed

Jun 26 21:08:41  10.217.31.98 CEF:0|Citrix|Citrix ADC|NS11.0|APPFW|APPFW_SQL|6|src=10.217.253.62 geolocation=Unknown spt=54001 method=GET request=http://aaron.stratum8.net/FFC/login.php?login_name\=%27+or&passwd\=and+%3B&drinking_pref\=on&text_area\=select+*+from+%5C+%3B&loginButton\=ClickToLogin&as_sfid\=AAAAAAXjnGN5gLH-hvhTOpIySEIqES7BjFRs5Mq0fwPp-3ZHDi5yWlRWByj0cVbMyy-Ens2vaaiULKOcUri4OD4kbXWwSY5s7I3QkDsrvIgCYMC9BMvBwY2wbNcSqCwk52lfE0k%3D&as_fid\=feeec8758b41740eedeeb6b35b85dfd3d5def30c msg= Special characters seen in fields cn1=74 cn2=762 cs1=pr_ffc cs2=PPE1 cs3=9ztIlf9p1H7p6Xtzn6NMygTv/QM0002 cs4=ALERT cs5=2015 act=transformed 

Example of an HTML SQL Injection log message when the post request is blocked

Jun 26 21:30:34  10.217.31.98 CEF:0|Citrix|Citrix ADC|NS11.0|APPFW|APPFW_SQL|6|src=10.217.253.62 geolocation=Unknown spt=9459 method=POST request=http://aaron.stratum8.net/FFC/login_post.php msg=SQL Keyword check failed for field text_area\="(')" cn1=78 cn2=834 cs1=pr_ffc cs2=PPE1 cs3=eVJMMPtZ2XgylGrHjkx3rZLfBCI0002 cs4=ALERT cs5=2015 act=blocked 

Note

As part of the streaming changes in 10.5.e build (enhancement builds) and 11.0 build onwards, we now process the input data in blocks. RegEx pattern matching is now restricted to 4K for contiguous character string matching. With this change, the SQL violation log messages might include different information compared to the earlier builds. The keyword and special character in the input can be separated by many bytes. We now keep track of the SQL keywords and special strings when processing the data, instead of buffering the entire input value. In addition to the field name, the log message now includes the SQL keyword, or the SQL special character, or both the SQL keyword and the SQL special character, as determined by the configured setting. The rest of the input is no longer included in the log message, as shown in the following example:

Example:

In 10.5, when the Web App Firewall detects the SQL violation, the entire input string might be included in the log message, as shown below:

SQL Keyword check failed for field text=\"select a name from testbed1;(;)\".*

In the enhancement builds of 10.5.e that support request side streaming and 11.0 build onwards, we log only the field name, keyword, and special character (if applicable) in the log message, as shown below:

SQL Keyword check failed for field **text="select(;)"

This change is applicable to requests that contain application/x-www-form-urlencoded, or multipart/form-data, or text/x-gwt-rpc content-types. Log messages generated during processing ofJSONorXMLpayloads are not affected by this change.

To access the log messages by using the GUI

The Citrix GUI includes a useful tool (Syslog Viewer) for analyzing the log messages. You have multiple options for accessing the Syslog Viewer:

• Navigate to theApplication Firewall>Profiles, select the target profile, and clickSecurity Checks. Highlight theHTML SQL Injectionrow and clickLogs. When you access the logs directly from the HTML SQL Injection check of the profile, the GUI filters out the log messages and displays only the logs pertaining to these security check violations.
• You can also access the Syslog Viewer by navigating toCitrix ADC>System>Auditing. In the Audit Messages section, click theSyslog messageslink to display the Syslog Viewer, which displays all log messages, including other security check violation logs. This is useful for debugging when multiple security check violations might be triggered during request processing.
• Navigate toApplication Firewall>policies>Auditing. In the Audit Messages section, click theSyslog messageslink to display the Syslog Viewer, which displays all log messages, including other security check violation logs.

The HTML based Syslog Viewer provides various filter options for selecting only the log messages that are of interest to you. To select log messages for theHTML SQL Injectioncheck, filter by selectingAPPFWin the drop-down list options forModule. TheEvent Typelist offers a rich set of options to further refine your selection. For example, if you select theAPPFW_SQLcheck box and click theApplybutton, only log messages pertaining to theSQL Injectionsecurity check violations appear in the Syslog Viewer.

If you place the cursor in the row for a specific log message, multiple options, such asModule,Event Type,Event ID,Client IPand so forth. appear below the log message. You can select any of these options to highlight the corresponding information in the log message.

Click to Deployfunctionality is available only in the GUI. You can use the Syslog Viewer to not only view the logs but also to deploy HTML SQL Injection relaxation rules based on the log messages for the Web App Firewall security check violations. The log messages must be in CEF log format for this operation. Click to deploy functionality is available only for log messages that are generated by the block (or not block) action. You cannot deploy a relaxation rule for a log message about the transform operation.

To deploy a relaxation rule from the Syslog Viewer, select the log message. A check box appears in the upper right corner of theSyslog Viewer框选中的行。选中该复选框then select an option from the Action list to deploy the relaxation rule.Edit & Deploy,Deploy, andDeploy Allare available asActionoptions.

The SQL Injection rules that are deployed by using the Click to Deploy option do not include the fine grain relaxation recommendations.

To use Click to Deploy functionality in the GUI:

1. In the Syslog Viewer, selectApplication Firewallin theModuleoptions.
2. Select theAPP_SQLas theEvent Typeto filter corresponding log messages.
3. Select the check box to identify the rule to deploy.
4. Use theActiondrop-down list of options to deploy the relaxation rule.
5. Verify that the rule appears in the corresponding relaxation rule section.

Statistics for the SQL Injection violations

When the stats action is enabled, the counter for the SQL Injection check is incremented when the Web App Firewall takes any action for this security check. The statistics are collected for Rate and Total count for Traffic, Violations, and Logs. The size of an increment of the log counter can vary depending on the configured settings. For example, if the block action is enabled, the request for a page that contains 3 SQL Injection violations increments the stats counter by one, because the page is blocked as soon as the first violation is detected. However, if the block is disabled, processing the same request increments the statistics counter for violations and the logs by three, because each violation generates a separate log message.

To display SQL Injection check statistics by using the command line:

At the command prompt, type:

sh appfw stats

To display stats for a specific profile, use the following command:

> stat appfw profile

To display HTML SQL Injection statistics by using the GUI

1. Navigate toSystem>Security>Application Firewall.
2. In the right pane, access theStatisticsLink.
3. Use the scroll bar to view the statistics about HTML SQL Injection violations and logs. The statistics table provides real-time data and is updated every 7 seconds.

Highlights

Note the following points about the SQL Injection check:

• Built-in Support for SQL Injection Protection—The Citrix Web App Firewall protects against SQL Injection by monitoring a combination of SQL keywords and special characters in the form parameters. All SQL keywords, special characters, wildcard characters, and default transformation rules are specified in the /netscaler/default_custom_settings.xml file.
• Customization—You can change the default key words, special characters, wildcard characters, and transformation rules to customize the SQL security check inspection for the specific needs of your application. Make a copy of the default signature object, modify existing entries, or add new ones. Bind this signature object to your profile to make use of the customized configuration.
• Hybrid Security Model—Both signatures and deep security protections use the SQL/cross-site scripting patterns specified in the signature object that is bound to the profile. If no signature object is bound to the profile, the SQL/cross-site scripting patterns present in the default signature object are used.
• Transform—Note the following about the transform operation:
  • 变换操作的独立工作other SQL Injection action settings. If transform is enabled and the block, log, stats, and learn are all disabled, SQL special characters are transformed.
  • 当启用了SQL转换,用户请求are sent to the back end servers after the SQL special characters are transformed in non-block mode. If the block action is enabled, it takes precedence over the transform action. If the injection type is specified as SQL special character and the block is enabled, the request is blocked despite the transform action.
• Fine Grained Relaxation and Learning—Fine-tune the relaxation rule to relax a subset of SQL elements from security check inspection but detect the rest. The learning engine recommends a specific value type and value expressions based on the observed data.
• Click to Deploy—Select one, or multiple SQL violation log messages in the syslog viewer and deploy them as relaxation rules.