1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
+
-
-
-
+
+
+
-
-
-
-
-
+
+
+
+
-
-
-
+
+
+
-
-
-
-
-
+
+
+
+
+
+
+
-
-
-
+
+
+
+
+
+
+
+
-
+
+
-
+
-
+
-
+
+
+
-
-
-
+
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
-
+
-
-
+
-
-
-
+
+
+
-
-
-
-
+
-
-
-
+
-
-
-
+
-
-
-
-
+
-
-
-
-
-
-
+
+
+
+
+
+
-
+
-
+
-
-
-
+
-
-
+
-
-
-
-
+
|
# The Default Content Security Policy (CSP)
When Fossil’s web interface generates an HTML page, it
normally includes a [Content Security Policy][csp] (CSP)
in the `<head>`.
which applies to all content on that page. The CSP tells the browser
which types of content (HTML, image, CSS, JavaScript...) the repository
is expected to serve, and thus which types of content a compliant
browser is allowed to pay attention to. All of the major browsers
enforce CSP restrictions.
A CSP is an important security measure on any site where some of the
content it serves is user-provided. It defines a “white list” of content
types believed to be safe and desirable, so that if any content outside
of that definition gets inserted into the repository later, the browser
will treat that unwanted content as if it was not part of the document
at all.
A CSP is a fairly blunt tool. It cannot tell good and visually appealing
enhancements from vandalism or outright attacks. All it does is tell the
browser what types and sources for page content were anticipated by the
site’s creators. The browser treats everything else as “unwanted” even
if that’s not actually true. When the CSP prevents the browser from
displaying wanted content, you then have to understand the current rules
and what they’re trying to accomplish to decide on [an appropriate
workaround](#override).
### <a name="base"></a> default-src 'self' data
### <a name="base"></a> default-src 'self' data:
This policy means mixed-origin content isn’t allowed, so you can’t refer to
resources (images, style-sheets, and scripts) on other web domains.
resources on other web domains, so the following Markdown for an inline
This policy allows inline `data:` URIs, which means you could
The default policy does allows inline `data:` URIs, which means you could
[data-encode][de] your image content and put it inline within the
document:
That method is best used for fairly small resources. Large `data:` URIs
are hard to read and edit. Keep in mind that if you put such a thing
into a Fossil forum post, anyone subscribed to email alerts will get a
copy of the raw URI text, which is really ugly.
For larger files, you could instead store the file in Fossil as:
For larger images in [embedded documentation](./embeddeddoc.wiki) you
store the image as a separate file in the Fossil repository and reference
it via a relative URI.
* **versioned content** retrieved via a [`/raw`](/help?cmd=/raw) URL
* **[unversioned content](./unvers.wiki)** retrieved
via a [`/uv`](/help?cmd=/uv) URL
Another path around this restriction is to [serve your
repo](./server/) behind an HTTP proxy server, allowing mixed-mode
content serving, with static images and such served directly by the HTTP
server and the dynamic content by Fossil. That allows a URI scheme that
prevents the browser’s CSP enforcement from distinguishing content from
Fossil proper and that from the front-end proxy.
Any content from the same domain as the Fossil repository will work fine.
So if the Fossil repository is but one path in a larger website, it will
be able reference other static resources within that same website. It
can also reference [unversioned content](./unvers.wiki). However, as
unversioned content and content outside of the Fossil repository itself
will not be transferred by [sync](/help?cmd=sync), the references probably
will not work in clones of your repository.
### <a name="style"></a> style-src 'self' 'unsafe-inline'
This policy allows CSS information to come from separate files in the
This policy means CSS files can only come from the Fossil server or via
a front-end proxy as in the inline image workarounds above. It also says
that inline CSS is disallowed; this will give a CSP error:
<p style="margin-left: 4em">Some bit of indented text</p>
In practice, this means you must put your CSS into [the “CSS” section of
The `'unsafe-inline'` element means that an injection vulnerability in
Fossil would allow an attacker to modify the CSS for a Fossil-generated
page. This is not ideal, but nor is it as dangerous as allowing
a custom skin][cs], not inline within Markdown, Wiki, or
HTML tags. You can refer to specific tags in the document through “`id`”
and “`class`” attributes.
The reason for this restriction might not be obvious, but the risks boil
down to this: CSS is sufficiently powerful that if someone can apply
their CSS to your site, they can make it say things you don’t want it to
say, hide important information, and more. Thus, we restrict all CSS to
come from trusted channels only.
We do currently trust CSS checked into the repository as a file, but
that stance might be overly-trusting, so we might revoke it later, as we
do for JavaScript:
This policy means HTML `<script>` tags are only allowed to be emitted
into the output HTML by Fossil C or TH1 code, because only code running
in those contexts can insert the correct “nonce” tag attribute, matching
the one declared in the CSP.¹ Since the nonce is a very large random
number that changes on each HTTP hit Fossil handles, it is effectively
unguessable, which prevents attackers from inserting `<script>` tags
This policy disables in-line javascript and only allows `<script>`
elements if the `<script>` includes a `nonce=` attribute the
matches the %s section of the CSP. Fossil provides a different
random nonce for every page it generates, and since an attacker has
no way of predicting what that nonce will be, the attacker is unable
to inject working javascript.
statically.
This means the workarounds given above will not work for JavaScript.
Under this policy, the only JavaScript that Fossil can serve is that
which it directly provided.
Users with the all-powerful Setup capability can insert arbitrary
JavaScript by [defining a custom skin][cs], adding it to the skin’s
“JavaScript” section, which has the random nonce automatically inserted
by Fossil when it serves the page. This is how the JS backing the
default skin’s [hamburger menu](./customskin.md#menu) works.
|