🔒fix: CVE 2023 26115 (2)

[OlafConijn]

Fixes #32

CVE-2023-26115
TLDR; ReDoS, the issue is due to Regex matching algo.

This PR proposes an alternative solution to #33 in which:

• string.prototype.trimEnd is not used, as this would break when ran on older nodejs runtimes.
• no (new) regular expressions are vulnerable to ReDoS (e.g. /\s+$/gm).

Performance:

• The custom trimEnd is slower compared to native string.prototype.trimEnd.
• The performance of the trimEnd function however is comparable to the original regular expression.

results here

[sawilde]

string.prototype.trimEnd is not used, as this would break when ran on older nodejs runtimes.

Is there a reason why we can't use the built-in trimEnd if it is available and only revert to a custom implementation when it is not?

[OlafConijn]

Is there a reason why we can't use the built-in trimEnd if it is available and only revert to a custom implementation when it is not?

We certainly could. it would be a nice performance improvement for those running node >=10

I think using the built-in trimEnd requires a slight bit more discussion/thought as this strips out more than just & \t (see here). As the library is used widely it is hard to oversee the effects of changing the implementation to use trimEnd.

I do think it's more likely to be an improvement than a regression. I would hoever advocate for making it a different release where consumers can roll back on the trimEnd change without having to roll back to a version that is vulnerable to CVE 2023 26115.

[doowb]

Thanks @OlafConijn !

I'm merging and publishing this fix now.