search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.7k stars 658 forks source link

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

Closed elarlang closed 9 months ago

elarlang commented 2 years ago

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:

elarlang commented 2 years ago

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

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

tghosth commented 2 years ago

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 commented 2 years ago

@elarlang what are our next steps on this?

elarlang commented 2 years ago

depends on related discussion https://github.com/OWASP/ASVS/issues/1220#issuecomment-1035200681

tghosth commented 2 years ago

I just asked you a question there :)

elarlang commented 2 years ago

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 commented 1 year ago

... 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 commented 1 year ago

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 commented 1 year ago

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:

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

WebSocket

Where to keep V13.5 WebSocket category?

tghosth commented 1 year ago

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

If so, I have a few thoughts:

Is that useful feedback?

elarlang commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Yes, it fits to this criteria.

tghosth commented 1 year ago

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 commented 1 year ago

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

elarlang commented 1 year ago

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"?

elarlang commented 1 year ago

. o O ( .. hello? )

tghosth commented 1 year ago

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:

  1. Requirements for controls that are implemented in the application front-end (post message verification, Sub-resource Integrity, safe JSONP etc)
  2. 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)
  3. 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?

elarlang commented 1 year ago

Yes, seems correct.

tghosth commented 1 year ago

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?

elarlang commented 1 year ago

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).

tghosth commented 1 year ago

@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:

  1. Requirements for controls that are implemented in the application front-end (post message verification, Sub-resource Integrity, safe JSONP etc)
  2. 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)
  3. 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?

elarlang commented 1 year ago

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.

ImanSharaf commented 1 year ago

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.

elarlang commented 1 year ago

"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).

elarlang commented 1 year ago

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 .

jmanico commented 1 year ago

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.

elarlang commented 1 year ago

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.

tghosth commented 1 year ago

@elarlang do you want to open a PR that start things assuming definition 2 above?

elarlang commented 1 year ago

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).

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.

jmanico commented 1 year ago

How about

"Browser Based Client Apps" or just "Browser-Based Security"

csfreak92 commented 12 months ago

I am also late to the party, but upon tracing all the threads and related comments, whew that was long, I agree with @elarlang's idea to have this category for browser-related security controls, but it was also discussed that there are some of the mentioned controls that could be mixed with server-side controls as well. Without getting into too much depth, I would say let's settle first with the browser-based related controls and then deal with the server-side matters later (such as CSRF which can also be a mix of controls on both sides).

Regarding the naming for this category, since we are kind of agreeing that these controls Elar has pointed out should be related to the browser, I would propose and would throw in a few more word-smitten titles if you may indulge:

I realize it could add more confusion, but these could also be something for us to vote on as options if we cannot agree with the previously proposed options. :)

What do you guys think?

On another note: I suggest us to have a touch base sessions or whatever works so that issues don't get too long and connected to so many comments and issues to read before any reader trying to figure out what's going on in a certain discussion. Just my 2 cents so that we can close issues easier. :)

tghosth commented 12 months ago

I agree with:

@elarlang, pick one :)

tghosth commented 12 months ago

On another note: I suggest us to have a touch base sessions or whatever works so that issues don't get too long and connected to so many comments and issues to read before any reader trying to figure out what's going on in a certain discussion. Just my 2 cents so that we can close issues easier. :)

Hoping that we will be able to start WG sessions to help with this but honestly I think it is also important that the deliberations are documented here in the open.

csfreak92 commented 12 months ago

On another note: I suggest us to have a touch base sessions or whatever works so that issues don't get too long and connected to so many comments and issues to read before any reader trying to figure out what's going on in a certain discussion. Just my 2 cents so that we can close issues easier. :)

Hoping that we will be able to start WG sessions to help with this but honestly I think it is also important that the deliberations are documented here in the open.

Definitely, deliberations will be documented in the open but what I mean is a touch base of let's say quarterly for huge changes so that it doesn't take long to close it.

elarlang commented 12 months ago

Well, I don't like those off-topics and "side notes", because those are exactly the reasons why it is complicated to follow some issue later.

