New Requirement on Browser Version Checking

[jmanico]

So much of ASVS is beginning to address new web standards like SameSite cookies.

I feel all websites should programmatically limit browsers in some way to ensure that very old browsers with bad web standard cannot be used my typical users.

Sure attackers can circumvent this but that is not the point.

For typical users (and for CSRf like attack scenarios) I feel JS block older browsers and to enforce a clear browser standard is crucial for the secure web.

[elarlang]

Does it makes sense from ASVS point of view to say, that you can not use certain (not EOL) browser, even site has proper defense for used technologies in place?

Supporting EOL browser versions actually does not makes sense, because if those will not get security patches, site owner need to consider those clients as "hacked clients" - confidential information may leak and so on.

[jmanico]

And older browsers do not support modern TLS, samesite, CORS, CSP 2/3 and a host of other standards that secure web apps need.

[elarlang]

But in practice, how could it work? From where you'll get list of "valid browsers"?

Just based on User-Agent string alone:

• you can not use allow-list - other-wise you keep away some "weird" users. No one want to loose their visitors.
• you can not use deny-list - you just can not keep a list of all possible "not good enough" browsers

And it all reminded me, that we may not have User-Agents soon at all:
https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/

So, in practice it means some extra "test-page for required technologies" before you actually can use site with your browser?

[cmlh]

An example of where support has to be given to the widest older releases of web browsers is when the public have to browse emergency warnings, etc yet this web app is considered as "high assurance" i.e. Level 3

The solution is to highlight when each ASVS Requirement supports only the latest browser release similar to https://caniuse.com/

[elarlang]

An example of where support has to be given to the widest older releases of web browsers is when the public have to browse emergency warnings, etc yet this web app is considered as "high assurance" i.e. Level 3

This is interesting problem

• it does not make sense to hide information about emergency warnings, because it may be critical information
• it does not make sense to show this information because you can not trust the client (browser) and integrity of the messages is questionable

But before we go there, my question is still - is it technically doable (with reasonable effort) without having detailed user-agent information?

[cmlh]

But before we go there, my question is still - is it technically doable (with reasonable effort) without having detailed user-agent information?

Yes as the web application is relying upon the web browser technologies cited by #959 (comment) rather than User-Agent Request Header alone.

The caveat is if the web application itself doesn't implement these web technologies to deliver the web application then it is simply increasing its attack surface.

Ultimately, Cloudflare et al would have the data on the pro and cons of this control.

[jmanico]

I asked the head of the W3c security group here. https://twitter.com/manicode/status/1432727817167331329?s=21 To understand how to reliably detect browser type.

[cmlh]

I asked the head of the W3c security group here. https://twitter.com/manicode/status/1432727817167331329?s=21 To understand how to reliably detect browser type.

Also of note is "The header, however, is likely to be impossible to remove entirely in the near-term, as existing sites' content negotiation code will continue to require its presence" to quote https://wicg.github.io/ua-client-hints/#user-agent cited in the Twitter thread above.

My current position at the moment is that if the web browser does not support what we consider a "secure" web technology then the end user will seek an alternate web application not verified against ASVS rather than upgrade due to lack of technical know-how.

[jmanico]

UA is one way to verify browser version server-side. As discussed in the twitter thread, https://wicg.github.io/ua-client-hints/ will only make it easier to do so.

[elarlang]

If this requirement takes place, it may have need for "documentation/process requirement" - "Verify that supported browsers are documented." + there is process to periodically recheck, that supported browsers are not vulnerably for known attacks.

[tghosth]

I think we could require a warning about an old browser version but requiring blocking old browser versions seems like it would get a lot of pushback from a functionality perspective. I also think this is maybe a Level 3 requirement. @jmanico what do you think?

[jmanico]

I think blocking old browsers is critical to security. We need to know the browser version for TLS configuration, simple things like CSS.escape for client-side XSS protection of styled-components, we need to know the version for CSP and many other things.

I agree, a good place to park it at first entry is level 3.

[tghosth]

So how do we classify an "old" browser? Which security features must it support?

[jmanico]

There are too ,many to enumerate.

CSS.escape does not fire in ie11

CSP 3 is only recently in Safari

I could list hundreds of these.

The general requirement is, know what security features you depend on and consider blocking clients that do not support it.

[tghosth]

So how about:

Verify that the web application warns users who are using an old browser which does not support HTTP security features on which the application relies.

