Proposal: (sub)category "Client-Side" (browser-side)

[elarlang]

Goal: to cover all requirements, where an application need to check, was a HTTP request made by the browser/client legit or forced by malicious actor from 3rd party site. It includes attack vectors like CSRF, XSSI, ClickJacking, etc.

To which category it should belong, I'm not sure. Just by title, it feels first idea to put to "V9 Communications", but this one seems to be "configuration only" category (the name should say it as well).

Related discussions and issues:

• Prevent cross-site access with JSONP #903 (comment)
• V9 rework needed #1220 (comment)
• V4.2.2 CSRF and/vs anti-automation #795 (comment)

[elarlang]

Or... to create "Browser communication" (in whatever correct wording) category which should contain additionally:

• general cookie setup (move 3.4 cookie-based requirement as general (not only session management specific) #1162)
• requirements for HTTP response headers (current subcategory "V14.4 HTTP Security Headers")

It even may contain abstract requirement, that don't do any decision on the client side:

• Discussion: to keep "Trusted service layer" requirements separately or combine them to one abstract #1229

[tghosth]

So I think XSSI, CSRF, click jacking are "Confused deputy" and could potentially be classified like that. I think calling them HTTP source validation is a little misleading most of the remediation do not involve validations but rather functionality restrictions (e.g. not allowing site to be iframed or not using JSONP functionality.)

I think Cookie security is something slightly different and whilst the different flags could theoretically be in different sections, for simplicity I think it is better that they are together.

[tghosth]

@elarlang what are our next steps on this?

[elarlang]

depends on related discussion #1220 (comment)

[tghosth]

I just asked you a question there :)

[elarlang]

As those requirement did not find their place under V9, we need to have some separate (sub)category somewhere else.

It requires maybe a bit more analyze, is it worth separate category or we can handle it with subcategories somewhere else.

[elarlang]

... or should I just create new category "Client-Side", then start collection all client-side related requirements there and then we can see, how they going to group to subcategories and what is the best name for the category itself.

[tghosth]

That seems like a sensible approach. How do you want to handle this? Do you want to prepare a PR or just a list of issues?

[elarlang]

Client-Side

Client-Side is not best title, because in this context requirements are meant only for browser. Communication with API can be done with browser or from another service, so it's not the subject for this category.

It should contain requirements which are handling:

• Same-Origin-Policy, Same-Site or Same-Origin based restriction or security mechanisms
• Sending introductions and restrictions to browser, how to handle response

Architecture

TBD

#	Description	L1	L2	L3	CWE
TBD	[ADDED] Verify that separate applications are hosted on different hostnames so as to benefit from the protections provided by the "same origin policy" and the hostname restrictions on cookies.	✓	✓	✓	668

HTTP response headers

#	Description	L1	L2	L3	CWE
14.4.1	Verify that every HTTP response contains a Content-Type header. Also specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and application/xml. Content must match with the provided Content-Type header.	✓	✓	✓	173
14.4.3 *	[MODIFIED] Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, CSS, JSON, and JavaScript injection vulnerabilities.	✓	✓	✓	1021
14.4.4	Verify that all responses contain a X-Content-Type-Options: nosniff header.	✓	✓	✓	116
14.4.5	[MODIFIED] Verify that a Strict-Transport-Security header is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=31536000; includeSubdomains.	✓	✓	✓	523
14.4.6	Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.	✓	✓	✓	116
14.4.7	Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response headers.	✓	✓	✓	1021
14.4.8	[ADDED, SPLIT FROM 14.5.3] Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allow list of trusted origins. When "Access-Control-Allow-Origin: *" needs to be used, verify that the responses do not include any sensitive information.	✓	✓	✓	183

* Note that 14.4.3 is being separately discussed in #1311

need some nice title here

"Verify that request was initiated by trusted party" and "Verify that the response is readable only for trusted parties" requirements.

SOP and CORS related rules.

Data integrity related requirements:

#	Description	L1	L2	L3	CWE
4.2.2	[MODIFIED, MERGED FROM 13.2.3] Verify that the application defends against Cross-Site Request Forgery (CSRF) attacks to protect authenticated or sensitive public functionality using the development framework's built-in anti-CSRF functionality or CSRF tokens plus additional defense in depth measures.	✓	✓	✓	352
4.2.3	[ADDED] Verify that messages received by the postMessage interface are discarded if the origin of the message is not trusted, or if the syntax of the message is invalid.		✓	✓	346
14.5.3	[MODIFIED, SPLIT TO 14.4.8] Verify that the Origin header is validated against a defined list of allowed origins to match the desired Cross-Origin Resource Sharing (CORS) policy.	✓	✓	✓	346

Functionality integrity requirements:

