[keycloak-dev] Avoid older user agents?

[Bill Burke]

On 8/7/2013 8:02 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Gabriel Cardoso" <gcardoso at redhat.com>, keycloak-dev at 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 at redhat.com>
>>>> To: "Gabriel Cardoso" <gcardoso at redhat.com>
>>>> Cc: keycloak-dev at 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