[elarlang]

and known to vulnerable browsers, if it is possible to detect it?

And again - those requirements will change in time, rules must be documented, up-to-date and periodically checked.

(like I already wrote: #959 (comment))

[tghosth]

@elarlang yeah I think that the old browsers list needs to be dynamic. How about:

Verify that the web application warns users who are using an old browser which does not support HTTP security features on which the application relies. (L3)
Verify that the list of old browsers which do not support HTTP security features on which the application relies is periodically reviewed and updated. (L3)

[elarlang]

There are 2 requirements:

• documentation - have your list and requirements
• implementation - check that implementation follows documentation/requirements

I think it makes sense to keep those as separate requirements.

[elarlang]

In my opinion and vision - we should have separate security decision requirement for V1 category like discussed here.

@tghosth @jmanico - do you want to stay with one requirement or you share the "security decision first" requirement idea?

and why it has major rework label?

[tghosth]

I think labelled it as rework because it seems to become a larger point of if and how we separate documentation and implementation requirements...

[elarlang]

ping @tghosth - I think the issue or requirements do not have any dependencies anymore and it should be enough information to decide - do we go with one requirement (like it is at the moment) or we should have a separate documentation requirement (like I proposed).

[tghosth]

Yes we need a documentation requirement for this where the allowed/disallowed browsers are made clear. Documentation goes to V1, implementation goes to V50.

@elarlang to propose the documentation requirement.

[jmanico]

How about:

Verify that the documentation states the security features required for browsers to safely use the web application, including support for HTTPS, HSTS, Content Security Policy (CSP), and other relevant HTTP security mechanisms.

[elarlang]

That's nice, I think we can remove few "restrictions":

Verify that the documentation states the security features required for browsers to safely use the web application, including support for HTTPS, HSTS, Content Security Policy (CSP), and other relevant HTTP security mechanisms.

[jmanico]

Good call, @elarlang 👍 So we are at :

Verify that the documentation states the security features required for browsers including support for HTTPS, HSTS, Content Security Policy (CSP), and other security mechanisms.

[tghosth]

I think the requirement is a little unclear without the original clarification:

Verify that the documentation states the security features required for browsers to use the application, including support for HTTPS, HSTS, Content Security Policy (CSP), and other relevant HTTP security mechanisms.

@elarlang do we need a matching implementation requirement in V50?

[elarlang]

@elarlang do we need a matching implementation requirement in V50?

Eem, yes. I was so sure it was already there, but no.

edit: found it from another category (as defined in #959 (comment)):

#	Description	L1	L2	L3	CWE
14.5.7	[ADDED] Verify that the web application warns users who are using an old browser which does not support HTTP security features on which the application relies. The list of old browsers must be periodically reviewed and updated.			✓	1104

[elarlang]

For the documentation checklist - the application needs, the browser:

• supports all the functionality features it relies on - otherwise it meets availability problems as functionality just does not work
• support all the security features it relies on - otherwise it expects some protection from the browser, but it is not there
• itself does not contain a known and widely usable vulnerability

If the mismatch is detected, there must be a clear decision on what to do - just warn the user or block the usage of the application. It depends on the application (see #959 (comment))

Verify that the documentation states the functionality and security features for browsers to use the application (such as support for HTTPS, HSTS, Content Security Policy (CSP), and other relevant HTTP security mechanisms), and states the decisions, how the application must behave when such event happens (such as warn the user, block the functionality).

If we agree with that, we need to update the current implementation requirement as well.

[jmanico]

I agree on all of this. The controls are usually to block the client or put up a banner warning them they are using an old browser and need to update.

[tghosth]

@elarlang can we now close this?

[elarlang]

@elarlang can we now close this?

No, I just moved the old implementation requirement to correct place but we have not merged the discussion from here.

[tghosth]

So we need to create a documentation requirement as well based on this:
#959 (comment)

and then align them?

If not, can you clarify the action here

[elarlang]

Status update.

We have proposal for the documentation requirement:

Verify that the documentation states the functionality and security features for browsers to use the application (such as support for HTTPS, HSTS, Content Security Policy (CSP), and other relevant HTTP security mechanisms), and states the decisions, how the application must behave when such event happens (such as warn the user, block the functionality).

Need to finetune and recheck that and then align current (moved to 50.7.3) implementation requirement to match that.

[tghosth]

Ok so please let me know when there is something updated to review