0

I just received a blackbox pentesting report where the security company recommended to hide the version number from the page (be it returned to the user as a text or used as a cache-buster in the css/js/img urls, like /path/to/file.css?v1.2.3.

I gave it some thought and could not think of a good solution that would comply with their recommendation and keep those resources fresh and cached on the client's devices.

These days browsers and proxies do crazy things about caching resources (sometimes when they even should not have). So urls must be unique between releases.

But if they are - then really does not matter whether it's a version number in the url, or a file contents hash, or a random value. If it's stable it still allows to uniquely identify a version.

I can invent some dirty way (which I'm not sharing at the moment, but later when I see any feedbacks), but what industry is doing these days to comply with the similar recommendations?

UPD: as promised, here is a workaround that would "keep" caching and hide the version number:

instead of version component in the url use the hash derived as: hash(version_str + year_str + week_number_str + secret_str). That way the value would naturally change every week and leak nothing.

2
  • 1
    Related, possible duplicate?: Is it really Security Misconfiguration to show a version number?. Consensus there seemed to be that exposing the version is not / no longer a significant risk (they can probably determine it by other means).
    – TripeHound
    Commented Aug 30, 2019 at 6:58
  • @TripeHound "they can probably determine it by other means" --- that's what I exactly grasped when first read the report.
    – zerkms
    Commented Aug 30, 2019 at 7:01

1 Answer 1

2

While exposing specific version numbers is considered a bad practice and is not recommended, in this case I do not really see an issue.

It is likely that the version is also displayed as a comment in the CSS file (and often also in JS files). It's quite easy to identify the version for such files (not 100% reliable but 99 out of a 100 times it will work)

As a security consultant, I would be more interested in your update policy:

  • How often do you check for updates on externally[1] used dependencies (CSS / JS)
  • How often do you apply these updates?
  • What's the process you execute before using these updates in production systems.

[1] I am not stating that you load these resources externally, just stating that it's a CSS file that is not created by you or your company.

As a side note: If this is considered the worst problem you have with your application, you've done quite well.

2
  • Yep, it's a very little list of recommendations, of which this was the highest severity one which I also had no idea how to address "correctly". Btw, I updated a question with a "solution" that would satisfy a client should they insist on it to be "fixed".
    – zerkms
    Commented Aug 30, 2019 at 6:48
  • 1
    As far as your solution, the thing is that one could still view the file's content. If there are comments they can search for this CSS file. Based on a hash they could still identify its version (assuming the content of the CSS file is not modified of course).
    – Jeroen
    Commented Aug 30, 2019 at 7:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .