From f46f4386c3c46d787abd5de4dce7235e57952c6c Mon Sep 17 00:00:00 2001
From: Daan Sprenkels <dsprenkels@gmail.com>
Date: Wed, 9 Nov 2016 12:53:13 +0100
Subject: [PATCH] Add v11 HTTP security up to 11.5 (3 left to do)

---
 report/report.tex      |  3 +-
 report/v11_httpsec.tex | 80 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 82 insertions(+), 1 deletion(-)
 create mode 100644 report/v11_httpsec.tex

diff --git a/report/report.tex b/report/report.tex
index 55ef024..7f0de16 100644
--- a/report/report.tex
+++ b/report/report.tex
@@ -31,8 +31,9 @@
 
 \subsection{Data Protection}
 
-\addtocounter{subsection}{1}
+\addtocounter{subsection}{2}
 \subsection{HTTP Security}
+\input{v11_httpsec.tex}
 
 \addtocounter{subsection}{4}
 \subsection{Files and Recourses}
diff --git a/report/v11_httpsec.tex b/report/v11_httpsec.tex
new file mode 100644
index 0000000..bf075c6
--- /dev/null
+++ b/report/v11_httpsec.tex
@@ -0,0 +1,80 @@
+
+\begin{enumerate}[label={11.\arabic*}]
+
+\item\fail{}
+Verify that the application accepts only a defined
+set of required HTTP request methods, such as
+GET and POST are accepted, and unused methods
+(e.g. TRACE, PUT, and DELETE) are explicitly
+blocked.
+\begin{result}
+    The application treats only \texttt{POST} requests as different from
+    others and in an opportunistic manner. It assumes all other methods to be
+    treated as \texttt{GET} requests.
+\end{result}
+
+\item\pass{}
+Verify that every HTTP response contains a
+content type header specifying a safe character set
+(e.g., UTF-8, ISO 8859-1).
+\begin{result}
+    Content type headers may be set anywhere in the application. Furthermure,
+    \texttt{Response::send} ensures that if no content type header is set, all
+    responses will fall back to using \texttt{text/html; charset=UTF-8}.
+\end{result}
+
+\notapplicable{\item
+Verify that HTTP headers added by a trusted proxy
+or SSO devices, such as a bearer token, are
+authenticated by the application.}
+
+% No proxies are present
+
+\item\fail{}
+Verify that a suitable X-FRAME-OPTIONS header is
+in use for sites where content should not be
+viewed in a 3rd-party X-Frame.
+\begin{result}
+    The application will never supply an \texttt{X-FRAME-OPTIONS} header. While
+    this is not really a problem for the home page, a 3rd party X-Frame should
+    not be able to refer to the administrative interfaces of the application.
+\end{result}
+
+\item\pass{}
+Verify that the HTTP headers or any part of the
+HTTP response do not expose detailed version
+information of system components.
+\begin{result}
+    The headers provide information about the PHP version (these are added by
+    the PHP interpreter by default) and information about the webserver. This
+    information is not specific for the application. It would be advisable to
+    hide the PHP version to the client, but this is specific to the way the
+    application is installed.
+\end{result}
+
+\item\pass{}
+\TODO \\
+Verify that all API responses contain X-Content-Type-Options:
+nosniff and Content-Disposition:
+attachment; filename="api.json" (or other
+appropriate filename for the content type).
+\begin{result}
+\end{result}
+
+\item\pass{}
+\TODO \\
+Verify that a content security policy (CSPv2) is in
+place that helps mitigate common DOM, XSS,
+JSON, and JavaScript injection vulnerabilities.
+\begin{result}
+\end{result}
+
+\item\pass{}
+\TODO \\
+Verify that the X-XSS-Protection: 1; mode=block
+header is in place to enable browser reflected XSS
+filters.
+\begin{result}
+\end{result}
+
+\end{enumerate}
-- 
2.20.1