CSRF (and csurf) in 2024

[TCNOco]

csurf is still one if if not the most downloaded and widely used CSRF protection middleware on NPM source with over 330,000 weekly downloads...

Yet express.js/csurf has not been updated in the last 4 years+. The reason being a "large influx of security vulunerability reports received". From what I can tell Snyk comes up a lot
... However checking the pages referred to in discussions I see "Amendment This was deemed not a vulnerability." and 404s for the posts talking about "vulnerabilities in csrf", such as this one.

It's sad to see such a widely used package shut down because of such issues... and what it seems accusations that later were amended. I may be missing something massive, however.

With the rise of AI, such as Github Copilot I see a lot of suggestions for csurf.

Heck, I have the Snyk extension installed in VSCode, and the "⚠️ Medium Severity | Cross-Site Request Forgery (CSRF) | Priority Score 570 | Vulnerability: CWE-352". The extension gives me some examples of "solutions"... Here are some excerpts:

Every "solution" includes csurf. A 4-year depreciated package.

---

I'm overwhelmed with my own projects, job and more so I can understand how being beat down relentlessly destroys such an open-source package, and I can sympathise with the developers...

But: What package are people using now? What is going to replace csurf?

I am very out of the loop with all of this.

[jonchurch]

Currently, you can still use csurf even though it is in deprecated mode. If the package accomplishes the job you need it to, use it.

Im catching up here to see if there is any signal in the noise of snyk reports. But I think you miss an important part of the issue at hand OP, which is that the snyk reports' quality is considered very low and noisey.

What I mean is, looking st snyk reports in vscode and implementing their suggestions blindly is the opposite of what work (if any) needs to be done here. Edit: I see your screenshots are not from csurf itself, but from application code and snyk is recommending using csurf to fix issues in your app. You can still take those recommendations, but you should evaluate if the vuln they are suggesting your app has is actually valid for your use cases.

[wesleytodd]

FWIW there are real issues with this package today. It is not really impactful for all usage but the security issues are not bogus. If I had a recommendation for today it would be to remove the package from your projects and then for us to deprecate all existing versions. Then as we get things back into a functional place to maintain it we fix the issues and release a new major which would not be deprecated and we roll the folks lagging behind forward.

[TCNOco]

This is very true. I wouldn't blindly follow Snyk reports, but I mention it in particular (especially it suggesting to use csurf) because from what I understand the reports and info from Snyk were one of the reasons this project was left behind. I may be wrong but it's just what I gather from what limited info I've seen. I don't know if there was an official post about csurf's deprecation that detailed exactly why it is being left in its current state.

I'm happy to hear development may resume in the future. For now, do you recommend any packages in place of csurf, @wesleytodd ?

[wesleytodd]

I do not. Fastify has fixed all the same issues in theirs, but I don't believe that works with express.

[Faridalim]

I hope we have good replacement for csurf. I want to help but i dont have enough knowledge in security. I will attempt to create one though since need it for apps.

[birdofpreyru]

I suggest you switch to https://github.com/birdofpreyru/csurf (https://www.npmjs.com/package/@dr.pogodin/csurf) — my fork of the original ExpressJS csurf, that keeps the original API and logic, and takes care about keeping all dependencies up-to-date, and other necessary maintenance. Or, as I put it into its README:

This is a fork of the original csurf package which was deprecated by its author with doubtful reasoning (in the nutshell the package was alright, but author did not want to maintain it anymore). It is published to NPM as @dr.pogodin/csurf, its version 1.11.0 exactly matches the same, latest version of the original package, its versions starting from 1.12.0 have all dependencies updated to their latest versions, and misc maintenance performed as needed. To migrate from the original csurf just replace all references to it by @dr.pogodin/csurf.

[wesleytodd]

The package is insecure and all you are doing here is setting up a target for security researchers to open up CVEs against. I am going to leave this comment in place because we cannot control what you do with this fork, but to anyone landing here, do not use csurf or a fork as they have known vulnerabilities.

[birdofpreyru]

