W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [XHR] Open issue: allow setting User-Agent?

From: Julian Aubourg <j@ubourg.net>
Date: Tue, 9 Oct 2012 16:34:08 +0200
Message-ID: <CANUEoeuK-fs-G+3EDVv6tCpW_5iW2x9YOoT48T5Rhb5W0EDHEg@mail.gmail.com>
To: "Hallvord R. M. Steen" <hallvord@opera.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Julian Aubourg <j@ubourg.net>, Jungkee Song <jungkee.song@samsung.com>, "public-webapps@w3.org" <public-webapps@w3.org>
>
>
>> I've had trouble writing extensions and user scripts to work around
> backend sniffing, due to being unable to simply set User-Agent for a
> specific script-initiated request and get the "correct" content. As I've
> attempted to explain to Anne, I think this experience is relevant to
> scripts using CORS, because they also want to interact with backends the
> script author(s) don't choose or control.
>

 If the backend sniffs out (all or some) browsers, it's the backend's
choice. CORS has been specified so that you NEED a cooperative backend.
Unlock a header and some other means to sniff you out will be found and
used :/

>
> Interacting, in a sane way, with a backend that does browser sniffing is a
> *very* compelling use case to me.


Thing is CORS makes it mandatory to handle things both client-side AND
server-side already anyway. I don't like this any more than you do (I'd
prefer a fully client-side approach but security snipers will probably
shoot me on-sight ;)).


>> The changed User-Agent will of course only be sent with the requests
> initiated by the script, all other requests sent from the browser will be
> normal. Hence, the information loss will IMO be minimal and probably have
> no real-world impact on browser stats.
>

var XHR = window.XMLHttpRequest;

window.XMLHttpRequest = function() {
   var xhr = new XHR(),
       send = xhr.send;
   xhr.send = function() {
       xhr.setRequestHeader( "User-Agent", "OHHAI!" );
       return send.apply( this, arguments );
   };
   return xhr;
};


>
>> If your backend really relies on User-Agent header values to avoid being
> "tricked" into malicious operations you should take your site offline for a
> while and fix that ;-). Any malicious Perl/PHP/Ruby/Shell script a hacker
> or script kiddie might try to use against your site can already fake
> User-Agent


Oh, I agree entirely. Except checking User-Agent is a quick and painless
means to protect against malicious JavaScript scripts. I don't like the
approach more than you do, but we both know it's used in the wild.


> A malicious ad script would presumably currently have the user's web
> browser's User-Agent sent with any requests it would make to your site, so
> unless you want to guard yourself from users running
> HackedMaliciousEvilWebBrowser 1.0 I don't see what protection you would
> loose from allowing XHR-set User-Agent.


The malicious script can trick the server into accepting a request the
backend expects to be able to filter out by checking a header which the
standard says is set by the browser and cannot be changed by user scripts.
Think painless DOS with a simple piece of javascript. I'm not saying the
assumption is stupid, I'm just saying we'll break a lot of things and may
cause harm in the end (by not aknowledging how bad people are at security).

Yes, sniffing is stupid, not it's not secure (in the sense a server can
already pretend to be a browser... but the use-case is really to prevent
browsers from mascarading as servers). If the header is used against a
white list (which, when you think about it, is "good" in all this
"badness"), then a backend not considering such or such browser is a pain.
But, just like CORS itself, it's something you need to handle server-side.

Now, my GMAIL dinged like crazy when I wrote this, so I guess I missed some
other back and forths :P
Received on Tuesday, 9 October 2012 14:34:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT