typo's

[ssproject1617.git] / report / fortify.tex

diff --git a/report/fortify.tex b/report/fortify.tex
index b36d015..3f6f060 100644 (file)
--- 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}