Fix for new security vulnerabilities? CVE-2019-11002, CVE-2019-11003, CVE-2019-11004

[kiere]

Github is alerting us that materialize-css 1.0.0 has vulnerabilities. Are you aware of this and do you know when a fix will be released?

[FINDarkside]

See: #6286

[DanielRuf]

v0.x is not developed anymore. Only 1.x will get updates. There are no patches (yet) as this would break many things.

In general the whole situation was badly handled - no responsible disclosure or coordination, a missing understanding that all of them are no real XSS vulns (it's possible but only if the user / developer uses user input without sanitization).

So far you can ignore the security warning if you do not directly output and use user input in tooltip, toast and autocomplete.

[kiere]

I can ignore it, but my clients who see these in their Github repo are NOT happy about it. 😳

Not sure about the 0.x comment since we use 1.0.0.

[DanielRuf]

Also these 3 are low severity.
Often not all vulns are patched or can be patched (so easily).

See https://www.npmjs.com/advisories for example.

[DanielRuf]

Also to make this right. These are no real XSS. Only if you use this the wrong way.

It is improper input validation in MaterializeCSS (CWE 20), not XSS (CWE 79). Only if you directly handle any user controllable data in there. This should not be mixed.

See http://cwe.mitre.org/data/definitions/20.html

[FINDarkside]

These are no real XSS.

I'm not sure why you're still going with this narrative. Autocomplete vulnerability is almost textbook example of XSS, see DOM based XSS for reference. Autocomplete tries to strip HTML out before rendering, but fails to do it properly. It never supported having html as input, so it's very big stretch to call it a "feature".

It's also a bit alarming how you think that it's ok or normal to intentionally have open vulnerabilities. Sure, there are lots of packages with unpatched vulnerabilities, but pretty much all of those packages are packages that no one uses and nobody probably maintains anymore. I agree that changing tooltip behavior would be breaking change. Fixing autocomplete, however, wouldn't be breaking change as it didn't really support HTML in the first place as explained here. And as also explained there, to "sanitize" your input, you must double escape your user input, which will prevent XSS, but will break autocompletion. It's in no way reasonable to expect for developers to know that you're supposed to double escape your input. I'm also willing to bet this isn't intended feature like you claim it is.

Even in the very unlikely case that it was intended, it would still be a vulnerability, as it's completely undocumented. With libraries as popular as this, security should be taken very seriously.

[lucianot54]

@kiere, you need just be careful if you use Tooltip, Autocomplete and Toast. If you didn't use this JavaScript feature, you can ignore warnings. The problem is MaterializeCss does not sanitize your HTML content and it's possible to inject a XSS.

v0.x is not developed. Only 1.x will get updates. There are no patches (yet) as this would break many things.

0.x is vulnerable too, I hope to see a v0.100.3.

[tflori]

I've read everything in both issues now. And it is really annoying to read everytime the same argument from @FINDarkside. DOM based XSS example is about <option> tags that don't support html by default. It would not make sense to allow html there.

Anyway: the website writes you should not output url input (an attacker could send this link to a victim). When using materializecss autocomplete the code (not manipulated; you have to write it on your website):

$('input.autocomplete').autocomplete({
  data: {
    document.location.href.substring(document.location.href.indexOf("default=")+8): null,
    'English': null,
  }
});

I agree to @DanielRuf that this is not a vulnerability coming from materializecss. The vulnerability comes from your code when it allows such input to be unsanitized hand over to materializecss..

But on the other hand: it is really supposed to only contain text (html is possible but will be searched and the highlighting is broken) - so it should just be escaped in the output. Sounds like a bug not a vulnerability.

[lucianot54]

Of my point of view, MaterializeCSS is a popular framework and it can offer more securities by default. I found many vulnerables developments who can to be avoid with a better security policy about the render.

https://infomedialtd.github.io/angular2-materialize/#/ModelBindings

• Insert your lastname or your script as feature

With this usage, you break Angular security just because a developper make a mistake. It's just one example. Developpers are responsables but MaterializeCSS can protect this bad usage.

Allow HTML it's a good idea but you can do many things with it, like inject javascript. I'll explain again Angular example. It manage HTML and all datas are sanitazed by default.
Bootstrap sanitize all HTML content with DOMPurify and you can disable it with a configuration.

https://getbootstrap.com/docs/4.3/getting-started/javascript/#sanitizer

HTML is a risk, as a popular framework, MaterializeCSS can reduce this risk and use with the initial usage and more security.

I reviewed the code source and security problems are datas as HTML when the basic funtionality is a simple text. I found again more "bugs" because the code use innerHtml (example: i18n) or images allow a string/url/html.

[tflori]

@lucianot54 You are absolutely right. It can protect you from writing bad code. But it is not a security vulnerability but a feature. And now we have a CVE because of a feature request and that is sad because the people not having a security issue on their page get a warning from their package management system. And maybe they step back from using materializecss because they are afraid the library is unsecure.

Some developers make a great library and others destroy the reputation because they can't distinguish between a vulnerability they created and a vulnerability of the library itself. That makes me sad, sorry.

[FINDarkside]

Dogfalo already confirmed autocomplete rendering html is not a feature, so no point in continuing the argument over this.

That makes me sad, sorry.

I'm not going to waste my time on this anymore. I'll just point out that Snyk has classified this as XSS vulnerability. Having a vulnerability does not "destroy the reputation", not taking them seriously does. The point of this is not to shit on materialize or someone else, it's to keep people safe. You seem to think this is some kind of personal attack. Having vulnerabilities is nothing out of ordinary, even the most popular packages have vulnerabilities at some point. What comes to this being "just a bug", if a bug exposes users to security threat, it is by definition a vulnerability.

[tflori]

Having a vulnerability does not "destroy the reputation"

That's wrong. Of course your installation rate drops when you have a vulnerability.

Snyk has classified this as XSS vulnerability

And the code example shows a code that I have to execute in developer tools to be a victim. Can you send me a link to a page not under your control that executes javascript in my browser? That is the definition of a xss as you can read in the link you sent.

But I have to admit it is wasting of time to discuss if it is xss or not. Now there is an open ticket and it has to be fixed.

[FINDarkside]

So you're really going the route that Snyk doesn't know what a vulnerability and xss is? They've literally made a business of knowing these things.

Can you send me a link to a page not under your control that executes javascript in my browser?

Technically, of course, but that'd be unethical and possibly illegal. We can't use random people's sites to demonstrate security vulnerabilities.

And the code example shows a code that I have to execute in developer tools to be a victim.

I'll try one more time as other PoCs are already public. I'll hope you'll read this with open mind, forget your initial opinion on this topic and just read trough this. Let's assume there's a website which lets you search other users with autocomplete. Kinda like github when you @ them. getUsers will fetch usernames and they will be fed to the autocomplete component. Notice that there is really nothing wrong with those few lines of code in the fiddle. It's using autocomplete as it's supposed to be used according to the documentation. Now, try what happens when you type typethis.

Now you argue that users should sanitize their inputs. There's nothing inherently wrong with the username, so it should be stored as it is. As Dogfalo said, autocomplete is not supposed to render HTML, so there's also no reason to sanitize it before passing it to materialize, right? Materialize is expected to handle the input as text instead of html as shown in the examples. If materialize was handling those usernames as text, sanitizing them would not make sense. If you'd sanitize <Username> to <Username>, materialize should render it as <Username> which is obviously not what you'd want.

But fine, there's another site which actually sanitizes the input. You can confirm that it's now safe to type "typethis". But actually, by sanitizing your input now you've turned the previously safe user <img src=/ onerror="alert(\'xss\')">still not safe to another issue. Try typing still not safe and see the results.

How about double escaping all html characters? That would probably solve the issue, but it'd make autocompletion pretty unusable. So yes, it is completely user preventable, by double sanitizing the input. That however does not mean that this isn't a vulnerability. Autocompletion is not working as it's documented, and if it's used in a way it's documented you'll expose yourself to xss if you autocomplete any user given content. It's absolutely not reasonable to expect developers to somehow know to double escape their inputs, when even the project maintainers didn't know it was necessary.

Now if you still don't agree that this is a vulnerability, that's fine, I doubt there's much that will change you mind. But how many people do you think know that they need to double sanitize their inputs? Probably not many, as this issue was brought up just now. So I think we can agree that majority of people using this do not know it, which means their site is possibly vulnerable. And you're saying that you feel sad because @lucianot54 requested a couple CVE ids? You should instead be happy he found this issue and that people were alerted, so they can fix their site if needed.

[Divine1]

i have been assigned a task to fix these 3 XSS attacks. But, i'm having a hardtime in understanding these XSS attacks.

yes there are many articles online to read about it but i'm able to reproduce only one of the XSS attacks.
This is the one attack i was able to reproduceHaving a textField in a website and allowing user to enter text in the textField . How i reproduced this attack is described below

this is my code for textField <input type="text" id="firstname" value="" />

an user who visits my website enters below value into my textField
a good user will enter this value firstname
a bad user will enter this value firstname" ><script>alert("test");</script>

Usually we do this to handle the form information in the front end

• either getValue from textField using javascript and trigger ajax request to server
• or submit form

in both cases, firstname data in the textField will be received by the server and validated for xss vulnerabilities in the server side code and then stored into the database .

if we consider the data entered by the bad user and If this validation is not done, then while the user via the same website tries to view the stored firstname information, the script which was stored along with firstname would definitely run in the browser. This is an XSS attack,

i'm not able to reproduce any XSS attacks other than this. kindly help me out

it appears to me that XSS attacks can be fixed only by handling the response data carefully in the server side code. i'm confused on why XSS attack vulnerability is reported on this materialize a client side library

[FINDarkside]

Text field is not one of the vulnerable components. If you render user input as html on server side, it's obviously your fault and doesn't really have much to do with materialize. The thing is, that some components in materialize do client side rendering, autocomplete for example. Have you read the comment above your comment, it has 2 PoCs for the autocomplete vulnerability. Here's one of them, type typethis to the autocomplete component.

Also, toast issue isn't really a vulnerability, so there's only 2 vulnerabilities. Both Snyk and npm have released public advisories of the vulnerabilities with autocomplete and tooltip.