Controlling the User-Agent header from script

# Anne van Kesteren (4 days ago)

Per XMLHttpRequest User-Agent has been off limits for script. Should we keep it that way for fetch()? Would it be harmful to allow it to be omitted?

slightlyoff/ServiceWorker#399

A possible attack I can think of would be an firewall situation that uses the User-Agent header as authentication check for certain resources.

Contact us to advertise here
# Nils Dagsson Moskopp (4 days ago)

Anne van Kesteren <annevk at annevk.nl> writes:

Per XMLHttpRequest User-Agent has been off limits for script. Should we keep it that way for fetch()? Would it be harmful to allow it to be omitted?

slightlyoff/ServiceWorker#399

A possible attack I can think of would be an firewall situation that uses the User-Agent header as authentication check for certain resources.

Reporting UA “Mozilla/4.0 (MSIE 6.0';DROP TABLE browsers;--"<u>{!=&})”

broke hilariously many sites when I did have set it as my default UA string, even though I think it conforms to RFC 2616, section 14.43.

# Roger Hågensen (3 days ago)

On 2014-10-13 15:53, Anne van Kesteren wrote:

Per XMLHttpRequest User-Agent has been off limits for script. Should we keep it that way for fetch()? Would it be harmful to allow it to be omitted?

slightlyoff/ServiceWorker#399

A possible attack I can think of would be an firewall situation that uses the User-Agent header as authentication check for certain resources.

That's a server security issue and not a browser one, attackers would never use a "nice" browser for attacks anyway, what point is there in background checks for security guards if the window is always open so anyone can get in? ;)

# Roger Hågensen (3 days ago)

On 2014-10-13 16:16, Nils Dagsson Moskopp wrote:

Anne van Kesteren <annevk at annevk.nl> writes:

Per XMLHttpRequest User-Agent has been off limits for script. Reporting UA “Mozilla/4.0 (MSIE 6.0';DROP TABLE browsers;--"<u>{!=&})” broke hilariously many sites when I did have set it as my default UA string, even though I think it conforms to RFC 2616, section 14.43.

Again, that's a server security issue and not a browser one, attackers would never use a "nice" browser for attacks anyway, what point is there in background checks for security guards if the window is always open so anyone can get in? ;)

Also, a script being able to set a custom XMLHttpRequest User-Agent would be nice. Not necessarily replace the whole thing but maybe concatenate to the end of the browser one? That way a webmaster would be able to see that the request is from script Blah v0.9 when it really should be Blah v1.0 for example. I always make sure that any Software I make uses a custom User-Agent, same goes for any PHP scripts and so on, ditto if I use CURL, that way the logs on the server will provide some insight.

# Jonas Sicking (3 days ago)

On Mon, Oct 13, 2014 at 6:53 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

Per XMLHttpRequest User-Agent has been off limits for script. Should we keep it that way for fetch()? Would it be harmful to allow it to be omitted?

slightlyoff/ServiceWorker#399

A possible attack I can think of would be an firewall situation that uses the User-Agent header as authentication check for certain resources.

We'd definitely need to treat the header as a content-set header from a CORS perspective. Otherwise we'd have problems not just with pages behind firewalls, but also websites that use cookies for authentication. I.e. most websites.

I still have some concerns about this. Though I can't think of any problems off the top of my head. I suspect we'll want to run this past our security team to make sure we're not missing anything.

FWIW, I don't think there's any difference between XHR and fetch(). If we enable this for fetch(), I don't see a reason not to enable it for XHR as well since it should mainly involve removing "User-Agent" from some internal blacklist in the code.

/ Jonas

# Nils Dagsson Moskopp (3 days ago)

Roger Hågensen <rescator at emsai.net> writes:

On 2014-10-13 16:16, Nils Dagsson Moskopp wrote:

Anne van Kesteren <annevk at annevk.nl> writes:

Per XMLHttpRequest User-Agent has been off limits for script. Reporting UA “Mozilla/4.0 (MSIE 6.0';DROP TABLE browsers;--"<u>{!=&})” broke hilariously many sites when I did have set it as my default UA string, even though I think it conforms to RFC 2616, section 14.43.

Again, that's a server security issue and not a browser one, attackers would never use a "nice" browser for attacks anyway,

I suspect with some XSS, this might be able to tear a new security hole with a feature that primarily provides cosmetic benefits.

what point is there in background checks for security guards if the window is always open so anyone can get in? ;)

Also, a script being able to set a custom XMLHttpRequest User-Agent would be nice. Not necessarily replace the whole thing but maybe concatenate to the end of the browser one?

I'd rather have a prefix, as the RFC says that UA tokens are in decreasing significance. Does that mean compatibility problems?

# Domenic Denicola (3 days ago)

From: whatwg [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Roger Hågensen

Also, a script being able to set a custom XMLHttpRequest User-Agent would be nice. Not necessarily replace the whole thing but maybe concatenate to the end of the browser one? That way a webmaster would be able to see that the request is from script Blah v0.9 when it really should be Blah v1.0 for example. I always make sure that any Software I make uses a custom User-Agent, same goes for any PHP scripts and so on, ditto if I use CURL, that way the logs on the server will provide some insight.

If this is your use case, a custom header will work just fine.

# Anne van Kesteren (3 days ago)

On Tue, Oct 14, 2014 at 1:02 AM, Jonas Sicking <jonas at sicking.cc> wrote:

We'd definitely need to treat the header as a content-set header from a CORS perspective. Otherwise we'd have problems not just with pages behind firewalls, but also websites that use cookies for authentication. I.e. most websites.

I thought maybe if we just allow it to be omitted (and not set to any value) it would be okay. Just like we allow Referrer to be omitted. But maybe not.

# Jonas Sicking (3 days ago)

On Tue, Oct 14, 2014 at 12:06 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

On Tue, Oct 14, 2014 at 1:02 AM, Jonas Sicking <jonas at sicking.cc> wrote:

We'd definitely need to treat the header as a content-set header from a CORS perspective. Otherwise we'd have problems not just with pages behind firewalls, but also websites that use cookies for authentication. I.e. most websites.

I thought maybe if we just allow it to be omitted (and not set to any value) it would be okay. Just like we allow Referrer to be omitted. But maybe not.

I'd rather not. Seems like an unknown amount of risk for a pretty low value. I would imagine that the main use case is to set a different UA, not remove the UA.

/ Jonas

Want more features?

Request early access to our private beta of readable email premium.