Forum Discussion
AltocumulusASM / 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 affected users were able to successfully login a few days prior.
Below are the 2 instances of issues
Actual username is getting Encoded and blocked
As we clearly know they're genuine users and it's a false positive, we would want to know what all options are available to resolve this issue on ASM.
3 Replies
- Nikoolayy1
MVP
It sounds like the backend app team may have added some encoding to the username parameter. Better sync with them and if it is base64 you have to enable it Securing Base64-Encoded Parameters . Other than that as mentioned in Working with evasion technique detected violations you may need to increase the number of decodings "Multiple decoding" if needed. Also the parameter "Auto Detect" option is interesting Using the 'Auto detect' option for a parameter to reduce false positive violations .
I will suggest if the app team has added base64 you may need to upgrade F5 to the latest version because Attack signature check security exposure
GDC1-TRG-F5Hi 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
About 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