@wesleytodd Somebody still needs to explain me, why is it vulnerable? Explanations I saw in web go along the lines of possibility that an attacker may override the cookie set by csurf, if that attacker controls a sub-domain of protected domain, or he can inject his own code into protected page. Then csurf won't help, as it compares that cookie to the value sent with a request; but to me that reads like a security hole outside csurf, if a bad actor controls a sub-domain, or finds a way to do XSS. And if an attacker can't control a subdomain, or embed his code into the page, then it looks to me csurf protects just enough against CSRF, doesn't it?

Also the deprecation notice on the original csurf reads:

This npm module is currently deprecated due to the large influx of security vulunerability reports received, most of which are simply exploiting the underlying limitations of CSRF itself.

That does not sound to me as authors admitted that csurf is broken and vulnerable as many articles re. csurf claim.

[gh0st]

@birdofpreyru https://fortbridge.co.uk/research/a-csrf-vulnerability-in-the-popular-csurf-package/

@wesleytodd, what's the alternative?

[birdofpreyru]

@gh0st I saw that, it turns out some security «experts» do not understand well neither security, nor JavaScript 🤣 with just cookie: true option CSURF does a variant of Naive Double-Submit Cookie Pattern, which does its jobs under assumption that malicious parties cannot control sub-domains of the protected domain. That article complains that it does not do Signed Double-Submit Cookie stuff without a more specific configuration, and also the dude got confused about the purpose of «secret» value in that case, which is not supposed to be secret in that scenario, and some other stuff; and also the article ends with the claim that package developers acknowledged the bug and deprecated the package because of it, when in reality developers told that the package is fine, but they are too tired to explain it to amateurs 🤣

So... the original package does its job, or you can use my fork, which got misc necessary maintenance, or you may try to use one of many packages other folks decided to write from scratch, hoping they know what they are doing and have not messed it up.

[fetis]

@gh0st that article started a shit storm around the csurf package, but in reality, it has no PoC that package has problems. It exploits known vulnerabilities of CSRF protection, not the package itself.

Here's a detailed critique of the article expressjs/discussions#153 (comment)

[fetis]

Since the link from the csurf package leads to the discussions section and this is the first post that appears in the search, I'll make a short summary for the folks who stumbled across the "csurf is deprecated" problem (as me a couple of days ago).

Timeline

• Fortbridge published an article that alleged vulnerabilities in csurf. The article was later proved wrong and full of mistakes.
• This article was picked up by the Snyk company, and they issued a report that blacklisted all versions of csruf
• That action triggered an enormous influx of messages to ExpressJS maintainers. Being unable to fix non-existent "vulnerabilities" or get in contact with the Snyk technical staff, they made an emotional decision to shut down the package.
• Later, Snyk employees contacted maintainers and revoked the report as not exploitable, but it was too late. Damage spread, and the package was already gone.

Situation for now

We have 2 alternatives

• https://github.com/birdofpreyru/csurf, forked from the original package, and it's a drop-in replacement. Maintained and updated regularly.
• https://github.com/Psifi-Solutions/csrf-csrf new package that implements "Signed Double Submit Pattern" only according to the OWASP recommendations.

There are a couple more packages, but I don't list them here because of their lower popularity

[kyldex]

We have migrated to the csrf-csrf package, and it's been working well so far. You might need to add a secret and session identifiers depending on your previous csurf config.

[pauldwaite]

Over in Go land, version 1.25 introduced a new middleware, http.CrossOriginProtection, which guards against CSRF attacks in modern browsers by checking the Sec-Fetch-Site and Origin HTTP headers:

• Original proposal
• Blog post by Filippo Valsorda, the proposal author
• Blog post by Simon Willison
• Discussion on Lobste.rs

As per this blog post by Alex Edwards, if you also enforce HTTPS connections and TLS v1.3 or later, then you exclude most older browsers that don't send these headers (pre-2018–2019).

If your risk profile allows it, you might prefer allowing TLS v1.2, and relying on the lesser protections offered by SameSite cookie attributes in browsers that support them (roughly 2017 and later).

Is there any interest in copying the header inspection approach in an Express.js middleware?