How-To : Add fault Handling in the shared flow ?

For any proxy, it is not possible to add the fault handling  in the shared flow and generate custom error message for the fault raised during the runtime in the sharedflow. However there is an indirect way in which you can do it.

The following example will show how to handle Fault and generate custom error message when a fault is raised for any security policy in the shared flow.

In the below example, we have added the Regular Expression Protection policy and Raise Fault Policy in the shared flow. In case of request failing the Regex protection, an appropriate custom error will be raised during the runtime, in the shared flow itself and therefore the current flow control will transfer to error flow and return the error message and no further policy processing occurs. All remaining processing Steps are bypassed, and the fault response is returned directly to the requesting app.

 

You can also use any other Security policy (e.g. JSON Threat Protection policyRegular Expression Protection policyXML Threat Protection policy etc) or throw custom errors for any request or response data and add the custom fault rule by using the error variables in the shared flows itself.

 

You can also attach the same shared flow in flow hooks to avoid manually adding the security policies in each of the Api proxy, after a Threat/ Vulnerability concerns have been identified for already deployed Api proxies. 

 

Here is how the below proxy with fault handling in shared flow is structured :

  1. SharedFlow 
    1. Regex Protection  Policy
    2. Raise Fault Policy
  2. Proxy Policies

 

Regex Protection Policy :  The below policy check for any "sql injection attack" in the query params in the request. Please make sure to set the variable 

Show More
'continueOnError="false"

 

 

 

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="RegexProtection">
    <DisplayName>RegexProtection</DisplayName>
    <Properties/>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <QueryParam name="query">
        <Pattern>[\s]*(?i)((delete)|(exec)|(drop\s*table)|(insert)|(shutdown)|(update)|(\bor\b))</Pattern>
    </QueryParam>
    <Source>request</Source>
</RegularExpressionProtection>

 

 

 

Raise Fault Policy : The below policy if executed, will transfer the control of the current flow to the error flow and block the further execution of the policies defined in the Api proxy and return the custom error message as defined below

 

 

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="RaiseFaultOnExploit">
    <DisplayName>RaiseFaultOnExploit</DisplayName>
    <Properties/>
    <FaultResponse>
        <Set>
            <Headers/>
            <Payload contentType="application/json">{"error":"SQL injection detected", "message":"Request validation failed "}</Payload>
            <StatusCode>400</StatusCode>
            <ReasonPhrase>Bad request</ReasonPhrase>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

 

 

Finally in the Shared Flows default, Add the following : 

 

 

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SharedFlow name="default">
    <Step>
        <Name>RegexProtection</Name>
    </Step>
    <Step>
        <Name>RaiseFaultOnExploit</Name>
        <Condition>regularexpressionprotection.RegexProtection.failed = true</Condition>
    </Step>
</SharedFlow>

 

 

 After the execution of the Regex Protection, the Raise fault policy will be executed if the below error variable is set to true.

Show More
"regularexpressionprotection.RegexProtection.failed" = true

 

Note : Make sure to add the Raise Fault policy only after the Policies that generate the fault errors or set the fault variables. For more information refer the Fault variables.

0 2 1,274
2 REPLIES 2

Thanks, Could you please provide a flow diagram of this solution (combination of flow hook and shared flow to block log4j request)

@tushards  can we use this same approch to ServiceCallout?

already tried below


<Step>
<Name>RF-RaiseCustomFault</Name>
<Condition>servicecallout.SC-Validation.failed = true</Condition>
</Step>