cache pollution risk

Issue #19 open
created an issue

If I'm a malicious user who wants to bother someone that serves using Fanstatic and I know he uses some form of front-end cache, I can pollute that cache by generating a lot of bogus hash urls:

/fanstatic/#️⃣bogus1/blah.js /fanstatic/#️⃣bogus2/blah.js

and so on

This will force a front-end cache to try to cache all those resources, even though they are in fact the same ones.

It should be possible to let the library check whether the hash used in the URL is in fact a legitimate one, and return a 404 if not.

This behavior might be a problem if someone is requesting a changed resource using the old hash. This would result in a 404 too. But since they were requesting the old resource that doesn't exist anymore, that's actually reasonable behavior. If a caching front end is in use, the caching frontend should be able to serve the old hash instead.

This hash checking is expensive and not useful during devmode, so this should be disabled in that case.

Comments (2)

  1. faassen reporter
    • changed status to open

    If we want to prevent sending a 404 when an old hash is used, but still want to prevent people from using bogus hashes to pollute the cache, we could come up with a solution that stored the old hashes and only serves files if addressed with the current or an old hash. This however would require Fanstatic to retain state, which is a new activity for Fanstatic. (we were already talking about minified and rolled up resources though, which would also require state maintenance).

    We could also consider the 404 behavior an option, which could be used by those people who know they don't need old hashes and are using a front-end cache, but can be ignored by people who don't use a front-end cache and do need old hashes.

  2. Log in to comment