Re: [keycloak-dev] Avoid older user agents?

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "Gabriel Cardoso" <gcardoso(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org Sent: Wednesday, 7 August, 2013 1:07:57 PM Subject: Re: [keycloak-dev] Avoid older user agents? On 8/7/2013 8:02 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: "Gabriel Cardoso" <gcardoso(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org >> Sent: Wednesday, 7 August, 2013 12:39:52 PM >> Subject: Re: [keycloak-dev] Avoid older user agents? >> >> >> >> On 8/7/2013 4:45 AM, Stian Thorgersen wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>>> To: "Gabriel Cardoso" <gcardoso(a)redhat.com&gt; >>>> Cc: keycloak-dev(a)lists.jboss.org >>>> Sent: Tuesday, 6 August, 2013 5:04:39 PM >>>> Subject: Re: [keycloak-dev] Avoid older user agents? >>>> >>>> For SSO login, we should support as old as possible (no javascript, >>>> backward compatible to HTML 4? 3? 2? I don't know you tell me....). >>> >>> HTML4 transitional is fine, pretty much covers 99.9999% of browsers in >>> use >>> today. We can use JavaScript as long as it's progressive enhancements >>> (for >>> example autofocus or placeholder replacement). The biggest issue is >>> around >>> css/style and testing that it's "pixel perfect", there's several websites >>> out there that can help with this. There may be an official list of >>> browsers Redhat supports, but I would think recent versions of Chrome, >>> Firefox, Safari, Opera (these are all generally updated and there's very >>> few old versions around). For IE6 is announced dead by MS themselves, and >>> IE7 has a relatively low usage, so I would think IE8 is sufficient. >>> That's >>> not to say it won't work with older browsers, it may just look a bit >>> crap. >>> >>>> >>>> For admin UI, we can be more restrictive, IMO. The admin UI, is not >>>> just a UI though. It is a set of REST services that can be called from >>>> javascript (or whatever langage/platform you want). For security >>>> reasons we might want to restrict the types of browsers that can make >>>> these REST requests. >>> >>> I'm wondering if limiting on agent header is false security as it can be >>> easily changed. >>> >> >> I was thinking more of XSS. If somebody has logged into Keycloak with >> an old browser. We're protecting the user, not preventing a direct >> attack. Am I right here? > > XSS is what I'm thinking about, as the malicious code could just set the > user-agent header on any XHR requests to mimic a new "safe" browser. BTW > I'm not expert and I'm just speculating ;) > How could malicious code make XHR requests to a different domain? I thought that didn't work even in old browser. That the only way would be a <script> call.

>> >>> Checking user agent before setting HttpOnly is also IMO not necessary as >>> most browsers do (in fact IE does all the way back to 6 and Firefox to >>> 3!). Anyone that still uses a browser that doesn't support it today are >>> using a heavily out of date (and unsupported browser) so it will be >>> riddled with vulnerabilities in any case. >>> >> >> No, we would always set HttpOnly. The cookie spec allows for arbitrary >> values. > > Sorry, I worded that incorrectly. I meant that we could just create the > cookie in any case (always with HttpOnly) as it seems to me that >99% > browsers are covered. > > A browser that is very vulnerable to XSS attacks might not even need a > cookie to get the required info? > >> >> I just think its so important to think of any security vulnerability and >> close it up. If we get one security hack, our credibility takes a huge >> hit. > > IMO if someone uses an old browser with known vulnerabilities it's the > browser that was hacked, not Keycloak. I guess this is the meat of what > I'm trying to say. > > What about a warning message on the login screen if someone uses an old > unsupported browser? > That could work too. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com