Javascript Version Disclosure

If there is interest in this actually being merged, let me know and I will rework the failing asset tests to account for this change.

I don't see version numbers on assets with or without aggregation enabled.

Yes, they are there on the JavaScript files if aggregation is off. Why is aggregation off on the site?

@cliefen Good question. Two different answers:

1. Even with javascript aggregation enabled, when you hit update.php or install.php, it seems they do not use aggregation and the individual script tags are present, which is where the versions are visible.
2. We have aggregation enabled on our stage an prod environments, so on all pages other than update.php or install.php it is not a full problem there. However we do have aggregation off on our dev environment so that is easier to debug js issues. And on our gov't projects all three environments are scanned due to Zero Trust mindset.

It is nice that aggregations solves it for most requests, and the Drupal recommended approach is to use aggregation, I don't think it should be a security requirement. There is nothing on the performance UI that says "use JS aggregation or your site will be more at risk."

I updated the steps to reproduce to be more specific about when and where they are exposed.

Heads up - a move in the opposite direction is being asked for in 📌 Use library version as query strings for external css (like js does) Active .

LOL. Interesting. I don't think that would security risk though as CSS rarely has exploitable issues. At least not that I am aware of. :shrug:

I think the scanner here is unreasonable, especially when talking about a dev site in a development mode, but also it would be easy and still correct to use a hash here. Should probably be the very shortest xxhash available.

@swirt if you had a situation with Bootstrap, for example, seeing its CSS version would reveal its JS version. That’s all on the assumption that this is a security improvement which I’m doubtful about. In fact, don’t these libraries declare their versions within their code, defeating this proposed protection?

@cliefen, These are all good questions, and I do not pretend to be a security expert but my current thinking on it is this:

That’s all on the assumption that this is a security improvement which I’m doubtful about.

Version disclosure is labeled as a low risk but is serious enough that Drupal does not reveal its minor version, Only the major.

<meta name="generator" content="Drupal 7 (https://www.drupal.org)" />

<meta name="Generator" content="Drupal 10 (https://www.drupal.org)" />

If it is serious enough that Drupal does not reveal itself, then Drupal should probably show the same level of care to libraries and not reveal their specific version.

In fact, don’t these libraries declare their versions within their code, defeating this proposed protection?

Many do. Example: jQuery.fn.jQuery will reveal its own version. If the library wants to reveal its own version, that is the library's choice. However, I think that should remain the choice of the library's maintainers. Drupal should not be the library's loose lipped friend that blabs the secret. I think this falls into the same reason why we routinely make the composer.lock and composer.json of our sites return an access denied.

@catch I took your suggestion on this MR and made it use a shorter hash https://git.drupalcode.org/project/drupal/-/merge_requests/11787

DAST tools and bad actors could additionally hash file contents and compare that against widely published lists to know an asset version. So, no, it actually wouldn't matter whether or not a given library includes its version in code. Anyone can still determine the version. I just want to be clear about how much this change actually would accomplish.

But, just to be clear, if a fast hash algo gets the job done, I don't see any reason not to do this.

Yes, makes sense. This alone does very little. But does a little. I will work on fixing the failing tests to get this completed.