XML SQL injection check
XML的SQL注入ion check examines the user requests for possible XML SQL Injection attacks. If it finds injected SQL in XML payloads, it blocks the requests.
A XML SQL attack can inject source code into a web application such that it can be interpreted and executed as a valid SQL query to perform a database operation with malicious intent. For example, XML SQL attacks can be launched to gain unauthorized access to the contents of a database or to manipulate the stored data. XML SQL Injection attacks are not only common, but can also be very harmful and costly.
Compartmentalizing the privileges of the database users can assist in protecting the database to some extent. All database users should be given only the required privileges to complete their intended tasks, so that they cannot execute SQL queries to perform other tasks. For example, a read-only user should not be allowed to write or manipulate data tables. The Web App Firewall XML SQL Injection check inspects all XML requests to provide special defenses against injection of unauthorized SQL code that might break security. If the Web App Firewall detects unauthorized SQL code in any XML request of any user, it can block the request.
The Citrix Web App Firewall inspects the presence of SQL keywords and special characters to identify the XML SQL Injection attack. A default set of keywords and special characters provides known keywords and special characters that are commonly used to launch XML SQL attacks. The Web App Firewall considers three characters, single straight quote (‘), backslash (), and semicolon (;) as special characters for SQL security check processing. You can add new patterns, and you can edit the default set to customize the XML SQL check inspection.
The Web App Firewall offers various action options for implementing XML SQL Injection protection. You canBlockthe request,Loga message in the ns.log file with details regarding the observed violations, and collectStatsto keep track of the number of observed attacks.
In addition to actions, there are several parameters that can be configured for XML SQL injection processing. You can check forSQL wildcard characters. You can change the XML 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 XML payload. The XMLSQL Comments Handlingparameter gives you an option to specify the type of comments that need to be inspected or exempted during XML SQL Injection detection.
You can deploy relaxations to avoid false positives. The Web App Firewall XML SQL check is performed on the payload of the incoming requests, and attack strings are identified even if they are spread over multiple lines. The check looks for SQL Injection strings in theelementand theattributevalues. You can apply relaxations to bypass security check inspection under specified conditions. The logs and statistics can help you identify needed relaxations.
Action options
An action is applied when the XML SQL Injection check detects an SQL Injection attack string in the request. The following actions are available for configuring an optimized XML SQL Injection protection for your application:
Block—If you enable block, the block action is triggered only if the input matches the XML SQL injection type specification. For example, ifSQLSplCharANDKeywordis configured as the XML SQL injection type, a request is not blocked if it does not contain any key words, even if SQL special characters are detected in the payload. Such a request is blocked if the XML SQL injection type is set to eitherSQLSplChar, orSQLSplCharORKeyword.
Log—If you enable the log feature, the XML SQL Injection check generates log messages indicating the actions that it takes. If block is disabled, a separate log message is generated for each location (ELEMENT,ATTRIBUTE) in which the XML SQL violation was detected. However, only one message is generated when the request is blocked. 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.
XML SQL parameters
In addition to the block, log and stats actions, you can configure the following parameters for XML SQL Injection check:
Check for XML SQL wildcard Characters—Wild card characters can be used to broaden the selections of a structured query language (SQL-SELECT) statement. These wild card operators can be used in conjunction with就像andNOT 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 as the second and third character.
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 square bracket ([), and closing square 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 XML SQLwildcard charactercheck is different from the XML SQLspecial charactercheck. 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 inspected location 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 processed payload string to trigger SQL violation.
- SQL keyword—At least one of the specified SQL keywords must be present in the processed payload string 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 keyword or the special character string must be present in the payload to trigger the security check violation.
Tip
If you select the SQL Special Character option, the Web App Firewall skips strings 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 web sites at risk.
SQL comments handling—By default, the Web App Firewall parses and checks all comments in XML data for injected SQL commands. Many SQL servers ignore anything in a comment, even if preceded by an SQL special character. For faster processing, if your XML SQL server ignores comments, you can configure the Web App Firewall to skip comments when examining requests for injected SQL. The XML SQL comments handling options are:
- ANSI—Skip ANSI-format SQL comments, which are normally used by UNIX-based SQL databases.
- Nested—Skip nested SQL comments, which are normally used by Microsoft SQL Server.
- 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
In most cases, you should 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.
Relaxation rules
If your application requires you to bypass the XML SQL Injection inspection for a specific ELEMENT or ATTRIBUTE in the XML payload, you can configure a relaxation rule. The XML SQL Injection inspection relaxation rules have the following parameters:
- Name:You can use literal strings or regular expressions to configure the name of theELEMENTor theATTRIBUTE. The following expression exempts allELEMENTSbeginning with the stringPurchaseOrder_followed by a string of numbers that is at least two and no more than ten characters long:
Comment: “Exempt XML SQL Check for Purchase Order Elements”
XMLSQLInjection: "PurchaseOrder_[0-9A-Za-z]{2,10}" IsRegex: REGEX Location: ELEMENT State: ENABLED Note:The names are case sensitive. Duplicate entries are not allowed, but you can use capitalization of the names and differences in location to create similar entries. For example, each of the following relaxation rules is unique:
1) XMLSQLInjection: XYZ IsRegex: NOTREGEX Location: ELEMENT State: ENABLED 2) XMLSQLInjection: xyz IsRegex: NOTREGEX Location: ELEMENT State: ENABLED 3) XMLSQLInjection: xyz IsRegex: NOTREGEX Location: ATTRIBUTE State: ENABLED 4) XMLSQLInjection: XYZ IsRegex: NOTREGEX Location: ATTRIBUTE State: ENABLED - Location: You can specify the Location of the XML SQL Inspection exception in your XML payload. The optionELEMENTis selected by default. You can change it toATTRIBUTE.
- Comment:这是一个n optional field. You can use up to a 255 character string to describe the purpose of this relaxation Rule.
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 name that you want to add as an exception, and nothing else. Careless use of Regular Expressions 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 XML SQL Injection inspection would otherwise have blocked.
Using the command line to configure the XML SQL Injection Check
To configure XML 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 XML SQL Injection protections. You can enable the block, log, and stats action(s). Select the type of SQL attack pattern (key words, wildcard characters, special strings) you want to detect in the payloads. 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:
set appfw profile**-XMLSQLInjectionAction** (([block] [log] [stats]) | [none]) set appfw profile-XMLSQLInjectionCheckSQLWildChars (ON |OFF) set appfw profile-XMLSQLInjectionType ([SQLKeyword] | [SQLSplChar] | [SQLSplCharANDKeyword] | [SQLSplCharORKeyword]) set appfw profile-XMLSQLInjectionParseComments ([checkall] | [ansi|nested] | [ansinested])
To configure a SQL Injection relaxation rule by using the command line
Use the bind or unbind command to add or delete relaxation rules, as follows:
- bind appfw profile -XMLSQLInjection [isRegex (REGEX | NOTREGEX)] [-location ( ELEMENT | ATTRIBUTE )] –comment [-state ( ENABLED | DISABLED )] - unbind appfw profile -XMLSQLInjection Example:
> bind appfw profile test_profile -XMLSQLInjection "PurchaseOrder_[0-9A-Za-z]{2,15}" -isregex REGEX -location ATTRIBUTE > unbind appfw profile test_profile –XMLSQLInjection "PurchaseOrder_[0-9A-Za-z]{2,15}" -location ATTRIBUTE Using the GUI to configure the XMLSQL injection security check
In the GUI, you can configure the XML SQL Injection security check in the pane for the profile associated with your application.
To configure or modify the XML SQL Injection check by using the GUI
- Navigate toWeb App Firewall>Profiles, highlight the target profile, and clickEdit.
- In the Advanced Settings pane, 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 just want to enable or disable Block, Log, and Stats actions for XML SQL Injection, you can select or clear check boxes in the table, click OK, and then click Save and Close to close the Security Check pane.
b. If you want to configure additional options for this security check, double click XML SQL Injection, or select the row and clickAction Settings, to display the following options:
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 clickSaveandCloseto close the Security Check pane.
To configure a XML SQL Injection relaxation rule by using the GUI
- Navigate toWeb App Firewall>Profiles, highlight the target profile, and clickEdit.
- In theAdvanced Settingspane, clickRelaxation Rules.
- In the Relaxation Rules table, double-click theXML SQL Injectionentry, or select it and clickEdit.
- In theXML SQL Injection Relaxation Rulesdialogue box, performAdd,Edit,删除,Enable, orDisableoperations for relaxation rules.
To manage XML SQL Injection relaxation rules by using the visualizer
For a consolidated view of all the relaxation rules, you can highlight theXML SQL Injectionrow in the Relaxation Rules table, 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.
To view or customize the SQL Injection patterns by using the GUI:
You can use the GUI to view or customize the SQL patterns.
The default SQL patterns are specified inWeb App Firewall>Signatures>*Default Signatures. If you do not bind any signature object to your profile, the default SQL patterns specified in the Default Signatures object will be used by the profile for XML SQL Injection security check processing. The rules and patterns in the Default Signatures object are read-only. You cannot edit or modify them. If you want to modify or change these patterns, create a user-defined signature object by making a copy of the Default Signatures object and changing the SQL patterns. Use the user-defined signature object in the profile that processes the traffic for which you want to use these customized SQL patterns.
For more information, seeSignatures.
To view default SQL patterns:
a. Navigate toWeb App Firewall>Signatures, select*Default Signatures, and clickEdit. Then clickManage SQL/XSS Patterns.
The Manage SQL/XSS Paths table shows following four rows pertaining to SQL Injection:
Injection (not_alphanum, SQL)/ Keyword Injection (not_alphanum, SQL)/ specialstring Injection (not_alphanum, SQL)/ transformrules/transform Injection (not_alphanum, SQL)/ wildchar b. Select a row and clickManage Elementsto display the corresponding SQL patterns (keywords, special strings, transformation rules or the wildcard characters) used by the Web App Firewall SQL injection check.
To customize SQL Patterns:You can edit a user-defined signature object to customize the SQL key words, special strings, and wildcard characters. You can add new entries or remove the existing ones. You can modify the transformation rules for the SQL special strings.
a. Navigate toWeb App Firewall>Signatures, highlight the target user-defined signature, and clickEdit. ClickManage SQL/XSS Patternsto display theManage SQL/XSS paths表格
b. Select the target SQL row.
我点击。Manage Elements, toAdd,EditorRemovethe corresponding SQL element.
ii. ClickRemoveto remove the selected row.
Warning
You must be very careful when removing or modifying any default SQL element, or deleting the SQL path to remove the entire row. The signature rules as well as the XML SQL Injection security check rely on these elements for detecting SQL Injection attacks to protect your applications. Customizing the SQL patterns can make your application vulnerable to XML SQL attacks if the required pattern is removed during editing.
Using the log feature with the XML SQL injection check
当日志action is enabled, theXML SQL Injectionsecurity check violations are logged in the audit log asAPPFW_XML_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 XML Cross-Site Scripting violations:
> Shell > tail -f /var/log/ns.log | grep APPFW_XML_SQL 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 toWeb App Firewall>Profiles, select the target profile, and clickSecurity Checks. Highlight theXML SQL Injectionrow and clickLogs. When you access the logs directly from the XML 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 toSystem>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 toWeb App Firewall>Policies>Auditing. In the Audit Messages section, click theSyslog messageslink to display theSyslog Viewer, which displays all log messages, including other security check violation logs.
The XML based Syslog Viewer provides various filter options for selecting only the log messages that are of interest to you. To select log messages for theXML SQL Injectioncheck, filter by selectingAPPFWin the dropdown options forModule. TheEvent Typelist offers a rich set of options to further refine your selection. For example, if you select theAPPFW_XML_SQLcheck box and click the应用button, only log messages pertaining to theXML SQL 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, andClient IPappear below the log message. You can select any of these options to highlight the corresponding information in the log message.
Statistics for the XML SQL injection violations
When the stats action is enabled, the counter for theXML SQL Injection检查时增加Web应用防火墙达克es 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, a request for a page that contains threeXML SQL Injectionviolations increments the stats counter by one, because the page is blocked as soon as the first violation is detected. However, if 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.
通过u显示XML SQL注入检查统计数据sing 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 XML SQL Injection statistics by using the GUI
- Navigate toSystem>Security>Web App Firewall.
- In the right pane, access theStatisticsLink.
- Use the scroll bar to view the statistics aboutXML SQL Injectionviolations and logs. The statistics table provides real-time data and is updated every 7 seconds.