Using the HTTP Malicious Pattern Detection Policy
Learn how to use regular expressions or Java markup tags in an HTTP Malicious Pattern Detection Policy to inspect messages for malicious content and to reject the messages, returning a fault, if a match is found.
For information about using policies in the context of the Community Manager developer portal, see Business Policies.
Table of Contents
- Introduction
- Creating a Malicious Pattern Detection Policy
- Configuring the Malicious Pattern Detection Policy
- Configuration Options
- Activating a policy
- Attaching a policy
- Resources
- HTTP Malicious Pattern Detection Policy: Use Cases
Introduction
The HTTP Malicious Pattern Detection Policy is used to inspect HTTP messages for content that could be considered dangerous to an API or web service. If the message content matches any of the expressions identified in the policy as potentially dangerous, the policy rejects the message and returns a fault.
Notes:
- This policy uses regular expressions to define the content that could be considered dangerous, that would warrant a message being rejected.
- Typical uses of this policy are for SQL injection detection or JavaScript detection.
Creating a Malicious Pattern Detection Policy
The first step in creating a policy is to define the basic policy information.
To add an operational policy
- Go to Workbench > Browse > Organization, and select Policies > Operational Policies. The Policies Summary is displayed.
- Click Add Policy.
- Choose the policy type and click Next.
- Specify a name (required) and description (optional) and click Finish. At the Completion Summary, click Close. The Add Policy Wizard creates a draft policy instance that you can then configure on the Policy Details page.
For more information, see Add Policy.
At this point, you've created the policy, but it doesn't do anything. The next step is to configure the policy details. See Configuring the Malicious Pattern Detection Policy below.
Configuring the Malicious Pattern Detection Policy
To configure your Malicious Pattern Detection policy, follow the steps below.
To configure the Malicious Pattern Detection policy:
- Create the policy as covered above.
- At the Policies Summary page, in the HTTP Malicious Pattern Detection Policy section, click Modify. The Modify HTTP Malicious Pattern Detection Policy page appears, as shown below.
- Configure your policy with a regular expression or JavaScript markup tags. For information about the options available, see Configuration Options.
Note: To get the most out of this policy, you'll need a good working knowledge of regular expressions. For more information, see Using Regular Expressions in Policies.
- Click Apply. The policy is saved.
Configuration Options
The policy includes the configuration options shown below.
- Inspect Headers
- Leave this box cleared.
- Inspect Path
- Check this box if you want the HTTP path to be scanned.
- Inspect Parameters
- Check this box if you want the HTTP query parameters to be scanned.
- Exclude Markup
- This option applies to content with markup such as XML or JSON. If markup is excluded, only the content of the properties, not the markup itself, will be scanned. For example, a JSON property name will not be scanned, just the property value.
- Patterns
- One or more regular expression patterns to scan for. Any match will cause the message to be rejected.
For examples of how you can configure these properties, see HTTP Malicious Pattern Detection Policy: Use Cases.
Activating a policy
When you create and configure a policy, the policy is in Draft state. When the policy configuration is complete, activate the policy: click Activate Policy and then confirm. See Activate a Policy.
A policy in Draft state is not available for general use. Once you activate the policy, it is in Active state and is available for use.
Attaching a policy
After you've saved and activated your policy, you can attach it:
- To an individual web service, to apply it to that service.
- At the Organization level, to apply it to all services defined within the organization.
Resources
To get the most out of this policy, you will need a good working knowledge of regular expressions. Some online tools:
- rubular.com is a free online regular expression editor based on Ruby.
- regex101.com is another useful free resource.
HTTP Malicious Pattern Detection Policy: Use Cases
This section includes the following examples:
Policy Example #1: detecting SQL injections
One example of using the Malicious Pattern Detection policy is to look for SQL injections and other attempts to query or change database tables.
Any input field (path parameter, query parameter, header) could potentially be used to send a database query, instead of a required request parameter. For example, a field expecting an integer could instead have an escape character and then a database SQL query.
For this example, first create the policy, following the procedure in Creating a Malicious Pattern Detection Policy above.
Then, follow the procedure in Configuring the Malicious Pattern Detection Policy above, and choose the following configuration settings:
- Inspect Headers: Check the box and specify the headers to be inspected. Add each header on a separate line. In this example: Authorization, Accept, Content-Type, Host.
- Inspect Path: Check this box.
- Inspect Parameters: Check this box.
- Exclude Markup: Leave the checkbox cleared.
- Patterns: Specify these three patterns, putting each on a separate line:
\w*(%27|')\s*(%6F|o|%4F)(%72|r|%52)
(%27|')\s*(union|select|insert|update|delete|join|merge|drop|alter|create)
exec(\s|\+)+(s|x)p\w+
Note: Regular expressions work only with certain content types. For example, you cannot use regular expressions with application/json or application/xml content. Use XPath only with XML payloads. Use JSONPath only with JSON messages. Use RegEx if the content type is neither XML nor JSON.
The policy configuration should look like the below:
Once you've saved the policy, you can activate it and then attach it to a service. In the example below, two separate HTTP Malicious Detection policies are attached to the service. One protects against JavaScript injections (see Policy Example #2: detecting JavaScript injections below), and one protects against SQL injections.
When malicious content is detected in a message, the platform returns an error, and the malicious content is rejected:
An alert is generated, as shown below.
Policy Example #2: detecting JavaScript injections
To configure this policy to detect JavaScript injections, follow the same configuration steps given in the previous example, but use the pattern below:
<\s*script\b[^>]*>[^<]+<\s*\/\s*script\s*>