Here, as it is rised - in theory it is nice and simple "let's discuss everything with some meeting and report the results". In practice, every tiny piece may require huge and time-consuming individual research and investigation, some require "sleeping on it" and settle a bit before comes some good solution how to solve it. With quick meeting it is possible to close "easy issues", but those easy issues does not need any meetings.

Meetings are good to change information fast on different topics, but it does not take away the need for research.

elarlang commented 12 months ago

I agree with:

  • Browser-Based Security (@jmanico)
  • Browser-Based Protections (@csfreak)

@elarlang, pick one :)

"Browser-Based" is the wording to avoid CSRF included later? :)

tghosth commented 11 months ago

I agree with:

  • Browser-Based Security (@jmanico)
  • Browser-Based Protections (@csfreak)

@elarlang, pick one :)

"Browser-Based" is the wording to avoid CSRF included later? :)

You have an alternative suggestion @elarlang :) ?

elarlang commented 11 months ago

Well, I think we need to keep CSRF category in mind (https://github.com/OWASP/ASVS/issues/1652).

The main initial reason for proposing "client-side" category was to find logical place for CSRF requirement(s). By current wording and proposal new category will not have CSRF requirements, those are still in incorrect place (in authorization category).

I think it makes sense to solve those together - if CSRF will not fit to "browser-based *" category, @tghosth - do you have any other ideas where it should be relocated?

tghosth commented 11 months ago

Sorry, I got confused. I have written my thought on #1652 but basically I still don't think CSRF belongs here.

I would recommend we stick go with "Browser-Based Security"

elarlang commented 11 months ago

I think entire ping-pong here relies on one not-answered (https://github.com/OWASP/ASVS/issues/1652#issuecomment-1760938108) question - what is the perspective for ASVS

ASVS stands for Application Security Verification Standard. It is for Security Verification. Clearly testing perspective.

It is not developers checklist. ASVS must be understandable for developers, but it will not replace or duplicate educating them for development (for that we have cheat sheet series project) or provide testing checklist (for that we have testing guide project)

Josh via https://github.com/OWASP/ASVS/issues/1652#issuecomment-1710000249

You could argue that from a tester perspective, this is a client side attack but from a developers perspective this is a server-side control.

Elar via https://github.com/OWASP/ASVS/issues/1760#issuecomment-1767682777 (and https://github.com/OWASP/ASVS/issues/1760#issuecomment-1775642686)

In general, maybe it's more point of view - I don't watch ASVS as testing framework which need to cover all test-cases, but reporting framework, which you can use to report your findings.

Josh via https://github.com/OWASP/ASVS/issues/1760#issuecomment-1776619114

Firstly, my overall preference is that we should have a single requirement per separate protection mechanism which is needed. To me ASVS is most important as a standard for developers as otherwise we won't really have anything to verify :)

From developers perspective or from developers checklist perspective it may make sense to consider Cross-Site Request Forgery as server-side check, but this is only when cookie-based sessions are used.

For API - one of the defenses against CSRF is to check Origin - yes, on the server side, but information provided by browser - is 14.5.3 server-side or browser-side requirement?

For API - one of the defenses against CSRF is to check request Content-Type, that if it is not CORS-safelisted (previously known as "simple request"), it fires Pre-flight request - is 13.2.5 server-side or browser-side?

In this issue, the question is not only about CSRF - the question is also for XSSI, JSONP (or so called "confused deputy" things).

The main point is.. or was - to have requirements which should take down attacks via victim browser in one category. Let's say we move on with "CSRF is not included" in "browser category". If CSRF is not included, then the same question rises to 13.2.5, 14.5.3 etc. For me it make things more confusing - some browser (attacker perspetive) related requirements are in one place, some are in another place.

Basically, I don't see the point for "partial browser related requirements" category. In this situation it do not make anything clearer, it do not provide possibility to skip one clear browser-related requirements from machine-to-machine testing etc. And you go crazy with the same-style philosophy for many requirements, is the control more on the server-side or more on the browser side. They all belong to the same category or there is not point to create the category.

Last one for explaining the idea and proposal.

We don't need to create the category, but I can not see any proposed alternative or argumented solutions:

tghosth commented 10 months ago

what is the perspective for ASVS

From the Preface:

The ASVS is a community-driven effort to establish a standard that defines the functional and non-functional security requirements to consider when designing, developing and testing modern web applications and web services.

From Using the ASVS

In the contents [sic, should be context] of secure requirements, the ASVS should be useful to anyone trying to:

  • Develop and maintain secure applications.
  • Evaluate the security of applications.

As such, despite the name it does appear to be apply equal weight to both sides.

I personally attach a lot of importance to the developer side because I think that this is where it provides a lot of value but I accept that this is just my opinion/perspective :)

With all that being said, I think the most important thing is not to let perfect become the enemy of good. If we have a new section or chapter which is good for a lot of cases, let's not worry that it doesn't fit every single case. I think this chapter adds value and nicely collects certain requirements.

elarlang commented 10 months ago

With all that being said, I think the most important thing is not to let perfect become the enemy of good. If we have a new section or chapter which is good for a lot of cases, let's not worry that it doesn't fit every single case. I think this chapter adds value and nicely collects certain requirements.

... or let's not worry not all the requirements belonging to the category fits here based on everyone perspective? If we don't need to worry, why we can not put those requirements here?

I don't want to go to some demagogy competition here. For me, the concept for the category do not exists if we need to have the same fight for every similar issue. No point to waste more time for that.

Re-using the question from my last comment:

We don't need to create the category, but I can not see any proposed alternative or argumented solutions:

elarlang commented 10 months ago

As such, despite the name it does appear to be apply equal weight to both sides.

Sorry for #nofilter, but this is demagogy. (filter applied here)

The ASVS is a community-driven effort to establish a standard that defines the functional and non-functional security requirements to consider when designing, developing and testing modern web applications and web services.

So it says clearly - it is security requirements and you need consider them doing x-y-z. First focus - security requirements, second focus - consider when...

In the contents [sic, should be context] of secure requirements, the ASVS should be useful to anyone trying to:

  • Develop and maintain secure applications.
  • Evaluate the security of applications.

Of course in ASVS document you need to sell the need for ASVS for everyone - It says "it should be useful" and it is correct, it is useful for developers but it do not convert it to developer-guide, there is cheat sheet project for that.

I personally attach a lot of importance to the developer side because I think that this is where it provides a lot of value but I accept that this is just my opinion/perspective :)

