3

A service I use has decided to block HTTP requests that do not provide a UserAgent, citing security reasons.

As far as I can tell, the UserAgent is a string without a standard format used primarily for statistics, serving different page versions (eg mobile), and blocking bots. The RFC says it SHOULD (but not MUST) be sent.

Why Shellshock works in useragent string? suggests that a malicious UserAgent could be constructed, but the service is blocking requests without a UserAgent.

Is there a vulnerability around absent UserAgent headers I'm not aware of?

6

Not really, your understanding seems to be correct. Pretty much every web browser (and most other HTTP clients) will send a user-agent string, so arguably any request that arrives without one is pretty sketchy-looking. On the other hand, it costs basically nothing to send one (for example, with curl, use the -A argument) and is not guaranteed to have anything to do with the truth. Most clients, including browsers, let you spoof the UA string as anything you (the user) want it to be.

Of course, if you tell the server that you're IE 5 running on Windows CE, you might get back some really abysmally shitty HTML/JS - many web servers use UA strings to send different versions of web pages based on the expected capabilities of the browser making the request - but that's your problem, not the server's problem. Same goes for sending no UA string at all.

Security-wise, you could maybe put a speed bump in an attacker's way by blocking requests with no UA, or with an untrusted UA, but all that an attacker has to do is just spoof the UA of, say, the current version of Chrome (which is easy to find and easy to use). It's nothing more than a speed bump. I wouldn't even call it defense-in-depth, since it's so trivial to bypass.

I think your service provider really doesn't grok security, and is falling for what I call the "no legitimate user" fallacy (not to be confused with "no true Scotsman"). It goes like this: "OK, so there's a security threat if the user [does X]? Well, no legitimate user would do that, so we're safe." In this case, [does X] seems to be "spoofs their client's UA string". A lot of people just don't understand that an attacker can, and will, impersonate a legitimate user well enough that you can't reliably tell the difference until you've been exploited.

Well, either that or they just aren't aware that the UA string is nigh-meaningless and trivially editable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.