: User-Agent with base64-encoded component? (Bounty question at the bottom) I'm having an issue with a client accessing our site, and the root cause is that the WAF (Web Application Firewall) doesn't

@Jennifer507

Is having a base64-encoded string inside a User-Agent normal or unusual?


Digging though the list of User agents at WhichBrowser. It is reasonable to conclude that this is rare, but possibly the result of a malware infection.

However I also abused this behaviour to add another security layer to my own site in the past, where only a few clients with a specific base64 UA token would even be displayed the login page. Similarly this unique fingerprinting could also be used to serve an attack page or redirect elsewhere.


Is the use of base64 strings inside a User-Agent covered by any RFCs or major vendor practices?


Not specifically. Nothing is documented in any of Gecko browsers vendor information. In the UA you provided, the base64 it is not part of the product information, but a comment. There are seemingly no restrictions of the comment field although having base64 in the product information is not allowed by RFC7231 as it can be seen as unnecessary information appended to the UA string.



Your WAF likely can't identify the UA as anything specific and maybe returns libwww-perl because the filter is unspecific (false positive) and gets too happy with the Linux/X11 bit as it cannot make sense of the base64 comment.

Vote Up Vote Down

@Pope3001725

If all other traffic from this IP address is legitimate, then I wouldn't worry about the WAF rule being triggered. It doesn't decode into a human readable string. So it was likely inserted by a proxy device for tracking purposes.

Regarding your concern about the RFC, they're written as a recommendation for how the field should be used though there is little consistency between platforms. That being said, it's a value defined by the client which cannot be trusted as it's trivial to modify. Thus why WAF rules are needed.

There are two areas in which I see User-Agent strings becoming a concern:


Buffer Overflow - either trying to overflow the buffer on the server or within the website/application. This clearly isn't happening in the provided example.
Script/Code Injection - providing inline scripting, references to remote files, etc. Again, clearly not applicable to your situation.


If you're really worried/paranoid, change the User-Agent string of your own system to this one and browse the same pages while using a proxy such as Fiddler, Burp, etc. How do the request/responses compare to using your original User-Agent string?

I wouldn't recommend blocking any IP addresses based off the provided example unless all traffic from this IP is malicious. Even then it should only be blocked for a limited time. Better yet, create a "blocked web page" with details of how to be unblocked. Redirect traffic there until contacted.

Vote Up Vote Down

@LarsenBagley505

Doing a check online has come across this user agent string on the site closetnoc.org. This user agent was identified as being one of a number which have been traced to a single IP address 192.185.1.20 which has been flagged as a spammer by list.quorum.to, bl.csma.biz, and spamsources.fabel.dk.

To block access to this IP (and in turn to that User-Agent)...


Using CISCO Firewall

access-list block-192-185-1-20-32 deny ip 192.185.1.20 0.0.0.0 any
permit any ip


Using Nginx

Edit nginx.conf and insert include blockips.conf; if it does not exist. Edit blockips.conf and add the following:

deny 192.185.1.20/32;


Using Linux IPTables Firewall

/sbin/iptables -A INPUT -s 192.185.1.20/32 -j DROP


Using Microsoft IIS Web Server

<rule name="abort ip address block 192.185.1.20/32" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{REMOTE_ADDR}" pattern="^192.185.1.20$" />
</conditions>
<action type="AbortRequest" />
</rule>


Using Apache .htaccess

RewriteCond %{REMOTE_ADDR} ^192.185.1.20$ [NC]
RewriteRule .* - [F,L]



Source: closetnoc.org

Vote Up Vote Down