Javascript on the Download page
(1) By anonymous on 2023-06-29 13:20:22 [source]
I'm a little confused (naivety almost certainly).
I am aware of the default CSP used by fossil. I am aware of the use of nonces to allow core javascript to work.
I am aware that the download page is stored as a UV file. I am aware that it used javascript (also stored as a UV file) to parse a json representation of all the unversioned files to generate the build artifacts list to then populate the download page.
I am aware that TH1 processing can add the nonce to core html <script> tags. I am aware that the CSP can be altered to make this unnecessary.
But, I cannot figure out how the javascript referenced by the download.html <script> tags works, as there doesn't seem to be a nonce included, and nor does the CSP seem to be different for that page.
Can anyone enlighten me please?
Bob
(2) By anonymous on 2023-06-29 13:57:32 in reply to 1 [link] [source]
Default CSP:
script-src 'self' 'nonce-%s' This policy disables in-line JavaScript and only allows <script> elements if the <script> includes a nonce attribute that matches the one declared by the CSP. That nonce is a large random number, unique for each HTTP page generated by Fossil, so an attacker cannot guess the value, so the browser will ignore an attacker’s injected JavaScript.
I'm actually starting to wonder if this does what I think it does. I assumed that <script> javascript here </script> code would not run without the nonces. However, I think the 'self' default declaration actually allows such referenced code (though not inline code in the html elements).
In which case, I'm not sure why anyone with checkin or UV checking rights cannot feed malicious javascript into Fossil's website - this is what I thought the CSP was designed to avoid?
Bob
(3) By Stephan Beal (stephan) on 2023-06-29 14:44:34 in reply to 2 [link] [source]
In which case, I'm not sure why anyone with checkin or UV checking rights cannot feed malicious javascript into Fossil's website - this is what I thought the CSP was designed to avoid?
Regarding UV: only one person, the project lead, has uv-push permissions in this project, and the download page is specific to this project (not distributed as a fossil feature).
Regarding check-ins: every check-in to this project is monitored by multiple people, so any outright malicious commits would quickly be uncovered. In the project's nearly 16 years, such tomfoolery has fortunately never been an issue.
(4) By anonymous on 2023-06-29 14:59:27 in reply to 3 [link] [source]
Thank you - less aimed at the main fossil fossil repository and more what might be possible in my own fossil repository.
It appears that I must be careful as anyone with checkin privileges could embed a js file in the repo which could then be used as payload in a checked in html file or a uv file (unless I alter the CSP).
Thanks, that answers my question.
Bob.