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 policy, Regular Expression Protection policy, XML 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 :
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
'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.
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.
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
@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