Vulnerable Regular Expression
cristianstaicu opened this issue · comments
The following regular expression used for parsing the cookie is vulnerable to ReDoS:
/^(([^=;]+))\s*=\s*([^\n\r\0]*)/The slowdown is moderately low: for 50.000 characters around 2.5 seconds matching time. However, I would still suggest one of the following:
- remove the regex,
- limit the number of characters that can be matched by the repetition,
- limit the input size.
I noticed there is another bug report regarding the correctness of this regular expression.
If needed, I can provide an actual example showing the slowdown.
Nice find. An actual example will be helpful in verification of a fix.
Sure, here it is:
function genstr(len, chr) {
var result = "";
for (i=0; i<=len; i++) {
result = result + chr;
}
return result;
}
var start = process.hrtime();
var tough = require('tough-cookie');
var str = "x" + genstr(50000, ' ') + "x";
var Cookie = tough.Cookie;
var cookie = Cookie.parse(str);
var end = process.hrtime(start);
console.info("Execution time (hr): %ds %dms", end[0], end[1] / 1000000);
@cristianstaicu remember to start your timer right before your parse operation (i.e. after your require and string generation) for accurate time measurements. Given that node limits header size to 80kb the dos is limited to about 7.3 seconds. At Node Security we consider anything over 1 second to be a valid issue.
Just fyi, nsp has this on their radar so anyone with nsp in their CI build pipeline will now be experiencing failing builds.
Indeed. Got the nsp error from our pre-commit hook. But is there a way to overcome it temporarily until a fix for tough-cookie is in place? I'd like to avoid of course disabling entirely the nsp check.
You could add an exception to your .npmrc for that
@adamwdennis Please fix as our builds are failing and I don't want to whitelist the advisory
add the following to a .nsprc file:
{
"exceptions": ["https://nodesecurity.io/advisories/525"]
}
Hey Guys,
do you think it will take long for an update of the package. Because i want to use this in a project of mine and would like this to count on a fix in a decent amount of time. If that sounds kinda harsh it shouldn't. :D
While we haven't heard from the maintainers, suggesting limiting the number of whitespaces in the key.
#94
Snyk is picking this up now too, https://snyk.io/vuln/npm:tough-cookie:20170905
Known vulnerability for 16+ days... time to patch guys.
Once we have #94 issues resolved can someone from @salesforce/tough-cookie-contributors with npm permissions publish an update?
I apologize for the late pickup of this. I'm closely monitoring this issue and PR now.
@inikulin yes I can push an update as soon as we get a fix.
My team's CI security checks started failing today due to this issue and I'm happy to see that you are on top of it. Thanks for your work on this! It is much appreciated! 👍
Published fix as 2.3.3 - will leave this ticket open until I've resolved it with nsp/snyk
do you know how long it takes nsp to update on their side?
@mshibl unsure, but I've emailed both nodesecurity and snyk
We updated Snyk's DB, results should factor in the 2.3.3 fix now.
Hi, just noticed this and the fix,
I believe you can fix the issue without potentially breaking standards compliance with a change like:
/^(([^=;\s]+))\s*=\s*([^\n\r\0]*)/
The difference being the \s in [^=;\s]. This passes the above test at least
Snyk and nodesecurity are both updated. Closing issue.
One more apology (can't help it, 🇨🇦 ): sorry for the delay in fixing this folks. I've fixed my notification settings and email filters so this won't happen again.
I've been working on a change that removes the problematic regex parsing entirely. Hopefully more on this soon, but a preview is on the no-re-parser branch. As a side-effect, it appears to run the entire tough-cookie test suite about 1.5% faster for me!
Thank you to @cristianstaicu @grnd @inikulin and everyone else (especially for your patience)