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 developer portal, see Business Policies.
Table of Contents
- Creating a Malicious Pattern Detection Policy
- Configuring the Malicious Pattern Detection Policy
- Configuration Options
- Attaching the Policy
- HTTP Malicious Pattern Detection Policy: Use Cases
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.
- This policy uses regular expressions to define the content that could be considered dangerous, that would warrant a message being rejected.
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.
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.
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.
- 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.
Attaching the Policy
After you've saved 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.
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.
- debuggex.com provides a more sophisticated (and more complex) tool for building and validating regular expressions.
- 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: Leave the checkbox cleared.
- 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:
The policy configuration should look like the below:
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.