OWASP
New Requirement on Browser Version Checking
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.
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.
And older browsers do not support modern TLS, samesite, CORS, CSP 2/3 and a host of other standards that secure web apps need.
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?
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/
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?
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 https://github.com/OWASP/ASVS/issues/959#issuecomment-815155670 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.
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.
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.
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.
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.
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?
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.
So how do we classify an "old" browser? Which security features must it support?
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.
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.
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: https://github.com/OWASP/ASVS/issues/959#issuecomment-989628980)
@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)
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 I thought about having two requirements but it seemed like they would also be the same level and that one was kinda useless without the other. Can you think of a situation where it would be useful to do one and not the other?
- "documentation requirements" could be used before someone start implementing anything, also base/input for later checking the implementation
- "implementation requirements" are for verifying, is implementation matching for requirements
ping @elarlang - some minor wordsmithing on the first one:
- Verify that the web application warns users using an old browser that 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)
I'm not sure how to put or should we put it into action, but I share my concern - at the moment we put the spotlight on (old) browsers, but maybe it should be on HTTP security features instead? The point is - you need to check (required) HTTP security features your application relies on. List of "old" and not supported browsers is the outcome of this action.
At the same time - "old browser" is also valid, if it is with a known vulnerability. In this case, it makes sense to be more precise.
So @elarlang maybe just reduce the focus on old and focus on the features:
Verify that the web application warns users if they are using a browser/browser version that does not support HTTP security features on which the application relies. (L3) Verify that the list of browsers/browser version which do not support HTTP security features on which the application relies is periodically reviewed and updated. (L3)
What do you think?
Current requirement
| # | 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 |
So at the moment documentation and implementation are merged to one requirement?
Pointing out my comments:
- https://github.com/OWASP/ASVS/issues/959#issuecomment-1090474984
- https://github.com/OWASP/ASVS/issues/959#issuecomment-1103620898
~~Adding this thread here for future discussion:~~
~~https://floss.social/@downey/110016569829718294~~
EDIT: I think we are already advocating what this post suggests
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?
I think labelled it as rework because it seems to become a larger point of if and how we separate documentation and implementation requirements...
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).
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.