Jump to content
Welcome to our new Citrix community!
  • 0

Field format check block multiple time even so learn & getting blocked

Ghaith Alqtieshat


Hello Everyone , 


Please i need you support ,

i have deployed Web application Firewall and and enable learning mode on field format check after we finished , and relax all learned rule we enable blocked , 

but we found that rule is getting blocked again even so they have been relaxed 

but i noticed the log indicate session id is change every time . 

so how can control this please 

Link to comment

4 answers to this question

Recommended Posts

  • 0

Always:  which version of ADC are you running (some appfw issues might be build specific issues)


Field format depends on whether you have a default field format set or not. Usually a default field format is not set.

Currently, you are finding violations on fields but not blocking (not stopping).  


If no default field format set, then only fields listed in the relaxations are protected with the format pattern (regex) specified. Therefore, with no default field format set, and a specific field/url listed, the contents of the field must match the regex pattern listed.  Issues with field name pattern, field url pattern, or field format pattern can  result in more frequent pattern violations.  If field is not listed, it is not protected at all.


If a default field format is set, then every field must confirm to "default" pattern specified. If not, a violation is generated.  Then exemptions are created for specific field names (patterns) on urls with the override pattern specified. If issues here, field is in violation of default; or field is in violation of relaxation pattern.


No more info available without understanding your default pattern (if in use) and the relaxation you are trying to use.


Link to comment
  • 0

Hi Rhonda , 


thanks for your response , 


I'm Running NS12.1 62.21.nc version 


I have question about fieled format , if the application it self  set the field only to accept lets numbers , this is consider as field format  protection ? did i need to enable field format on security 

my issue that I learn the application using security check and later we enable block and i found the format is being blocked again and i can deploy it again also 


see below example , it have been relax & on same filed name 


Field Name: sid

Action URL^https://tam\.aseza\.jo/wialon/ajax\.html$




Link to comment
  • 0

So, if the app is doing data type enforcement, you typically don't want/need the appfw doing it, unless there is a risk/vulnerability in what the app allows.

If you rely on the apps field confirmation for alpha, numbers, other, then if the user enters the wrong "type" by mistake the app can display an error and allow the user to correct it.

If you overdo the field format protection with the appfw instead, the only response on violation is a complete block of the page.


If you have a text field that is vulnerable to various attacks that still looks legitimate to the app (its doing some validation, but no input cleaning), then appfw can help you add a layer of protection, but its not user friendly. Typically, a lot of vulnerabilities are already protected by signatures, start/deny urls, and the various command injection protections (sql/xss/cmd injection which may not be in 12.1).  Field Format was used more when signatures didn't exist yet.  I tend to use as a last line of protection if 1) the field is of particular risk and 2) none of the other protections work.  You can also use field format as a "don't allow these" pattern while allowing the app-level field protection to do the "what to allow" check and the appfw only catches truly bad patterns.


If you have a field: sid

on the page specified,

If no default field format is specified AND the alphanum type is specified. Then field can only contain alpha/numerics.

So what does the log say is the contents?

Otherwise make sure your "is regex" for field name is marked (so both field and url regex is recognized). And make sure field isn't matching on different urls other than the one you are looking for.


The problem is your log event above is flagging on the "params" field instead. Which contains encodings for {, " and, } among others maybe.



Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...