From 46a48fdbb385f2ecf75ca7acfc430d3b331adc39 Mon Sep 17 00:00:00 2001 From: leo Date: Thu, 25 May 2023 03:11:32 +0200 Subject: [PATCH] tex: add CSP, delete sections --- tex/references.bib | 9 ++++++++ tex/text.tex | 56 +++++++++++++++++----------------------------- 2 files changed, 29 insertions(+), 36 deletions(-) diff --git a/tex/references.bib b/tex/references.bib index 41f7a7f..38f81b3 100644 --- a/tex/references.bib +++ b/tex/references.bib @@ -343,4 +343,13 @@ institution = {International Organization for Standardization} isbn = {978-1593278267}, } +@inproceedings{longliveCSP, + title = {{CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy}}, + author = {Lukas Weichselbaum and Michele Spagnuolo and Artur Janc and Sebastian Lekies}, + booktitle = {Proceedings of the 5th ACM SIGSAC Conference on Computer and Communications Security (CCS '16)}, + address = {New York, NY, USA}, + doi = {10.1145/297674}, + year = 2016, +} + % =========================================================================== % diff --git a/tex/text.tex b/tex/text.tex index 109f06f..0932f45 100644 --- a/tex/text.tex +++ b/tex/text.tex @@ -469,49 +469,33 @@ A header is additional information sent by both the server and the client. \n{2}{Content Security Policy}\label{sec:csp} -Content Security Policy has been an important addition to the arsenal of +Content Security Policy (CSP) has been an important addition to the arsenal of website operators, even though not everybody has necessarily been utilising it properly or even taken notice. To understand what guarantees it provides and what kind of protections it employs, it is first necessary to grok how websites are parsed and displayed, which has been discussed in depth in previous sections. +As per Weichselbaum et al.\ CSP is a mechanism designed to mitigate +XSS~\cite{longliveCSP}. It is a declarative policy mechanism that allows the +website operator to decide what client-side resources can load and what origins +are permitted. Scripts can be restricted to only load from a list of trusted +domains and inline scripts can be blocked completely. The scripts can also be +allowed based on a cryptographic hash based on their content, which should be a +known information to website operators prior to or at the time scripts are +served. -\n{1}{Sandboxing}\label{sec:sandboxing} -\n{2}{User isolation} -Admin vs regular user, privilege escalation, least-privilege principle, -zero-trust principle. -\n{2}{Process isolation} -Sandbox escape. -\n{2}{Namespaced isolation} -Sandbox escape. - - -\n{1}{Data storage} -Among the key aspects of any security-minded system (application), the -following are certain to make the count: -\begin{enumerate} - \item data integrity - \item data authenticity - \item data confidentiality -\end{enumerate} - -\n{2}{Integrity} - -\n{2}{Authenticity} - -\n{2}{Confidentiality} - -\n{2}{Encryption-at-rest} - - -\n{1}{Compromise checking and prevention} - -\n{2}{HIBP and similar tools} - -\n{2}{OWASP Top 10 for the implementers} - -\n{2}{Password best practices} +CSP3, which is the current version, can be served either as a header or inside +website's \texttt{} tag. Directives are generally named after a topic +keyword and suffixed `-src', such as \texttt{script-src}, \texttt{img-src} or +\texttt{style-src}, although some directives don't follow this pattern, +\texttt{form-action}, \texttt{upgrade-insecure-requests} and \texttt{sandbox} +representing this group nicely. Sections are delimited using semicolons and +each section can only appear once. Special values exist for the origin itself +(\texttt{'self'}) and disallowing any source (\texttt{'none'}). A good CSP is +targeted and not overly broad. For instance, a website that loads no JavaScript +at all does not need to allow a popular CDN (Content Delivery Network) origin +in its \texttt{script-src}, instead it can be set to \texttt{'none'}. % =========================================================================== %