ASVS
ASVS copied to clipboard
OWASP
Proposal: subcategory "HTTP request source validation"
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:
- https://github.com/OWASP/ASVS/issues/903#issuecomment-896814258
- https://github.com/OWASP/ASVS/issues/1220#issuecomment-1035200681
- https://github.com/OWASP/ASVS/issues/795#issuecomment-743720732
Or... to create "Browser communication" (in whatever correct wording) category which should contain additionally:
- general cookie setup (https://github.com/OWASP/ASVS/issues/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:
- https://github.com/OWASP/ASVS/issues/1229
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.
depends on related discussion https://github.com/OWASP/ASVS/issues/1220#issuecomment-1035200681
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.
... 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.
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?
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 https://github.com/OWASP/ASVS/issues/903 - Verify that JSONP functionality is not enabled anywhere across the application to avoid Cross-Site Script Inclusion (XSSI) attacks. | ||||
| TBD | outcome from https://github.com/OWASP/ASVS/issues/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 https://github.com/OWASP/ASVS/issues/1009 - "Do not serve the content when the resource is not meant to be accessed directly"
- outcome from https://github.com/OWASP/ASVS/issues/959#issuecomment-1172990290 - "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?
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?
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
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?
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
Late to the party but really do like the Client-Side category here as it could encompass other facets of client controls
ping @tghosth , can we move on with this?
This "Client-Side"... instead of abstract "Client" we should have "Browser" in the category title but how exactly, I don't know and need help with wordsmithing this. Or maybe just "Browser"?
Ok, we are going back and forth on this and I am still struggling with this.
What is the definition of requirement that fits into this section.
Possibilities that I have either seen or have imagined include:
- Requirements for controls that are implemented in the application front-end (post message verification, Sub-resource Integrity, safe JSONP etc)
- Requirements for controls that are enforced in the browser (all the above plus a whole load same-origin/cross-origin/CSP stuff which is enforced by server headers)
- Requirements designed to prevent attacks that would not exist if it was not for the browser (all of the above but now including things like XSS and CSRF)
@elarlang, what do you think?
Doh, sorry, I should have been more clear. Which of the above do you think is the correct definition. I personally think definition 3 is too wide.
I don't love definition 2 either because I think it pulls controls which have a server-side implementation into a client side section.
What do you think?
My idea is basically option 3. Then all browser-combination related requirements are in one place and easier to follow and skip (in machine-to-machine application situation).
@jmanico @danielcuthbert + ASVS WG.
Can you provide your input on this question.
Elar suggested creating a new ASVS section for "client side" issues which I think makes a lot of sense. However, we are not sure what the definition of the section should be, i.e. which requirements would go into it.
I have come up with 3 potential definitions:
- Requirements for controls that are implemented in the application front-end (post message verification, Sub-resource Integrity, safe JSONP etc)
- Requirements for controls that are enforced in the browser (all the above plus a whole load same-origin/cross-origin/CSP stuff which is enforced by server headers)
- Requirements designed to prevent attacks that would not exist if it was not for the browser (all of the above but now including things like XSS and CSRF)
My perspective:
I believe option 1 or maybe 2. I personally think option 3 is too wide. I don't love option 2 either because I think it pulls controls which have a server-side implementation into a client side section.
@elarlang's perspective:
My idea is basically option 3. Then all browser-combination related requirements are in one place and easier to follow and skip (in machine-to-machine application situation).
What do you all think?
Clarification for option 3: I would keep so-called XSS away from this, ass "XSS" is mostly encoding or escaping problem and happens on the server side as well (classical example - HTML injection during "HTML to PDF" conversions, which leads to SSRF etc).
CSRF belongs here.
If you opt for Option 3, it could become a very large category. Option 1 maintains a laser focus on client-side code but may miss the broader context that some of the controls (like Content Security Policies) set by the server are actually to control client-side behavior. Regardless of the choice, the name "Client-Side" may be misleading. As mentioned, these controls are more browser-specific than client-specific. I am in favor of option 1 and 2.
On the side note: Certainly, the importance of Content Security Policy (CSP) in mitigating Cross-Site Scripting (XSS) attacks is well-understood. However, the implementation is where many businesses falter, often leaving vulnerabilities in the system that attackers can exploit. A poorly implemented CSP is almost as bad as having no CSP at all. With that in mind, I recommend the following modification to item 14.4.3:
14.4.3 Verify that a robust Content Security Policy (CSP) is in place and effective in mitigating the impact of XSS attacks, including but not limited to HTML, DOM, CSS, JSON, and JavaScript injection vulnerabilities.
and we can put this as a side note:
Note: A CSP should be assessed for effectiveness. We recommend the usage of CSP evaluation tools, such as Google's CSP Evaluator, to validate that the policy does not have loopholes that attackers could exploit.
"Client-side" is not the best title, as it is "browser-side" by content. This is written here: https://github.com/OWASP/ASVS/issues/1230#issuecomment-1287381350 and https://github.com/OWASP/ASVS/issues/1230#issuecomment-1678931226. I changed the issue title to point it out more.
Also potential structure and requirements are listed there - I can not see that the category is "too big". The difference between option 2 and option 3 are few CSRF-style requirements....
Let's keep the focus here how to define the new category, for CSP we have separate issue (https://github.com/OWASP/ASVS/issues/1311).
One more comment - if option 3 does not suit for you, please come up with solution and proposals where CSRF requirement should be located? Like issue https://github.com/OWASP/ASVS/issues/1652 .
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.
Well, I think we have general agreement, that we will create new category - the main discussion/problem topic here seems to be our (me and Josh) different view on CSRF topic.
As there are other requirements waiting to get into the document, I prefer to move forward with this - let's get requirements into place when we have agreement and have separate discussion for those where we don't have agreement yet. Otherwise there is another year walking around the issue and we never reach anywhere.
My main goal is to get new requirements from issues to document what they get more attention and feedback for validation. Most likely we are going to make changes to the structure anyway and there is no need to find "the one, perfect and final" structure right now.
@elarlang do you want to open a PR that start things assuming definition 2 above?
I can do.. just "tiny" help needed - what would be the category name? :)
It can not be "Client-Side" (like written https://github.com/OWASP/ASVS/issues/1230#issuecomment-1287381350) because it is misleading as requirements are limited only to browser (which is just one type of client).
- Browser Related
- Browser Specific
- ???
And again - maybe during the process of doing it we figure out that there are better ways, like creating subcategories to other big categories (like in V8 at the moment is "Client-side Data Protection"). But it also requires we have grouped similar requirements together to some subcategories and then it's easier to move them around together.