Fossil SCM
Reworked the new introductory material in defcsp.md to be less about the CSP as last-resort and more about being a secondary filter to our other measures. Gave examples to clarify the tensions that prevent a purely server-side solution from being a practical solution.
Commit
1c4df5bf0a52724062aa50d0f698df86028cbfe046c1b01d72a782f497eaf723
Parent
5182be99c940830…
1 file changed
+36
-24
+36
-24
| --- www/defcsp.md | ||
| +++ www/defcsp.md | ||
| @@ -1,38 +1,50 @@ | ||
| 1 | 1 | # The Default Content Security Policy (CSP) |
| 2 | 2 | |
| 3 | -When Fossil’s web interface generates an HTML page, it | |
| 4 | -normally includes a [Content Security Policy][csp] (CSP) | |
| 5 | -in the `<head>`. | |
| 6 | -The CSP tells the browser what types of content (HTML, image, CSS, | |
| 7 | -JavaScript...) the document may reference and from where the | |
| 8 | -content may be sourced. | |
| 9 | - | |
| 10 | -CSP is a security measure designed to prevent [cross-site scripting][xss] | |
| 11 | -(XSS) and other similar code injection attacks. | |
| 12 | -The CSP defines a “white list” of content types and origins that | |
| 13 | -are considered safe. Any references to resources that are not | |
| 14 | -on the white list are ignored. | |
| 15 | - | |
| 16 | -If Fossil were perfect and bug-free and never allowed any kind of | |
| 17 | -code injection on the pages it generates, then the CSP would not | |
| 18 | -be useful. The Fossil developers are not aware of any defects | |
| 19 | -in Fossil that allow code injection, and will promptly fix any defects | |
| 20 | -that are brought to their attention. Lots of eyeballs are looking at | |
| 21 | -Fossil to find problems in the code, and the Fossil build process uses | |
| 22 | -custom static analysis techniques to help identify code injection problems | |
| 23 | -at compile-time. Nevertheless, problems do sometimes (rarely) slip | |
| 24 | -through. The CSP serves as a final line of defense, preventing | |
| 25 | -code injection defects in Fossil from turning into actual | |
| 26 | -vulnerabilities. | |
| 3 | +When Fossil’s web interface generates an HTML page, it normally includes | |
| 4 | +a [Content Security Policy][csp] (CSP) in the `<head>`. The CSP defines | |
| 5 | +a “white list” to tell the browser what types of content (HTML, images, | |
| 6 | +CSS, JavaScript...) the document may reference and the sources the | |
| 7 | +browser is allowed to pull such content from. The aim is to prevent | |
| 8 | +certain classes of [cross-site scripting][xss] (XSS) and code injection | |
| 9 | +attacks. The browser will not pull content types disallowed by the CSP. | |
| 10 | + | |
| 11 | +Fossil has built-in server-side content filtering logic. For example, it | |
| 12 | +purposely breaks `<script>` tags when it finds them in Markdown and | |
| 13 | +Fossil Wiki documents. (But not in [HTML-formatted embedded | |
| 14 | +docs][hfed]!) We also back that with multiple levels of analysis and | |
| 15 | +checks to find and fix content security problems: compile-time static | |
| 16 | +analysis, run-time dynamic analysis, and manual code inspection. Fossil | |
| 17 | +is open source software, so it benefits from the “[many | |
| 18 | +eyeballs][llaw],” limited by the size of its developer community. | |
| 19 | + | |
| 20 | +However, there is a practical limit to the power of server-side | |
| 21 | +filtering and code quality practices. | |
| 22 | + | |
| 23 | +First, there is an endless battle between those looking for clever paths | |
| 24 | +around such barriers and those erecting the barriers. The developers of | |
| 25 | +Fossil are committed to holding up our end of that fight, but this is, | |
| 26 | +to some extent, a reactive posture. It is cold comfort if Fossil’s | |
| 27 | +developers react quickly to a report of code injection — as we do! — if | |
| 28 | +the bad guys learn of it and start exploiting it first. | |
| 29 | + | |
| 30 | +Second, Fossil has purposefully powerful features that are inherently | |
| 31 | +difficult to police from the server side: HTML [in wiki](/wiki_rules) | |
| 32 | +and [in Markdown](/md_rules) docs, [TH1 docs](./th1.md), etc. | |
| 33 | + | |
| 34 | +Fossil’s strong default CSP adds client-side filtering to backstop our | |
| 35 | +server-side measures. | |
| 27 | 36 | |
| 28 | 37 | Fossil site administrators can [modify the default CSP](#override), perhaps |
| 29 | 38 | to add trusted external sources for auxiliary content. But for maximum |
| 30 | 39 | safety, site developers are encouraged to work within the restrictions |
| 31 | 40 | imposed by the default CSP and avoid the temptation to relax the CSP |
| 32 | 41 | unless they fully understand the security implications of what they are |
| 33 | 42 | doing. |
| 43 | + | |
| 44 | +[llaw]: https://en.wikipedia.org/wiki/Linus%27s_Law | |
| 45 | + | |
| 34 | 46 | |
| 35 | 47 | ## The Default Restrictions |
| 36 | 48 | |
| 37 | 49 | The Fossil default CSP declares the following content restrictions: |
| 38 | 50 | |
| 39 | 51 |
| --- www/defcsp.md | |
| +++ www/defcsp.md | |
| @@ -1,38 +1,50 @@ | |
| 1 | # The Default Content Security Policy (CSP) |
| 2 | |
| 3 | When Fossil’s web interface generates an HTML page, it |
| 4 | normally includes a [Content Security Policy][csp] (CSP) |
| 5 | in the `<head>`. |
| 6 | The CSP tells the browser what types of content (HTML, image, CSS, |
| 7 | JavaScript...) the document may reference and from where the |
| 8 | content may be sourced. |
| 9 | |
| 10 | CSP is a security measure designed to prevent [cross-site scripting][xss] |
| 11 | (XSS) and other similar code injection attacks. |
| 12 | The CSP defines a “white list” of content types and origins that |
| 13 | are considered safe. Any references to resources that are not |
| 14 | on the white list are ignored. |
| 15 | |
| 16 | If Fossil were perfect and bug-free and never allowed any kind of |
| 17 | code injection on the pages it generates, then the CSP would not |
| 18 | be useful. The Fossil developers are not aware of any defects |
| 19 | in Fossil that allow code injection, and will promptly fix any defects |
| 20 | that are brought to their attention. Lots of eyeballs are looking at |
| 21 | Fossil to find problems in the code, and the Fossil build process uses |
| 22 | custom static analysis techniques to help identify code injection problems |
| 23 | at compile-time. Nevertheless, problems do sometimes (rarely) slip |
| 24 | through. The CSP serves as a final line of defense, preventing |
| 25 | code injection defects in Fossil from turning into actual |
| 26 | vulnerabilities. |
| 27 | |
| 28 | Fossil site administrators can [modify the default CSP](#override), perhaps |
| 29 | to add trusted external sources for auxiliary content. But for maximum |
| 30 | safety, site developers are encouraged to work within the restrictions |
| 31 | imposed by the default CSP and avoid the temptation to relax the CSP |
| 32 | unless they fully understand the security implications of what they are |
| 33 | doing. |
| 34 | |
| 35 | ## The Default Restrictions |
| 36 | |
| 37 | The Fossil default CSP declares the following content restrictions: |
| 38 | |
| 39 |
| --- www/defcsp.md | |
| +++ www/defcsp.md | |
| @@ -1,38 +1,50 @@ | |
| 1 | # The Default Content Security Policy (CSP) |
| 2 | |
| 3 | When Fossil’s web interface generates an HTML page, it normally includes |
| 4 | a [Content Security Policy][csp] (CSP) in the `<head>`. The CSP defines |
| 5 | a “white list” to tell the browser what types of content (HTML, images, |
| 6 | CSS, JavaScript...) the document may reference and the sources the |
| 7 | browser is allowed to pull such content from. The aim is to prevent |
| 8 | certain classes of [cross-site scripting][xss] (XSS) and code injection |
| 9 | attacks. The browser will not pull content types disallowed by the CSP. |
| 10 | |
| 11 | Fossil has built-in server-side content filtering logic. For example, it |
| 12 | purposely breaks `<script>` tags when it finds them in Markdown and |
| 13 | Fossil Wiki documents. (But not in [HTML-formatted embedded |
| 14 | docs][hfed]!) We also back that with multiple levels of analysis and |
| 15 | checks to find and fix content security problems: compile-time static |
| 16 | analysis, run-time dynamic analysis, and manual code inspection. Fossil |
| 17 | is open source software, so it benefits from the “[many |
| 18 | eyeballs][llaw],” limited by the size of its developer community. |
| 19 | |
| 20 | However, there is a practical limit to the power of server-side |
| 21 | filtering and code quality practices. |
| 22 | |
| 23 | First, there is an endless battle between those looking for clever paths |
| 24 | around such barriers and those erecting the barriers. The developers of |
| 25 | Fossil are committed to holding up our end of that fight, but this is, |
| 26 | to some extent, a reactive posture. It is cold comfort if Fossil’s |
| 27 | developers react quickly to a report of code injection — as we do! — if |
| 28 | the bad guys learn of it and start exploiting it first. |
| 29 | |
| 30 | Second, Fossil has purposefully powerful features that are inherently |
| 31 | difficult to police from the server side: HTML [in wiki](/wiki_rules) |
| 32 | and [in Markdown](/md_rules) docs, [TH1 docs](./th1.md), etc. |
| 33 | |
| 34 | Fossil’s strong default CSP adds client-side filtering to backstop our |
| 35 | server-side measures. |
| 36 | |
| 37 | Fossil site administrators can [modify the default CSP](#override), perhaps |
| 38 | to add trusted external sources for auxiliary content. But for maximum |
| 39 | safety, site developers are encouraged to work within the restrictions |
| 40 | imposed by the default CSP and avoid the temptation to relax the CSP |
| 41 | unless they fully understand the security implications of what they are |
| 42 | doing. |
| 43 | |
| 44 | [llaw]: https://en.wikipedia.org/wiki/Linus%27s_Law |
| 45 | |
| 46 | |
| 47 | ## The Default Restrictions |
| 48 | |
| 49 | The Fossil default CSP declares the following content restrictions: |
| 50 | |
| 51 |