Forum Discussion
GDC1-TRG-F5
Nimbostratus
NimbostratusASM / WAF - Requests getting blocked due to encoded usernames
Users are trying to login to an application and we believe requests are getting blocked due to encoding happening for the usernames. This is an existing config and no recent changes done. The same a...
GDC1-TRG-F5Nimbostratus
NimbostratusHi Nikoolayy
It seems to be URL encoded
Content-Type application/x-www-form-urlencoded
org.apache.struts.taglib.html.TOKEN=a4f6d3a973f693cff91af4a6b85508e1&userName=z%7D%26%26s%7Cu%26%28s&action=Login&serviceName=C3&clientIp=x.x.x.x&fingerprint=563462682
I've already tried the "Auto Detect" option but it didn't help.
Is there any other option we can try to specifically allow these users against those signature ID's without disabling the signatures or any other checks for them.
Does updating to the latest signatures help?
If the policy is configured to learn Automatically, would it also update to the latest signature by itself.
Nikoolayy1
MVP
MVPAbout updating the latest signatures I can't say if this will help as it is your network environment but you can test it and policy being set to auto does not influence signature update as for auto policy building you can see Overview of Fully Automatic Policy Building learning mode. I suggest reading Managing BIG-IP ASM Live Updates (14.1.x and later) to understand how signature updates work as maybe you are having real time live updates as the triggered signatures could be new that the auto policy builder to still have not disabled as if there is not enough traffic from many different ip addresses, so you may need to do this manually.
Also as mentioned better sync with your developers to get the full picture before implementing a solution as URL Decode and Encode - Online did not show the value from your picture to be url encoded. The first encoding z%7D%26%26s%7Cu%26%28s is URL based but the second z}&&s|u&(s is something else, as this could be a case of multiple encodings, except if that is the real username but I think it is not otherwise stop the signatures just for the parameter as I shown at the end of this post with a link.
F5 should correctly decode by default url encoded parameters automatically except if there is a version bug, but I don't think it is a bug (still BIG-IP version update is always nice if you running old version) as I mentioned the value does not seem url encoded. If you see a suggestion to increase the decoding Learning suggestion to increase Maximum Decoding Pass Attempts then do it but as I mentioned the encoding does not seem URL based to me.
Also it is good to sync with the developers that they are using UTF-8 language and not something else for the parameters Overview of encoding language settings for the BIG-IP ASM system and ASM: Wrong charset on policy, what's the impact ? | DevCentral
Also check if there was a failover on the big-ip Security policy Enforcement Mode changed from Transparent to Blocking
That are the suggestions I can provide without stopping the signatures on the parameter "userName" Disabling attack signature checks for specific entities