#	Description	L1	L2	L3	CWE
14.2.3	[MODIFIED] Verify that if client-side assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.	✓	✓	✓	829

Confidentiality related requirements

#	Description	L1	L2	L3	CWE
TBD	outcome from #903 - Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks.
TBD	outcome from #903 - Verify that sensitive information is not present in JavaScript files to avoid Cross-Site Script Inclusion (XSSI) attacks.

Belongs here as well, but need to find good category name

• outcome from Discussion: serving content when resource is not meant to be accessed directly #1009 - "Do not serve the content when the resource is not meant to be accessed directly"
• outcome from New Requirement on Browser Version Checking #959 (comment) - "Verify that the web application warns users using an old browser that does not support HTTP security features on which the application relies."

WebSocket

Where to keep V13.5 WebSocket category?

[tghosth]

Are you proposing a new chapter with controls that are enforced by the browser?

If so, I have a few thoughts:

• It seems like the HTTP response headers section + 14.5.3 are server configs which control how the browser enforces security so I agree this is the right place.
• 14.2.3 is a page value which controls how the browser enforces security so I agree this is the right place.
• 4.2.3 is a control that is enforced by JavaScript within the browser but not actually by the browser. But it is still client side so I agree this is the right place.
• 4.2.2 seems like it is in the wrong place. CSRF protection is enforced by the server, the client just has to provide the correct headers, parameters, etc. I don't think this is the right place I would count this as a client side enforced control.
• JSONP and sensitive data in javascript are not client enforced controls so I don't think this is the right place.

Is that useful feedback?

[elarlang]

Are you proposing a new chapter with controls that are enforced by the browser?

This chapter should contain requirements, which takes down attack vectors via victim browser. It's more question and being more precise with descriptions and subcategory titles here - but I think that CSRF, JSONP, XSSI ("Confused deputy via victim browser") belongs here - those attacks do not exists without a browser (those are called SSRF then).

Is that useful feedback?

yes, we can move forward

[tghosth]

Ok, the idea of attacks which don't exist without the browser is an interesting one...

That is why you want the requirement from #1299 to be in here?

[elarlang]

Yes, it fits to this criteria.

[tghosth]

Ok, I think you need to create a label for "big decisions" where we get feedback from the other leaders before finalizing. Do you agree? This issue would seem to match that category

[danielcuthbert]

Late to the party but really do like the Client-Side category here as it could encompass other facets of client controls

[elarlang]

Back to this issue. This ping-pong has been here now for one and half year. Conclusions:

title: Proposal: (sub)category "Client-Side" (browser-side)

Goal: to cover all requirements, where an application need to check, was a HTTP request made by the browser/client legit or forced by malicious actor from 3rd party site. It includes attack vectors like CSRF, XSSI, ClickJacking, etc.

Agreement for this proposal from @danielcuthbert is here: #1230 (comment)

Late to the party but really do like the Client-Side category here as it could encompass other facets of client controls

As it was more than a year ago, @danielcuthbert is welcome to recheck and revalidate it.

New question (#1230 (comment)) from @tghosth - should CSRF as option 3 belong to the cateogry.

Agreement from @jmanico is here: #1230 (comment)

I would aim for "requirements that do not fit better elsewhere which fit into category 1 2 or 3 from above"

Client and Server issues are very mixed together. I do not think we should be super specific here.

I have not seen any other proposals.

In CSRF issue - the concept got clarified I guess. In JSONP issue it's written it waits for this issue - why, if it does not belong here?

What else is needed?

If I do the math: time-wasted-to-this-issue * average-pen-test-hour-price, it is one really expensive issue already.

[tghosth]

At this point, I think you should get the PR done. If you want CSRF to go in there as well then go for it, I agree this has dragged on too long.

[jmanico]

At this point, I think you should get the PR done. If you want CSRF to go in there as well then go for it, I agree this has dragged on too long.

Agreed

[elarlang]

special mention for @tghosth

[tghosth]

I have made some proposed changes and included comments with my logic:
elarlang#4

[tghosth]

Elar is working on creating the monster PR for this based on individual commits for each requirement (to help traceability)

[elarlang]

Elar is working on creating the monster PR for this based on individual commits for each requirement (to help traceability)

my idea is actually a bit the opposite - to avoid monster PR and put the content in with small PRs :)

edit: but the monster arrived...

[elarlang]

The new "Web Frontend Security" category is in place, with temporary number V50.

https://github.com/OWASP/ASVS/blob/master/5.0/en/0x50-V50-Web-Frontend-Security.md

There is still a lot of work to do with that, but for those changes it makes sense to open new issue per topic. As a structure change proposal, we can say it is done.

[tghosth]

Great work @elarlang !