Closed KatsuragiCSL closed 1 year ago
Must be fixed in https://github.com/SamVerschueren/decode-uri-component/issues/5
Is it an option to simply get rid of this dependency and use the built in decodeURIComponent
instead?
my advice is to ditch the vulnerable library. The issue was identified on the project in August and hasn't been fixed yet. The project hasn't had any meaningful activity on it in 3 years. Either fork and fix and use the forked repo or migrate away from it. We are seeing this as well, too.
Is it an option to simply get rid of this dependency and use the built in
decodeURIComponent
instead? I will upset you, but even in thedecodeURIComponent
it does not work correctly
I looked at this library and all it does is replacing +
with a space, and only if the native decodeURIComponent
throws an error, it attempts to parse the string itself. So anything it crashes on is something that decodeURIComponent
also crashes on.
I guess I anyway don't understand why this is considered a vulnerability.
@wzijden apparentely, someone decided it would be brilliant idea to start filing any unexpected exceptions caused by input (which even in very far fetched cases might be inputted by remote user) in libraries as DoS vulnerabilities. Not the first I see this kind of reasoning
I'll try to get a release out today.
People see to be very friendly nowadays. Piling up my Twitter DMs because Snyk seems to mark this as high severity...
I'll try to get a release out today.
People see to be very friendly nowadays. Piling up my Twitter DMs because Snyk seems to mark this as high severity...
The problem is that this is not your vulnerability, but the vulnerability of a native function, which for some reason was shifted to you
I'll try to get a release out today.
People see to be very friendly nowadays. Piling up my Twitter DMs because Snyk seems to mark this as high severity...
I understand, there you need another try-catch block
I see that decode-uri-component is upgraded to 0.2.2, but it also has the same issue
Have you actually tried it?
https://stackblitz.com/edit/node-fhizma?file=index.js
@sindresorhus I think you can close this issue now.
Regarding the Snyk "vulnerability". I'm in contact with them to see what needs to happen but that is unrelated to this issue.
Version:
v7.1.1
Crash occured when
# kun%ea%ba%5a%ba
is parsed byqueryString.parse
This hash is valid and should be parsed correctly as{ ' kun%ea%ba%5a%ba': null }
For example in chrome's development tools' console the urlhttps://google.com# kun%ea%ba%5a%ba
can be parsed without problems:Code to reproduce
Results
TypeError: decodeComponents(...).join is not a function