Hi Nik,
I think the default charsets are fairly reasonable in recent ASM versions. This is the logic I used to use for older ASM versions when they weren't set as well.
In general, I am most concerned about not allowing the following meta-characters in any global character set as these are the most common characters required to initiate an application layer attack:
'%< >&;`
'- single quote, used in SQL injection and XSS attacks
%- percent, used in encoding attacks
<>- angle brackets, used in scripting, SQL injection attacks
&;- ampersand hash semi-colon, used together in Unicode encoding attacks
`- backtick, used in operating system command injection attacks (Posix OS’s only)
URI and parameter input are normalized according to the number of decodings specified in the Blocking Mask -> Evasion Techniques section.
Because ASM does not URL decode the HTTP headers, we typically need to enable the % character in the header character set. This is typically found in the Referer header value.
For a secure start to a policy, you can try to only allow these characters globally:
Header:
A-Z a-z 0-9 space ! " $ % & ( ) * + , - . / : ; = ? @ [ ] _ { }
URL:
A-Z a-z 0-9 Space " / ( ) + , - . @ [ ] _ { } $ ?
Parameter Name:
A-Z a-z 0-9 Space ! " ( ) + , - . @ [ ] _ { } $ ? = :
Parameter Value:
A-Z a-z 0-9 Space CR LF ! " ( ) + , - . @ [ ] _ { } $ ? = :
As you test the application through ASM, you can globally allow any character not in the risky list (the eight meta-characters listed above). For meta-characters in that list, make specific exceptions so you don't allow them in the global character sets (ie, for a parameter value which requires a , create a parameter and allow the character only for that parameter).
Aaron
Nimbostratus
