Duration : 15 mins
Persona : API Team / Security
You have an existing Apigee API proxy that takes requests from the internet and forwards them to an existing service. You have a requirement to ensure the integrity of the API message content, by protecting against threats such as JSON/XML/SQL injection and other malicious payload manipulation.
Message content is a significant attack vector used by malicious actors. Apigee Edge provides a set of out-of-the-box policies that help mitigate the potential for your backend services to be compromised by attackers or by malformed request payloads.
In this lab we will see how to use the following policies:
For this lab we will be using a mock target API. An initial Apigee API proxy has been created for you. Download the API proxy here.
Go to https://apigee.com/edge and log in. This is the Edge management UI.
Select Develop → API Proxies in the side navigation menu:
In the above example, we use the JSON Threat Protection policy to ensure that the incoming API request JSON payload does not contain more than 5 fields. If the incoming payload contains more than 5 fields, the API proxy returns an error response.
For a full list of JSON integrity checks that can be performed using this policy, see the [JSON Threat Protection policy documentation](https://docs.apigee.com/api-platform/reference/policies/json-threat-protection-policy#elementreference).
13. Click on **Save** to save the API Proxy changes:

## Test JSON Threat Protection:
1. To test the changes made, first click on **Trace** tab of the API proxy dashboard:

2. Click on **Start Trace Session** button to begin tracing:

3. Now, send a POST request to your API endpoint at **http://-.apigee.net/mock-target-api/echo** with the following format:
POST /mock-target-api/echo HTTP/1.1 Host: -.apigee.net Content-Type: application/json
{ “field1”: “test_value1”, “field2”: “test_value2”, “field3”: “test_value3”, “field4”: “test_value4”, “field5”: “test_value5”, “field6”: “test_value6” }
You can make this call either using a REST client like the one <a href="https://apigee-restclient.appspot.com/" target="_blank">here</a>, or using a terminal.
Example `curl` command:
curl -X POST “http://-.apigee.net/mock-target-api/echo” -H “Content-Type: application/json” -d ‘{“field1”: “test_value1”, “field2”: “test_value2”, “field3”: “test_value3”, “field4”: “test_value4”, “field5”: “test_value5”, “field6”: “test_value6”}’
* **Note:** If you are using a REST client, make sure that your HTTP request has a Header name/value pair of `Content-Type: application/json` as shown below

4. The response received will be an error, since we attempted to send more than 5 fields in the POST request payload.

On the Trace screen we also see that the JSON Threat Protection policy was triggered to return this error response:

5. You can now test for a successful API call, by sending the API endpoint a similar POST request, but this time with 5 or fewer fields in the JSON payload.
POST /mock-target-api/echo HTTP/1.1 Host: -.apigee.net Content-Type: application/json
{ “field1”: “test_value1”, “field2”: “test_value2”, “field3”: “test_value3”, “field4”: “test_value4”, “field5”: “test_value5” }
Again, you can make this call either using a REST client like the one [here](https://apigee-restclient.appspot.com/), or using a terminal.
Example `curl` command:
curl -X POST “http://-.apigee.net/mock-target-api/echo” -H “Content-Type: application/json” -d ‘{“field1”: “test_value1”, “field2”: “test_value2”, “field3”: “test_value3”, “field4”: “test_value4”, “field5”: “test_value5”}’
6. The response received will be a successful one, since we attempted to send fewer fields in the POST request payload:

On the Trace screen we also see that the JSON Threat Protection policy allowed the request to go through and hit the API target:

## Regular Expression Protection
### Add Protection Against SQL Injection Attacks
1. Click on the "**View IP address**" flow under **Proxy Endpoints → default**. Click on **+Step** on the upper right of the Request flow and attach a Regular Expression Protection policy.

2. Select **Regular Expression Protection** policy. Click on **Add** button to add the policy to the selected flow's request pipeline.

3. Select the policy to display the policy's XML configuration in the editor.

4. Change the policy's XML configuration to the below snippet to protect against SQL injections.
<?xml version=”1.0” encoding=”UTF-8” standalone=”yes”?>
In the above example, the Regular Expression Protection policy has been configured with a pattern that matches common SQL injection attacks. This pattern will be checked against the value of the query parameter named `query`, and if there is a match, the policy will return an error response. Note that the policy lets you check the pattern against all types of input parameters and body content.
For other sample patterns, reference the [Regular Expression Protection policy documentation](https://docs.apigee.com/api-platform/reference/policies/regular-expression-protection#abouttheregularexpressionprotectionpolicy-exampleblacklistpatterns).
5. Click on **Save** to save the API Proxy changes.

## Test Regular Expression Protection:
1. To test the changes made, first click on **Trace** tab of the API proxy dashboard, and click on **Start Trace Session** button.

2. Now, send a GET request to the API endpoint at **http://-.apigee.net/mock-target-api/ip?query=** with any of the following entries in the `query` parameter. Try out all of the entries, and see if you can determine what each attack is trying to do!
query=delete query=password’ OR 1=1 query=5; DROP TABLE USERS;
You can make this call either using a REST client like the one [here](https://apigee-restclient.appspot.com/), or using a terminal.
Example `curl` command:
curl “http://-.apigee.net/mock-target-api/ip?query=” ```
The response received will be an error, since we attempted to send a malicious attack that we have configured our policy to recognize:
We can also confirm from the Trace screen that the Regular Expression Protection policy was triggered to return this error response:
If you like to learn by watching, here are some short 4 minute videos on using the policies explained above:
Now that you have tried the JSON and Regular Expression Threat Protection policies, try out the XML Threat Protection policy that helps you check the API payload content integrity in the case of XML payloads.
That completes this hands-on lesson. In this simple lab you learned how to protect your APIs against payload content based threats.
Useful Apigee documentation links on Threat Protection policies -
Video on using Threat Protection policies in Apigee Edge
You may now proceed to Lab 4