Hi all
I would like to implement a RegexThreatProtection policy that is capable of checking all request headers as we would send them to the Target Endpoint.
I notice that we can only define headers statically in the policy:
This would mean that we need to know each and every header that will ever be allowed through Apigee, which I think is not the best implementation...
Has anyone implemented something like this before?
I am thinking about perhaps using the Variable tag instead and just (using Javascript) parsing all request header values together into a single variable and have that checked in the regex policy.
Or can this have negative side-effects?
Curious what others think about this. Perhaps this is overkill?
Perhaps this is overkill?
It depends. Not all headers need to be scanned for common attack signatures. The ModSecurity Core Rule Set will give you a good idea of what to include in your var concatenation.
Has anyone implemented something like this before?
Yes. This sample code is a bit inefficient and there's room for improvement.
var concatParams = function(paramType) {
var paramsNames = context.getVariable("request."+paramType+"s.names").toArray();
paramsNames.forEach(function(name){
var paramValuesCount = context.getVariable("request."+paramType+"."+name+".values.count");
if(paramValuesCount > 0) {
var paramValues = context.getVariable("request."+paramType+"."+name+".values").toArray();
paramValues.forEach(function (value){
decodedRequest = decodedRequest.concat(' ',value);
});
}
});
};
Or can this have negative side-effects?
Watch out for performance bottlenecks (greedy regex and long header values). Test your implementation at scale!
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |