That really depends on your filter set.
Essentially they are using encoded characters to manipulate the request:
- %5B is an encoded [
- %7D is an encoded }
If you look in your dispatcher.log you'll see which filter rule allows that request through. See what it allows and then you can start to understand why it allows it
You can block these kinds of requests by not allowing suffixes on request that don't need them at all. For example here is a filter rule that will allow that type of request but not allow the encoded characters suffixes:
Request: http://answers.salesforce.com/etc/segmentation/sfdc-www.segment.js
```
/03000 {
/type "allow"
/method "GET"
/path "/etc/segmentation/*"
/url "/etc/segmentation/*.js*"
/extension "js"
/selectors "segment"
/suffix ""
}
```
This rule will allow the request through but because the suffix matcher is blank they can't smuggle stuff at the end of the request and have it work.
If you look at the original request and use something like cyberchef to decode it you'll see the pivot attack
original: http://answers.salesforce.com/etc/segmentation/sfdc-www.segment.js/jcr:content/%5b.%5b./%5B.%5b./%5b...
decoded: http://answers.salesforce.com/etc/segmentation/sfdc-www.segment.js/jcr:content/[.[./[.[./[.[./[.[./c...
because the encoded brackets are ignore it consolidates to:
and as you might know /../ is a traversal to go up a directory. It's trying to go to:
I hope that makes sense but essentially use as many matches (i.e. /method, /suffix,/extension, /url, /path, /selectors) as possible in your dispatcher allow rules. if you add a matcher with a blank value that means it won't allow the extras to exist and block the request. General rule of thumb is be as specific as you possibly can.
