Inappropriate content (Testing for Cross Site Script Inclusion)

[yhojann-cl]

4.11.13 Testing for Cross Site Script Inclusion is not a WEB vulnerability, is a Web Browser application vulnrability. The WSTG is a framework for WEB aplications testing and 4.11 is for client side applications but no client applications. This vulnerability only can affect to specific browsers like as ie6, in this case you need include all other cve vulnerabilities or all other browsers like as how to broken the origin policy from ie8.

This document shouldn't be.

[kingthorin]

XSS is not limited to only old browsers, feel free to check with any modern pen tester or bug bounty hunter.

[ThunderSon]

Hello @yhojann-cl
Thanks for raising this for us.

1. Why are you targeting exactly inclusion attacks?
2. What references do you have that this only targets specific browsers?

@kingthorin FYI for us, we are missing references in that section. Or maybe my phone is glitching. We need to add some refs for it 🤔

[kingthorin]

Sorry, was working from my cell. I see what you’re talking about, we’ll review the section.

[yhojann-cl]

the vulnerability refers to a web browser problem when processing embedded resources with mixed or insecure content, it is not a security problem in the programming of a web application even though it may have some type of mitigation, this means that they should be included all types of software vulnerabilities in web browsers and servers, I think this documentation is not what you are looking for if you want to test the web application instead of the infrastructure or the environment.

For example, in internet explorer 6 it was possible to extract information between cross-sites because there was no same-origin policy or the universal xss for ie8, you can prevent the universal xss but I think that is beyond the scope of this documentation. In web software development, you create applications with security in mind by design and do not create patches for each type of vulnerability for each type of web browser.

[ThunderSon]

In that logic, CSRF attacks should be handled by the browser, and not by the developer, because it's an inherent problem with the browser sending cookies every request to website A.

We don't test a website to how it behaves on the server only, it's how it's behaving on browser as well. It is part of the "Web", otherwise we'd have called it "mobile" 😉

If you have a problem with XSSI on your website, then you need to fix it. I don't think a web developer will look at an XSSI problem where someone can steal data and say "oh, it's the browser's problem".

This documentation is a book, it details IE6/8/<version> because that's historical knowledge, and that's important for people to learn how things behaved in the previous era. Yes, they're unexploitable right now, but they matter.

In web software development, you create applications with security in mind by design and do not create patches for each type of vulnerability for each type of web browser.

Well, by design, you should include CSRF tokens then, enforce POST requests with a certain flow, or whatever works best for your application. If you know about the attack, you're not "patching", you're bolting security measures into your web service.

[yhojann-cl]

In that logic, CSRF attacks should be handled by the browser, and not by the developer, because it's an inherent problem with the browser sending cookies every request to website A.

It is a very different case because it is not a vulnerability of the WEB browser nor is it the browser in charge of controlling this type of situation since the current http standard does not request it in that way, it is very different from having a vulnerability that allows to omit or circumvent an existing and standard security mechanism such as same-origin policies.

I understand that this is a very recurring problem at the time and that today it is no longer exploitable, just like TRACE attacks to obtain cookies since modern browsers do not allow TRACE requests to be made through fetch or xmlhttp, the issue It is not whether it is a vulnerability or not, but to whom it belongs, to the application or the client browser, it is a categorization problem and not to recognize whether it is a vulnerability or not.

My point of view is that if it is allowed to document the vulnerability of a client browser beyond the security problems at the development level categorized through a CWE, then we should include all the CVE of all WEB browsers that allow code execution or some type of evasion that allows any layer of protection to be violated. I think that is not the purpose of this documentation.

[rbsec]

@yhojann-cl I don't think I'd agree that XSSI is a vulnerability in the web browser. If we take the first example in the guide, exploiting it basically relies on three thing:

1. When a browser makes a cross-domain request from a <script> tag, it includes the cookies of the target domain (victim.com).
2. When a browser executes code JavaScript from a <script> tag, it executes it in the context of the calling domain (attackingwebsite.com)
3. The JavaScript file on victim.com contains sensitive information that isn't exposed to anonymous users.

Points 1 and 2 aren't really vulnerabilities in the browser: they're fundamental parts of how the web standards, and are present in all(?) modern browsers. There are no CVEs for points 1 and 2 (and won't ever be), and they can't be "fixed" by upgrading your browser to a newer patched version, because they're part of the core functionality. This is quite different things like the broken same-origin policies or universal XSS issues you mentioned, because those are implementation issues in specific versions of browsers, which were subsequently fixed.

The problem only comes when they're combined with point 3 - which is something that's under the control of the web developer.

I think a (somewhat simplified) way to view whether something should be in the WSTG is to think about how to fix the issue. If the recommendation is "patch your browser", then it probably shouldn't be there. If it's "change some code on your website" then it's probably appropriate. And XSSI falls more into the latter category.

[NiedziolkaMichal]

1. When a browser makes a cross-domain request from a <script> tag, it includes the cookies of the target domain (victim.com).

That's not true. In Google Chrome since version 85, cookies have SameSite flag set to Lax but default, which makes them inaccessible by <script src=""></script>.
Firefox will not include cookies of the target domain in such a request, even if SameSite is explicitly set to None. Users can change this behavior by opting out of standard protection.
In Safari, such request also doesn't work, but I didn't find any way to allow it.