Are there pre-built, production-quality configurations for the XML, JSON, and Regex threat protection policies?

[#1]

If you are not a security expert, you would not know the potential exploits that could be prevented by proper use of these policies. Does Apigee provide a set of configurations crafted by experts that would catch known exploits?

[akoo · Accepted solution]

Hi Lee,

For Regex threat protection, our docs have a nice list of sample blacklist patterns. You can find this easiest by searching for 'blacklist patterns' on the below link:

http://apigee.com/docs/api-services/reference/regu...

For XML and JSON threat, there are samples in our documentation (http://apigee.com/docs/api-services/reference/xml-threat-protection-policy and http://apigee.com/docs/api-services/reference/json-threat-protection-policy), but due to the custom-nature of these policies, these will almost certainly need to be modified based on the XML/JSON backend that is being protected. In that sense, there are not pre-built configurations for these 2 policies that should be used out-of-the-box. The documentation explains the configurations well enough that necessary changes could be made.

[#3]

Knowledge of the threats posed by malformed payloads is important, but the most important attribute of a threat protection policy, in my opinion, is that it is consistent with the API it is protecting.

Take for instance a JSON request payload for collecting a payment:

{
    "processPayment": {
        "accountNumber": "1234567890",
        "totalAmount": 15.50,
        "taxAmount": 2.50,
        "currency": "USD",
        "description": "Dr. Who Season 1 HD",
        "source": {
            "type": "credit",
            "brand": "AMEX",
            "cvv": "2390",
            "expirationDate": "12/2016",
            "accountNumberEntryMode": "WebForm",
            "billingAddress": {
                "addressLine1": "123 Any Street",
                "addressLine2": "Suite 345",
                "cityName": "Lake Oswego",
                "stateCode": "OR",
                "countryCode": "USA",
                "postalCode": "97214",
                "postalCodeExtension": "3456"
            },
            "shippingAddress": {
                "addressLine1": "123 Any Street",
                "addressLine2": "Suite 345",
                "cityName": "Lake Oswego",
                "stateCode": "OR",
                "countryCode": "USA",
                "postalCode": "97214",
                "postalCodeExtension": "3456"
            },
            "cardHolderFirstName": "John",
            "cardHolderLastName": "Doe"
        }
    }
}

The JSON threat protection policy allows us to limit things like the maximum depth or nesting of sub-objects. My preference is to set this number to the maximum depth we supporting payloads on a given API. In this example a depth greater than 4 would be outside our specifications. Looking at other payloads we would then be able to come up with a max depth parameter for JSON payloads (ContainerDepth in the policy definition). Similarly, given we have a finite domain of field labels we can determine an upper limit for the maximum label length parameter (ObjectEntryNameLength). Using the same process we can look through our request payloads and arrive at a balanced set of parameters for JSON threat protection. Something like:

<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>5</ContainerDepth>
   <ObjectEntryCount>50</ObjectEntryCount>
   <ObjectEntryNameLength>64</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1024</StringValueLength>
</JSONThreatProtection>

Similar exercises would be undertaken for any XML payloads.