From: Mart Lubbers Date: Tue, 6 Dec 2016 10:17:20 +0000 (+0100) Subject: typo's X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=44cda6e8361838491689480eb642eefa9b986b1c;p=ssproject1617.git typo's --- diff --git a/report/Makefile b/report/Makefile index b12d7fd..c327e19 100644 --- a/report/Makefile +++ b/report/Makefile @@ -1,7 +1,7 @@ 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) @@ -13,12 +13,14 @@ all: $(DOC).pdf %.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)\ diff --git a/report/fortify.tex b/report/fortify.tex index b36d015..3f6f060 100644 --- a/report/fortify.tex +++ b/report/fortify.tex @@ -10,7 +10,7 @@ Fortify's results can be summarized to the following: \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} diff --git a/report/organization.tex b/report/organization.tex index 31eb119..3cdd946 100644 --- a/report/organization.tex +++ b/report/organization.tex @@ -26,12 +26,12 @@ a sound level 2 audit on the software. % 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 @@ -49,4 +49,4 @@ could then use. 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. diff --git a/report/preamble.tex b/report/preamble.tex index 3e2046a..15697c4 100644 --- a/report/preamble.tex +++ b/report/preamble.tex @@ -1,6 +1,7 @@ \documentclass[a4paper,titlepage]{article} \usepackage{CJKutf8} +\usepackage[british]{babel} \usepackage{rutitlepage} \usepackage{geometry} \usepackage{hyperref} @@ -12,7 +13,7 @@ \usepackage{calc} \usepackage{amsmath} \usepackage{amssymb} -\usepackage{booktabs}% good looking tables +\usepackage{booktabs} \hypersetup{hidelinks, pdftitle={OWASP ASVS Souce Code Review Project}} @@ -68,12 +69,12 @@ % 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}} diff --git a/report/reflection.auditing_process.tex b/report/reflection.auditing_process.tex index 9413548..844a1d7 100644 --- a/report/reflection.auditing_process.tex +++ b/report/reflection.auditing_process.tex @@ -4,16 +4,16 @@ 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. diff --git a/report/reflection.tools.tex b/report/reflection.tools.tex index 4205902..15ee8a7 100644 --- a/report/reflection.tools.tex +++ b/report/reflection.tools.tex @@ -1,16 +1,16 @@ % How useful were code analysis tools? The usefulness of the Fortify Static Code Analysis tool turned out to be very limited. -Since we had most verdicts ready before a license was provided we couldn't use +Since we had most verdicts ready before a license was provided we could not use the tool as an initial guide through the code. This forced us to manually check the application source which took quite some time. After the tool became available we -didn't get any new insights regarding potential security risks, just more examples +did not get any new insights regarding potential security risks, just more examples of problems we already detected. An example would be the use of the \code{crypt()} \PHP{} function which will, on some platforms, use the outdated \code{DES} algorithm in order to encrypt data. The use of this function would pose a security risk and results in a failed check. Since we where only interested in providing a verdict for each check a single occurrence of this function allowed us to back-up our verdict. Fortify provides a full list of all occurrences which could be used to fix the application, our verdict on the other hand -doesn't provide the developer with any information on how to fix the problem. We just +does not provide the developer with any information on how to fix the problem. We just state that there is a problem. % How could they be improved? (niet echt een antwoord maar we hebben de tool ook niet echt gebruikt?) @@ -24,10 +24,10 @@ focus on determining which parts of a application need to be secure and less on out actual security flaws. % How did you experience the rates and amounts of false and true positives? -As far we where able to verify the tool didn't produce any false positives. +As far we where able to verify the tool did not produce any false positives. However, Fortify was not able to detect all problems we found. Fortify concluded the application passed all checks in the -Error reporting and Logging (V8) section, however we detected a number of severe +Error reporting and Logging (\ref{sec:V8}) section, however we detected a number of severe problems in this area. % How might that be improved? diff --git a/report/report.tex b/report/report.tex index c365b4e..9b6b780 100644 --- a/report/report.tex +++ b/report/report.tex @@ -41,7 +41,7 @@ \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} diff --git a/report/v4_access.tex b/report/v4_access.tex index 1c0468f..5ddc549 100644 --- a/report/v4_access.tex +++ b/report/v4_access.tex @@ -17,7 +17,7 @@ Some typical objects of access control, in this case, are: \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: @@ -70,7 +70,7 @@ such as \code{Thumbs.db}, \code{.DS\_Store}, \code{.git} or \code{.svn} folders. \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} @@ -104,7 +104,7 @@ injections that are capable to alter any information stored in the database. 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 diff --git a/report/v8_error.tex b/report/v8_error.tex index e667af8..b66874b 100644 --- a/report/v8_error.tex +++ b/report/v8_error.tex @@ -28,7 +28,7 @@ \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 @@ -37,7 +37,7 @@ 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} @@ -73,7 +73,7 @@ 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 diff --git a/report/v9_data.tex b/report/v9_data.tex index 1ea1f87..2354243 100644 --- a/report/v9_data.tex +++ b/report/v9_data.tex @@ -4,7 +4,7 @@ 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