Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

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 5 2,407
5 REPLIES 5

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>

@tushards I have tried handling the spike arrest error in sharedflow  by RF policy as mentioned above. But it is not working as expected.Although if I create an AM policy and keep it in the fault rules with the same condition in the proxy , it is working. This is the condition i have used <Condition>ratelimit.policyname.failed = true</Condition>. Can you please help me understand this

Hello Mitra - are you continuing on error in this scenario as a part of the shared flow? I was able to get this workflow operating to expectation by setting the continueOnError flag to "true" within the Spike Arrest policy, then validating on that exceeded condition as noted above (I used 

<Condition>ratelimit.SA-Limit.failed == true </Condition>)
From there, I was able to call into my Raise Fault Exception within my SF and create a custom error as needed
 
Please let me know if you have any additional questions/concerns - thanks!

@hartmann Hello Hartmann, Thankyou for responding back to the query! Yes, as you hightlighted continueOnError was false, which is why it was not working. Its sorted out now!

Thank you again