CSRF flaw in csurf NPM package aimed at protecting against the same flaws

Charlie Osborne 02 September 2022 at 15:11 UTC
Updated: 02 September 2022 at 15:18 UTC

Serious security prompt developers to discontinue open source package

Pen testers hunting for low-severity bugs found a far more severe cross-site request forgery (CSRF) flaw in the open source csurf software.

Researchers from UK-based cybersecurity firm Fortbridge were called in when a customer asked them to review a penetration testing report. An issue flagged was a CSRF cookie missing a secure flag.

Curious about the finding, the team began digging. According to an August 28 blog post put together by Fortbridge cloud application security consultant Adrian Tiron, the issue was ultimately traced back to a node.js application relying on csurf.

Catch up on the latest infosecurity research news and analysis

Csurf is a project designed to allow developers to create middleware for CSRF token creation and validation via sessions or cookies. The NPM package is still downloaded approximately 400,000 times per week even though its last formal update was three years ago.

Tiron writes that while the popular package was intended to defend against CSRF, a CSRF bug has lain dormant within the code since the last version release, impacting any application using the open source package.

After exploring the csurf code, the pen testers found several problems. These included secrets stored in clear text within _csrf cookies; the use of the broken SHA-1 cryptographic algorithm; a lack of signature checks for cookies by default, and the validation of header tokens against the secret or GET/POST parameters with different names.

Furthermore, Tiron explained that there was some “weird behavior” in the code. For example, the app would accept empty XSRF tokens and it was possible to create a token from a salt and the secret, allowing attackers to calculate their own CSRF tokens.

Cookie toss

By adding a second cookie with the same name and forcing an app to use a malicious alternative by setting specific Path attributes, in what is known as a cookie toss, the team could pass the CSRF token header as GET, exploiting the software in the process.

“OSS just like commercial software can have vulnerabilities,” Tiron told The Daily Swig. “Companies relying on OSS should realize that people behind it are often volunteers and quite often there’s no budget for security tooling or pen testing.”

Fortbridge submitted its findings to the package developer on June 2. The issue was acknowledged a day later, and after further investigation, the maintainer has reportedly decided to mark the package as deprecated.

“Popular open source libraries are a good target for attackers because they impact a large number of applications that are incorporating it,” Tiron told us. “Even if it’s open source and many eyes are supposedly looking at it, the truth is that sometimes the security skills are lacking or there’s no incentive to look for bugs because there’s no bug bounty involved.”

Tiron concluded: “What we see is that companies are very reactive in this area (they rely just on patching) and we recommend that they should be more proactive and do their own security check.”

YOU MAY ALSO LIKE Graph-based JavaScript bug scanner discovers more than 100 zero-day vulnerabilities in Node.js libraries