Forum Discussion

Nik_67256's avatar
Nik_67256
Icon for Nimbostratus rankNimbostratus
Feb 24, 2012

Character set Policy settings - URL,Parameters,Headers

Hello friends,

 

 

 

The character set feature for URL's , parameters and Headers has a "Restore default" button. Is it an industry norm and wise to use the default settings to use this feature. Asking this becasue i see different character policy settings for URL's , Parameters & Headers and am not sure if someone custom modified them before or are these the default settings.

 

 

Specifically , Queries are :

 

 

1) Is it wise to click the "restore default" button and use the default policy rules accross these entities.

 

2) By clicking restore defaults, would the charater sets policy settings (allowed/disallowed )be different for URL's , parameters , Headers ? (casue if not , then i know someone custom modified it)

 

 

Nik

 

  • 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