Forum Discussion
mwitt_65218
Nimbostratus
NimbostratusHow to disable a particular Attack Sig for a specific user-input parameter
Greetings,
I have the 416-page user manual but have had no other training, so please bear with me.
I am having problems figuring out how to disable a particular Attack Signature for a particular user-input parameter called username.
A user could not login with the username jroot@morrison.com because of the Attack Signature SQL-INJ ROOT@ (per the log in Reports).
When I clicked on that log, I then clicked ACCEPT with the hope that this jroot@morrison.com would be able to login. The users use an email address for the username textbox/parameter. Still though this jroot@morrison.com could not login and received the blocking from the SQL-INJ ROOT@ Attack Sig.
So I went to the username parameter. It already had the Meta Character @(64) allowed. For that parameter, I brought to the left with the << button the SQL-INJ ROOT@ Attack Signature and it was already disabled but I brought it to the left with the << button anyway and I clicked UPDATE with its state as disabled. Still though jroot@morrison.com could not login and received the blocking error from the SQL-INJ ROOT@ Attack Sig.
I do not want to change the class from Blocking to Transparent.
In the Policy/Blocking/Settings area, Block is not checked for any of the check boxes and Learn and Alarm are checked for all of the check boxes. The Attack Signature Detected though has no option to put into Learn, Alarm, or Block as there are no check boxes for Attack Signature Detected. It was my understanding that a log will go to Policy Building - Manual if the Learn is checked, but this SQL-INJ ROOT@ blocking did not produce an error in Policy Building - Manual. I guess this is because the Attack Signature Detected has no check boxes for Learn/Alarm/Block. But the Alarm puts the log into Reports and the Reports log shows how jroot@morrison.com was blocked because of the SQL-INJ ROOT@ Attack Sig (though the Attack Signature Detected has no check boxes for Learn, Alarm, or Block).
So yesterday in Attack Signatures section, I found the Policy Attack Signatures. I clicked to disable SQL-INJ ROOT@ by unchecking the Enabled check box. I saved and applied the policy and the 7-day staging period started yesterday.
Today jroot@morrison.com could login successfully.
Even if jroot@morrison.com will be able to login successfully after the 7-day staging period, have I disabled the SQL-INJ ROOT@ Attack Signature for everything, for the entire policy?
Why can't I disable somehow this one SQL-INJ ROOT@ Attack Signature for ONLY the user-input parameter named username? It seems that the user's last name "root" or the "root@" in the user's email address is causing the SQL-INJ ROOT@ Attack Signature to block when the user types "jroot@morrison.com" into the username textbox to login.
Any suggestions or ideas would be greatly appreciated.
Thanks!
mwitt
6 Replies
hoolioCirrostratus
Hi,
I don't actually see a SQL-INJ ROOT@ attack signature in the latest attack signature update, but that might have just been bad searching on my part. Anyhow, you can configure a parameter (easiest option is global) named username. You can then disable the SQL-INJ ROOT@ attack signature under the parameter's attack signatures tab by selecting it in the Global Security Policy Settings list and moving it to the Overridden Security Policy Settings list. It will be listed as disabled in the Overridden Security Policy Settings list by default.
If you disable the attack signature under Policy | Attack Signatures | Policy Attack Signatures, the change will apply to the whole policy.
Aaron- Greetings again!
Hoolio is spot on about the behavior when the signatures are disabled in their respective locations. You probably saw when you found the 'Attack Signatures' section that the Learn, Alarm, and Block settings are listed here for the individual signature sets - which is why they don't appear in the normal Blocking Settings.
It's difficult to speculate on why adding the signature to the parameter didn't work - it certainly should have. It may be worth checking the parameter level, global versus assigned to an object. hoolio's steps work in a test here. Perhaps there's another factor at play? 
mwitt_65218Thanks to you both for your replies, Hoolio and Ben.
I had used Global for Parameter Level for this username parameter that has a Parameter Value Type of User-Input Value.
In Parameters - Attack Signatures, I had used the << button to bring to the Overridden Security Policy Settings the SQL-INJ ROOT@ from the Global Security Policy Settings. It was Enabled when I brought it over with the << button, so I changed to disabled and clicked UPDATE. I was told by an employee that this other employee jroot@morrison.com still could not login. So then I had disabled in Attack Signatures - Policy Attack Signatures the SQL-INJ ROOT@.
I just now went to Attack Signatures - Policy Attack Signatures to click the Enabled check box for SQL-INJ ROOT@ to re-enable. I disabled this yesterday in an attempt to allow this user to login successfully, but I had a feeling that this would turn off the SQL-INJ ROOT@ for the whole policy as you have confirmed.
I just now went again to Parameters and clicked on the username parameter. I clicked on Attack Signatures. I used the >> button to remove SQL-INJ ROOT@. I then used the << button to bring again the SQL-INJ ROOT@ from the Global Security Policy Settings to the Overridden Security Policy Settings and I made sure that the State dropdown is Disabled. I applied the policy. The staging is set for 7 days though, so I do not know if these changes just now will go into effect immediately or after the staging period.
Anyway, I will give it another try. Maybe the timing was off when an employee told me that the other employee jroot@morrison.com still could not login after I had done what you suggested.
Just now I decided though to change the Parameter Level of the username parameter from Global to Object as suggested just to see if this helps. I used HTTPS for the Object Path since this is what is in the URL in the Browser. When I read here the mention of Object versus Global, I thought that Object might be better for this parameter that is for textbox on the web page.
Thanks again VERY much for your replies!- mwitt_65218Just an update in case you two, or anybody else for that matter, are interested ....
What I did yesterday seems to have worked with concern to the SQL-INJ ROOT@ Attack Signature and the username parameter. Yesterday I enabled that Attack Sig for the entire policy since I had disabled it. Yesterday I changed the username parameter from global to object and I brought in that particular Attack Sig to the Overridden Security Policy Settings section to disable it.
Today the jroot@morrison.com logged in per the logs in the Reports section. I do not see anymore in the logs how the SQL-INJ ROOT@ Attack Sig would block this user.
I do see a log when this user logged in about Illegal Static Parameter Value and Modified Domain Cookie(s).
When I open a log for the login of jroot@morrison.com that shows Illegal Static Parameter Value and Modified Domain Cookie(s) and I click ACCEPT, does this mean that next time jroot@morrison.com logs in he will not generate this log about Illegal Static Parameter Value and Modified Domain Cookie(s)?
Anyway, thanks again to you two for your replies as they both helped me very much. - Thanks for the updates! To clarify the effects of staging on the changes you made - if the staging period is currently active, any violations which are in staging should not cause actual blocking responses. This is the section of the manual that goes over this:
Click here
Also, when using the 'Accept' button on a violation, this will start an instance of the policy builder to accept all violations for this request. In the case of these violations, the value seen as an Illegal Static parameter will probably be added to the parameter values for this parameter, but the Modified domain cookie would probably add the offending cookie to the list of Allowed Modified Domain Cookies.
Either way, these changes effect the entire policy, and not a single user.
You may see the modified cookies for a period after you first put ASM in production as clients may still have cookies that were set prior to ASM being put in line where it could see them. In general, you should only need to allow modified cookies if you know that the client should be allowed to modify them (client-side javascript or something).
You might also want to review whether this should be a static, dynamic, or user-input parameter. A static parameter is a parameter for which you know the value will always be from a static list - like a drop-down selection of states. This describes them a little more, as well:
Click here - mwitt_65218Thanks Ben, I will look into it when I get a chance.
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
