security: SNYK-JS-CLASSVALIDATOR-1730566

[j-ibarra]

Description

https://security.snyk.io/vuln/SNYK-JS-CLASSVALIDATOR-1730566

Affected versions of this package are vulnerable to Improper Input Validation via bypassing the input validation in validate(), which can lead to cross-site scripting (XSS) or SQL injection. NOTE: There is an optional forbidUnknownValues parameter that can be used to reduce the risk of this bypass.

[Borales]

@NoNameProvided hi, is there any update on this? it's been 3.5 months since SNYK's report.

[jmadan]

Any update on this?

[Shereef]

For the people asking if there's any update. I don't think there will be.

However, feel free to use this easy fix:

1. npm uninstall class-validator
2. npm install @nestjs/class-validator
3. search your project for from 'class-validator' and replace it with from '@nestjs/class-validator'

P.S. This is what I did and it fits my project and it doesn't necessarily mean that you should do it or that it's right.

[braaar]

The lead maintainer of this project has reached out, so we might get some action going here soon. See #1719

[braaar]

I've closed all duplicates and left this issue up.

@NoNameProvided – this security issue has led some to switch over to @nestjs/class-validator. I think this should have a high priority

[NoNameProvided]

I have reflected on this issue in the closed issues, I will copy it here as well for reference.

Hi all!

Sorry for the long overdue update, I would like to chime in to clarify a few things.

First of all, as mentioned before in other threads the reported issue is not a security vulnerability in the sense that you can defend against it by specifying the forbidUnknownValues: true option.

I still think this was opened by mistake and it's the same as if I would open a vulnerability report on NodeJS saying "if I turn off the server the NodeJS application crashes". The valid (and fixed) problem was in the class-transformer package that I fixed in a rather speedy manner in under 10 days from disclosure. (The fastest fix from the 3 affected packages.) That issue was properly reported privately to me with a pentest report explaining the attack vector.

A second problem is that for this vulnerability I was never provided a reproducible test case officially, saying: this is what failing and needs to be fixed. The closest to an official example is from the issue in this repository that is linked in the security reports: #438. Running that example code shows the issue is fixed for almost a year now.

Code snippet from #438

import { validate, IsInt, Length, IsEmail, IsFQDN, IsDate, Min, Max } from "class-validator"; 
import { plainToClass } from "class-transformer";

class Post {
  @Length(10, 20) 
  title: string; 
  
  @IsInt() 
  @Min(0) 
  @Max(10) 
  rating: number; 
  
  @IsEmail() 
  email: string; 
  
  @IsFQDN() 
  site: string; 
  
  @IsDate() 
  createDate: Date;
}

let userJson = JSON.parse('{"title":1233, "proto":{}}'); // a malformed input 
let users = plainToClass(Post, userJson);

validate(users, { forbidUnknownValues: true }).then(errors => { // errors is an array of validation errors 
  if (errors.length > 0) { 
    console.log("validation failed. errors: ", errors); 
  } else { 
    console.log("validation succeed"); 
  } 
});

This code fails with validation errors as expected.

So you may ask why the security advisory is still open? That's the million-dollar question, and the answer is that when you try to write to someone they will redirect to someone else who will redirect to someone else who will redirect to the first org. It's a circle and everybody says: "sorry I just source my data from someone else", I cannot do anything for you.

Another contributor tried to write to them, and I have tried to write to them. No success.

The mistake I made was that after a while I stopped trying. I knew the issue don't exist so I am using it without worrying, but I see how an open critical advisory is scary for others.

To sum up my plan for going at it again:

• I will flip the default settings for forbidUnknownValues and make a release so there is literally zero ground to say this is a vulnerability
• I will try to contact the SNYK and other organizations again to tell them the issue is not present
• I will repeat step two until someone actually can update the security advisory

Also, it is worth noting that the other package under the NestJS org doesn't fix any issues. The security warning is not present there because it has a different name, not because the "problem is fixed".

[NoNameProvided]

The proposed fix of changing forbidUnknownValues to true by default has landed in #1798. (Not released yet.)

[hoanglinhtan]

@NoNameProvided when does this expect to release?

[michaeljauk]

Hey @NoNameProvided bumping this to the top of your inbox. When can we expect a new release?

[NoNameProvided]

Thanks for the reminder, but it is top of my inbox/head. I am first trying to coordinate with the NestJS lead maintainer (only wrote him today) to make the breaking change more visible for NestJS users. (Last time it didn't go to well, and the NestJS project has a lot of open issues not knowing what is going on.)

I plan to do a release on Sunday regardless if I can discuss it with the NestJS team or not.

[NoNameProvided]

I quietly note, that doing a release will not make the security warning go away. The real task only belongs after that, when I have to email everyone and try to explain to them, that this lib is fixed and they keep redirecting me in a circle or maybe things improved since then and I will get it quickly resolved. We will see.

[NoNameProvided]

The default settings for forbidUnknownValues has been changed to true in 0.14.0.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.