XSS Vulnerability "HIGH" due to default escapeHtml=false setting

[nmg196]

The default behaviour of toastr is that html displayed is not encoded.

So this code causes a browser popup:

var msg = 'Hello <script>alert("Danger!")</sc' + 'ript>';
toastr.success("Example <strong>Message</strong> " + msg);

There is a setting which controls this called "escapeHtml". However because this 'fix' is opt-in rather than the default behaviour, it gets flagged in pen tests and security scans as an unfixed HIGH vulnerability.
See: https://security.snyk.io/vuln/SNYK-JS-TOASTR-2396430

Is there no way that escapeHtml = true is the default, and you have to opt in to use HTML instead? Otherwise this library will be permanently flagged as having an XSS vulnerability - category "HIGH", which means it can't be used on many projects.

This would have to be through a new release as current release 2.1.4 is regarded as vulnerable (HIGH) in security scanners:

[peterlaws]

Is this project dead? This issue has been ignored?

[Jacob-Lockwood]

@peterlaws Yes it seems to be dead--the latest release was made in 2018

[peterlaws]

Anyone found a decent similar replacement?

[lucasrochadejesus]

Anyone found a decent similar replacement? [2]

[NkazimuloMvundla]

yes, https://apvarun.github.io/toastify-js/#

[girng]

lol imagine worrying about xss on a toast plugin..

[nmg196]

lol imagine worrying about xss on a toast plugin..

I doubt the nature of the plugin makes any difference to how bad an XSS attack could be.

[girng]

lol imagine worrying about xss on a toast plugin..

I doubt the nature of the plugin makes any difference to how bad an XSS attack could be.

so then why is this an issue? did you even read what you wrote?

[nmg196]

Maybe you didn't understand my point. A hacker exploiting an XSS vulnerability will not care if it's in a Toast plugin or any other kind of plugin - it makes no difference if you can still carry out the attack. How on earth can it make any difference?

[girng]

Maybe you didn't understand my point. A hacker exploiting an XSS vulnerability will not care if it's in a Toast plugin or any other kind of plugin - it makes no difference if you can still carry out the attack. How on earth can it make any difference?

then how is it relevant to this toast library? no one is using toast plugins for xss attacks, lmao. that's the same as saying devs are using eval with user input. well, no duh there's gonna be exploit if they do that 😂

[nmg196]

no one is using toast plugins for xss attacks,

Can you post your source for where you read that nonsense? I can't imagine why a hacker would care what type of plugin they can use if they can hack a major website given it makes NO DIFFERENCE AT ALL.

It's even listed as a HIGH vulnerability on a major 3rd party security site:
https://security.snyk.io/vuln/SNYK-JS-TOASTR-2396430

[girng]

no one is using toast plugins for xss attacks,

Can you post your source for where you read that nonsense? I can't imagine why a hacker would care what type of plugin they can use if they can hack a major website given it makes NO DIFFERENCE AT ALL.

It's even listed as a HIGH vulnerability on a major 3rd party security site: https://security.snyk.io/vuln/SNYK-JS-TOASTR-2396430

the source is this issue we're both in right now (your thread), LOL. this ain't a xss vulnerability for this plugin. that's like saying any js plugin is a xss vulnerability because a dev can use eval in it 😂.

shocker incoming: don't allow custom user input for html or eval. that's not the plugin's fault, it's the developer's