This should not be so difficult.

Hi Naladar,

 

 

Thanks again to you. Before Mike from F5 called about the Case Number that I had created, I was in Policy Building - Manual to review and accept some of the various Non-Attack Sig violations (like Illegal Empty Value In Parameter for example) as you had mentioned and described. I do not have the BLOCK checkbox checked yet for these Non-Attack Sig violations, but I want to modify the policy to accept them BEFORE I decide to check the BLOCK checkbox for these Non-Attack Sig violations.

 

 

The problem with overriding the SQL-INJ ROOT@ Attack Signature for the email parameter was that the STAGING process still was active.

 

 

It seems that when you go to click ACCEPT on an Attack Sig violation via Policy Builing - Manual (or via the Report section), you must first turn off the STAGING process in order to modify the policy to accept/override that Attack Sig for that parameter. So as soon as I turned off the STAGING process, I then clicked ACCEPT on the SQL-INJ ROOT@ violation for the email parameter and now there is no problem when I type jroot@morrison.com into the email textbox.

 

 

Again, if the violation is NOT an Attack Sig violation (like Illegal Meta Character In Paramter Value or Illegal Empty Value In Parameter or Illegal Static Value In Parameter), you can click to ACCEPT even though you have not put yet into blocking mode by clicking the BLOCK checkbox. But you cannot click to ACCEPT an Attack Sig violation UNLESS first you remove the STAGING.

 

 

Thanks again very much though as your suggestions/comments helped me greatly! I need to continue to play around in the web app, figure out what Non-Attack Sig violations I want to accept and then click to accept them, and then eventually click the BLOCK check box for them to start actually blocking.