[crtlaltdel]

noticing a lot of comments about how this is a “javascript” problem. i just want to clarify whether or not people are asserting this is a _language design_ issue, or an implementation of the runtime specifically within the context of web browsers and web servers?

is this a js problem?

[danShumway]

No, it has very little if anything to do with Javascript. My charitable reading is that people are using JS as a colloquial term to refer to the Web as a platform in general.

To the extent that it's a browser problem at all, it's a problem with how browsers as a platform handle HTTP requests and site-isolation, which is a security system that predates Javascript.

[yoloClin]

The issue is an injection attack. The ability to insert either unsanitised HTML data or data reflected inside the context of a JavaScript code block which results in JavaScript execution (by <script> tags, being able to specify data in DOM element events such as onClick or onError, or being able to specify code in onClick/onError events). I don't consider this a flaw in JavaScript itself, rather how JavaScript is harnessed from HTML.

Once JavaScript execution is obtained* it's possible to inject a JavaScript keylogger and/or rewrite the DOM to request authentication details from the victim (resulting in credential compromise). Alternatively, it's possible use AJAX to perform GET/POST requests to the same domain, routed through the victims browser which includes all cookies etc - effectively this is a time-boxed account compromise (CSRF controls do not apply when requests are executed from the local domain).

It's also possible to coerce a browser into triggering the exploit in a hidden iframe on a completely different page (eg you browse to evil.com, there's a hidden iframe which exploits an XSS vulnerability on facebook.com, compromising your facebook account if your currently logged into facebook on the exploited browser). I'm pretty sure samesite=strict only fix this if the XSS vector on facebook.com requires the user to be authenticated prior to exploitation, similarly, samesite=lax will not prevent attacks which require authenticated POST primitives.

*I'm a pentester, so that's sometimes my job, I don't break laws.

[adt2bt]

IMO, yes and no. The language design isn’t to blame. The libraries and runtime that are colloquially known as JS are. It’s hard to separate the two in discussion so the term js is a bit overloaded.

[temporallobe]

Thanks for pointing this out because I was just going to say the same thing. It’s most definitely not a Javascript problem, as Javascript is just a language, and nothing about the language design is inherently insecure. The problems are with the implementation of the browsers’ security mechanisms, some of which are indeed controlled via JS.