Bugzilla

(In reply to Julien Vehent [:ulfr] from comment #43)

> > utm_content will be rta%3A<base64_string> where <base64_string> is a collection of /[a-zA-Z0-9_\-]+/
> 
> :ddurst, two questions:
> * can we length limit this to something reasonable?

We *can*, though I'm not sure of the value there. Any GUID has a max length of 255, so the max encoded (I'm assuming this would be checked prior to decoding?) would be 340. As this should be escaped anyway, and the server rejects things that do not match or decode properly, this would/could be a check on w.m.o that wouldn't really impact anything further along the line. Meaning: if this is an abundance of caution, great; but it's not that meaningful in a mitigation sense, as far as I can tell. [Noting previous comments and email threads about the fact that an arbitrary URL used there is still not a threat.]

[Also reiterating that this is not protecting anything about attribution (since that's been around for a while) -- just the use of data stored via attribution.]

> * can it be decoded and validated against actual values, rather than treating it as a blob?

* Not really. Because the GUID follows https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/browser_specific_settings#Extension_ID_format, the actual values are less useful than formats -- and those seem pretty broad. Since these are used to get a response from the API, bogus ones (ones AMO doesn't know about) will return 400 anyway.

(In reply to Julien Vehent [:ulfr] from comment #43)

> > utm_content will be rta%3A<base64_string> where <base64_string> is a collection of /[a-zA-Z0-9_\-]+/
> 
> :ddurst, two questions:
> * can we length limit this to something reasonable?

We *can*, though I'm not sure of the value there. Any GUID has a max length of 255, so the max encoded (I'm assuming this would be checked prior to decoding?) would be 340. As this should be escaped anyway, and the server rejects things that do not match or decode properly, this would/could be a check on w.m.o that wouldn't really impact anything further along the line. Meaning: if this is an abundance of caution, great; but it's not that meaningful in a mitigation sense, as far as I can tell. [Noting previous comments and email threads about the fact that an arbitrary URL used there is still not a threat.]

[Also reiterating that this is not protecting anything about attribution (since that's been around for a while) -- just the use of data stored via attribution.]

> * can it be decoded and validated against actual values, rather than treating it as a blob?

Not really. Because the GUID follows https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/browser_specific_settings#Extension_ID_format, the actual values are less useful than formats -- and those seem pretty broad. Since these are used to get a response from the API, bogus ones (ones AMO doesn't know about) will return 400 anyway.