DOC:=report
-LATEX:=pdflatex
-BIBTEX:=bibtex
-LATEXFLAGS:=-file-line-error -halt-on-error -no-shell-escape
+LATEX?=pdflatex
+BIBTEX?=bibtex
+LATEXFLAGS?=-file-line-error -halt-on-error -no-shell-escape
TEXS:=$(wildcard *.tex)
%.fmt: preamble.tex logo.pdf
$(LATEX) $(LATEXFLAGS) -ini -jobname="$(basename $@)" "&$(LATEX) $<\dump"
-%.pdf: %.tex %.fmt $(TEXS)
+%.mlog: %.tex %.fmt $(TEXS)
$(LATEX) $(LATEXFLAGS) $<
grep -q '^\\bibdata{' $(basename $<).aux && $(BIBTEX) $(basename $<) || true
- $(LATEX) $(LATEXFLAGS) $< | tee $(basename $<).mlog
- grep -qF 'Please rerun LaTeX.' $(basename $<).mlog &&\
- $(LATEX) $(LATEXFLAGS) $< || true
+ $(LATEX) $(LATEXFLAGS) $< | tee $@
+
+%.pdf: %.mlog
+ grep -qF 'Please rerun LaTeX.' $< &&\
+ $(LATEX) $(LATEXFLAGS) $(basename $<) || touch $@
clean:
$(RM) $(addprefix $(DOC).,aux log fmt toc bbl blg mlog run.xml out)\
\item In the \textbf{privacy violation} category, Fortify found errors and warnings printed back to the browser, and labelled it \textbf{critical}. However, this happens in the installer script, which we have decided to treat separately, as explained earlier.
\item \textbf{\SQL{} injection} attacks are possible on the installer script, labelled \textbf{critical}. Yet again: the installer script.
\item \textbf{Cookie security}: the \code{HttpOnly} header is not set, labelled \textbf{high}.
- \item \textbf{Privacy violation}: \HTML{} forms don't disable autocompletion. Labelled \textbf{high}. However, autocompletion of \HTML{} forms by means of the \code{autocompletion="none"} attribute notoriously doesn't really work. The larger problem is that the post/redirect/get pattern is not followed, as stated above at our analysis of OWASP requirement (9.1).
+ \item \textbf{Privacy violation}: \HTML{} forms do not disable autocompletion. Labelled \textbf{high}. However, autocompletion of \HTML{} forms by means of the \code{autocompletion="none"} attribute notoriously does not really work. The larger problem is that the post/redirect/get pattern is not followed, as stated above at our analysis of OWASP requirement (9.1).
\item Fortify complains that \PHP{}'s \code{crypt(...)} function is \textbf{weak encryption} and labels the 5 usages \textbf{high}.
\end{enumerate}
% Initial approach
We were quickly set up and started to do each own parts of the audit by hand.
For each OWASP ASVS item specific to certain mechanisms (like login and input
-validation), we took the source code of the \CMS{} and follow the control
-flow to see if the application satisfies the security requirement. For more
+validation), we took the source code of the \CMS{} and followed the control
+flow to see if the application satisfied the security requirement. For more
general requirements, we could just look at the code that is responsible for
this requirement (like the \code{Response} class in the case of \HTTP{} security).
-When we had found that a requirement was not satisfied, we elaborate shortly
-and move on.
+When we had found that a requirement was not satisfied, we elaborated shortly
+and moved on.
This went well, because with five people the individual workload is just not
that big. Furthermore, finding vulnerabilities is a lot easier than verifying
When we finished the report, each of us reread the other parts to check
if things had been missed or reported incorrect. This may not have thorough, but
because in the end five pairs of eyes have read all verdicts, we trust that, in
-the end, we feel all verdicts are sufficiently checked.
+the end, all verdicts are sufficiently checked.
\documentclass[a4paper,titlepage]{article}
\usepackage{CJKutf8}
+\usepackage[british]{babel}
\usepackage{rutitlepage}
\usepackage{geometry}
\usepackage{hyperref}
\usepackage{calc}
\usepackage{amsmath}
\usepackage{amssymb}
-\usepackage{booktabs}% good looking tables
+\usepackage{booktabs}
\hypersetup{hidelinks, pdftitle={OWASP ASVS Souce Code Review Project}}
% Reference naar de source
-\newcommand{\srcref}[2]{{\small\texttt{#1}} (line(s) #2)}
+\newcommand{\srcref}[2]{{\small\texttt{#1}} (line (s) #2)}
% Pass en fail
\newcommand{\pass}{{\large\ding{51}}}
\newcommand{\fail}{{\large\ding{55}}}
-\newcommand{\TODO}{\ding{111} \textbf{\itshape TODO}}
+\newcommand{\TODO}{\ding{111} \textbf{\itshape{} TODO}}
% span code fragments
\newcommand{\code}[1]{\texttt{#1}}
We have noticed that, when doing an audit in a team, it is not feasible for
everybody to have read all source code. Trying this is just a bad
idea. We are happy to have divided the project by ASVS category, instead of
-program component. For each requirement the the ASVS, the
+program component. For each requirement the ASVS, the
team had to verify that there were no mistakes in the code. This would have
taken a lot of time if we had to verify each component for each requirement.
Furthermore, the ASVS is an easy guide for dividing the work\footnote{The
categories in the ASVS are all more or less of similar size. We settled on giving each team
member two categories to check.}. Dividing by component would have been a lot
harder to do fairly, especially because when beginning the project we had
-little knowledge of the internals (and component sizes) of the CMS.
+little knowledge of the internals (and component sizes) of the \CMS{}.
-We haven't experimented with working in pairs. This might be a good idea to
+We have not experimented with working in pairs. This might be a good idea to
experiment with. We are confident however that, because we have all checked
each other's finished work (and the final product), we did not miss any
problems.
% How useful were code analysis tools?\r
The usefulness of the Fortify Static Code Analysis tool turned out to be very limited.\r
-Since we had most verdicts ready before a license was provided we couldn't use\r
+Since we had most verdicts ready before a license was provided we could not use\r
the tool as an initial guide through the code. This forced us to manually check\r
the application source which took quite some time. After the tool became available we\r
-didn't get any new insights regarding potential security risks, just more examples\r
+did not get any new insights regarding potential security risks, just more examples\r
of problems we already detected. An example would be the use of the \code{crypt()} \PHP{}\r
function which will, on some platforms, use the outdated \code{DES} algorithm in order to encrypt data. The\r
use of this function would pose a security risk and results in a failed check. Since\r
we where only interested in providing a verdict for each check a single occurrence of\r
this function allowed us to back-up our verdict. Fortify provides a full list of all\r
occurrences which could be used to fix the application, our verdict on the other hand\r
-doesn't provide the developer with any information on how to fix the problem. We just\r
+does not provide the developer with any information on how to fix the problem. We just\r
state that there is a problem.\r
\r
% How could they be improved? (niet echt een antwoord maar we hebben de tool ook niet echt gebruikt?)\r
out actual security flaws.\r
\r
% How did you experience the rates and amounts of false and true positives?\r
-As far we where able to verify the tool didn't produce any false positives.\r
+As far we where able to verify the tool did not produce any false positives.\r
However, Fortify was not able to detect all problems we found.\r
Fortify concluded the application passed all checks in the \r
-Error reporting and Logging (V8) section, however we detected a number of severe\r
+Error reporting and Logging (\ref{sec:V8}) section, however we detected a number of severe\r
problems in this area.\r
\r
% How might that be improved?\r
\subsection{Cryptography at rest}
\input{v7_cryptography.tex}
- \subsection{Error Handling \& logging}
+ \subsection{Error Handling \& logging}\label{sec:V8}
\input{v8_error.tex}
\subsection{Data Protection}
\item Folders, files, info over these data
\end{itemize}
-Our check reveals that the access control mechanisms are basically only a stub, and haven't been developed to their usually implied meaning, thus flattening the access control to the single aspect of being logged in or not. Hence, the main remaining security consideration deal with whether this login mechanism protects `back-end' objects from anonymous users.
+Our check reveals that the access control mechanisms are basically only a stub, and have not been developed to their usually implied meaning, thus flattening the access control to the single aspect of being logged in or not. Hence, the main remaining security consideration deal with whether this login mechanism protects `back-end' objects from anonymous users.
These are the results of our check:
\begin{result}
\begin{itemize}[leftmargin=*]
\item \code{.gitignore} is freely accessible, as well as any other dot-preceded file (except \code{.htaccess}, which is hidden by default Apache rules), as well as files such as \code{Thumbs.db} and \code{.DS\_Store}.
- \item Directory contents were listed in my simple setup. A global apache setting may disable by default, but the \code{.htaccess} file doesn't explicitly disable (with \code{Options -Indexes}), so that the \CMS{}'s code-base basically enables the listing by default.
+ \item Directory contents were listed in my simple setup. A global apache setting may disable by default, but the \code{.htaccess} file does not explicitly disable (with \code{Options -Indexes}), so that the \CMS{}'s code-base basically enables the listing by default.
\end{itemize}
\end{result}
This is described in more detail in item V2.6 on page~\pageref{auth:6}.
\end{result}
-\notapplicable{
+\notapplicable{%
\item
Verify that there is a centralized mechanism (including
libraries that call external authorization services) for
\begin{result}
Failed login attempts or password resets are not logged at all.
Only actual crashes or unrecoverable errors are logged.
- Failed/unauthorized installation attempts won't get logged either.
+ Failed/unauthorized installation attempts will not get logged either.
\end{result}
\item\fail{} Verify that each log event includes necessary
happens.
\begin{result}
- Log information is very minimal and doesn't include the date and time unless it's part of the exception message.
+ Log information is very minimal and does not include the date and time unless it's part of the exception message.
Only information available regarding the moment an error occurred is the date used as the log filename.
\end{result}
The application itself does not log any usernames or passwords.
\code{PDOException}s end up in the log files however, the database driver implementation
could append sensitive data to the exception message.
- Documentation suggesting users should verify that the database driver they end up using doesn't include sensitive data in exception messages is absent.
+ Documentation suggesting users should verify that the database driver they end up using does not include sensitive data in exception messages is absent.
\end{result}
\notapplicable{\item Verify that all non-printable symbols and field
features.
\begin{result}
- The login and page/post editing/creation forms post back to the same page, thereby incentivising the browser to cache the form inputs as well. This is as opposed to the common post/redirect/get model (see \url{http://en.wikipedia.org/wiki/Post/Redirect/Get}). Also, the \code{Cache-Control} isn't explicitly used anywhere in the \CMS{} to aid the situation. In our test setup, the response does send \code{Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0}, but expect that this depends on the platform.
+ The login and page/post editing/creation forms post back to the same page, thereby incentivising the browser to cache the form inputs as well. This is as opposed to the common post/redirect/get model (see \url{http://en.wikipedia.org/wiki/Post/Redirect/Get}). Also, the \code{Cache-Control} is not explicitly used anywhere in the \CMS{} to aid the situation. In our test setup, the response does send \code{Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0}, but expect that this depends on the platform.
\end{result}
\notapplicable{\item Verify that the list of sensitive data processed by the
repositories / ssproject1617.git / commitdiff