Character set Policy settings - URL,Parameters,Headers

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