Forum Discussion
mwitt_65218
Nimbostratus
NimbostratusThis should not be so difficult.
Hello,
We have F5 ASM v9.4.5 running on a production web app (though very few users use it).
We have Automatic Policy Builder running. A parameter named email was created by it. This is for a textbox to enter the email address of a contact when the user is adding a contact. This email parameter that Automatic Policy Builder created is a user-input global.
When I entered jroot@morrison.com (a real email address of a user who uses this small web app), the Report section showed the error about the Attack Signature SQL-INJ @ROOT. So I clicked ACCEPT on the error. I then clicked APPLY POLICY. I again entered jroot@morrison.com and again received another error. Again I clicked on ACCEPT on the error. I processed again, received the error again, clicked ACCEPT, clicked APPLY POLICY, et cetera. But I keep getting the error.
So I went to the email parameter and manually brought to the left the Attack Sig named SQL-INJ ROOT@ and made sure that the drop down showed DISABLED before I clicked UPDATE. Since the RED M showed since I had modified a parameter and therefore the policy, I clicked APPLY POLICY. I processed again to enter jroot@morrison.com and yet again I received in Report section another error about this Attack Sig not liking jroot@morrison.com. So numerous times I have gone into the email parameter which shows already disabled for this Attack Sig since I have processed numerous times today to click UPDATE for that parameter with DISABLED for this Attack Sig, but STILL I keep getting the error when entering that value.
If the Automatic Policy Builder is running and I click ACCEPT on an error in the Report section AND go to the parameter to disable that Attack Sig, clicking APPLY POLICY whenever the RED M shows for the policy, why do I keep getting the error when I process to enter jroot@morrison.com into the textbox that corresponds to Automatic Policy Builder's email parameter?
Thanks much.
13 Replies
mwitt_65218Yeah, I will let you know if I find out anything.
I thank you very much again.
naladar_65658Altostratus
I am glad to help! As an added bonus, once you get an answer back from those guys we will BOTH know a little more about these things! Hehehe....- mwitt_65218Hi 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.