I reference ASVS in my Web Application Security training a lot as well, to make developers aware of security requirements - why those exists and what kind of attacks and how should be avoided. But it does not change ASVS to developer guide - I just reference it as they need to know it as well and it is better for them to know it before they get it to know via pen-test report.

But whatever it is said in the ASVS document previously can be fixed or corrected among hundreds of other things we fix - but the name for the project stays.

The project name is Application Security Verification Standard. If to some product is written "it is X", but is does not contain it - it's fooling the user or customer. So it must contain security verification requirements.

Why the project is used? For verifying application security. Not teaching developers. Developers need to consider those security requirements and those are useful for them to understand how to verify their own product security.

How ASVS is used world-wide? For teaching developers or verifying application security?

Why -some-big-name-company- wanted to use ASVS for their partners? To use it for verifying product security or teaching developers.

Why so much fuzz "out of nowhere" - I think we have some requirements hanging already because of different understanding of the concept of ASVS. From some moment it is not possible to write two different point of views to the same document.

elarlang commented 10 months ago

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: https://github.com/OWASP/ASVS/issues/1230#issuecomment-1304440841

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 (https://github.com/OWASP/ASVS/issues/1230#issuecomment-1717194144) from @tghosth - should CSRF as option 3 belong to the cateogry.

Agreement from @jmanico is here: https://github.com/OWASP/ASVS/issues/1230#issuecomment-1719687723

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

special mention for @tghosth

tghosth commented 10 months ago

I have made some proposed changes and included comments with my logic: https://github.com/elarlang/ASVS/pull/4

tghosth commented 9 months ago

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