Merge branch 'master' of gitlab.science:mlubbers/ssproject1617

diff --cc report/report.tex
index c832984,c832984..a131312
--- 1/report/report.tex
--- 2/report/report.tex
+++ b/report/report.tex
@@@ -9,16 -9,16 +9,16 @@@
  \section{Organization}
  \input{organization.tex}
  
--\section{Our security analysis of the CMS}
++\section{Our security analysis of the \CMS{}}
  
    \subsection{General comments}
  
    \begin{itemize}
      \item
--      The CMS comes equipped with an installer script, which is incredibly insecure, but which the author of the CMS assumes the admin will remove after installation. If we regard this installer script as part of our subject matter, the analysis becomes incredibly simple, as it directly makes the CMS vulnerable to server side code execution, SQL injections, etc. Therefore, we regard the installer script as a special case, and we assume that it is indeed removed after installation. The analysis, then, treats the CMS as it is after installation.
++      The \CMS{} comes equipped with an installer script, which is incredibly insecure, but which the author of the \CMS{} assumes the admin will remove after installation. If we regard this installer script as part of our subject matter, the analysis becomes incredibly simple, as it directly makes the \CMS{} vulnerable to server side code execution, \SQL{} injections, etc. Therefore, we regard the installer script as a special case, and we assume that it is indeed removed after installation. The analysis, then, treats the \CMS{} as it is after installation.
  
      \item
--      A number of times in our analysis, the OWASP ASVS requirements will require certain overridable server settings or request/response headers to be correcty set. The CMS is in principle able to set these parameters, for example by adding directives to an Apache \code{.htaccess} file, or explicitly setting certain HTTP response headers. However, the CMS does not do so, and therefore relies upon the server's default settings. In these cases, we consider the requirements failed, although one might contest this on the principle of separation of concerns.
++      A number of times in our analysis, the OWASP ASVS requirements will require certain overridable server settings or request/response headers to be correcty set. The \CMS{} is in principle able to set these parameters, for example by adding directives to an Apache \code{.htaccess} file, or explicitly setting certain \HTTP{} response headers. However, the \CMS{} does not do so, and therefore relies upon the server's default settings. In these cases, we consider the requirements failed, although one might contest this on the principle of separation of concerns.
    \end{itemize}
  
  
@@@ -33,7 -33,7 +33,7 @@@
    \subsection{Access Control}
    \input{v4_access.tex}
  
--  \subsection{Input Validation \& Output Encoding/Escaping}
++  \subsection{Input Validation \& Output Encoding/Escaping}\label{sec:v6} 
    \input{v5_input.tex}
  
    \addtocounter{subsection}{1}
@@@ -48,7 -48,7 +48,7 @@@
    \input{v9_data.tex}
  
    \addtocounter{subsection}{2}
--  \subsection{HTTP Security}
++  \subsection{\HTTP{} Security}
    \input{v11_httpsec.tex}
  
    \addtocounter{subsection}{4}