Minor latex changes: changed the presentation of requirement results slightly for...
authorKelley van Evert <hello@kelleyvanevert.nl>
Wed, 19 Oct 2016 15:14:50 +0000 (17:14 +0200)
committerKelley van Evert <hello@kelleyvanevert.nl>
Wed, 19 Oct 2016 15:14:50 +0000 (17:14 +0200)
OWASP_Application_Security_Verification_Standard_3.0.1.pdf [new file with mode: 0644]
report/preamble.tex
report/report.tex
report/v5_input.tex

diff --git a/OWASP_Application_Security_Verification_Standard_3.0.1.pdf b/OWASP_Application_Security_Verification_Standard_3.0.1.pdf
new file mode 100644 (file)
index 0000000..fb94159
Binary files /dev/null and b/OWASP_Application_Security_Verification_Standard_3.0.1.pdf differ
index a72256a..692cea3 100644 (file)
@@ -7,12 +7,27 @@
 \usepackage{enumitem}
 \usepackage{pifont}
 \usepackage[dvipsnames]{xcolor}
+\usepackage{mdframed}
 
 \hypersetup{hidelinks, pdftitle={OWASP ASVS Souce Code Review Project}}
 
 % Als een criterium niet applicable is (we doen alleen 1 en 2)
 \newcommand{\notapplicable}[1]{{\color{Gray} #1}}
 
+% Layout voor resultaat van requirement check.
+% (Anders loopt de tekst vd requirement direct over in het resultaat, wat niet duidelijk leest.)
+\newmdenv[
+  topline=false,
+  bottomline=false,
+  rightline=false,
+  linewidth=1.5pt,
+  innerrightmargin=0pt,
+  innertopmargin=2pt,
+  innerbottommargin=2pt,
+  skipabove=\topsep,
+  skipbelow=\topsep
+]{result}
+
 % Tools afkortingen
 \newcommand{\PHP}{\textsc{PHP}}
 \newcommand{\SQL}{\textsc{SQL}}
 \newcommand{\srcref}[2]{{\small\texttt{#1}} (line (s) #2)}
 
 % Pass en fail
-\newcommand{\pass}{\ding{51}}
-\newcommand{\fail}{\ding{55}}
+\newcommand{\pass}{{\large\ding{51}}}
+\newcommand{\fail}{{\large\ding{55}}}
+\newcommand{\TODO}{\ding{111} \textbf{\itshape TODO}}
+
+% span code fragments
+\newcommand{\code}[1]{\texttt{#1}}
 
 \renewcommand\thesubsection{V\arabic{subsection}}
 
index 8213ab1..c4f7fcf 100644 (file)
@@ -11,6 +11,7 @@
 \subsection{Session Management}
 
 \subsection{Access Control}
+\input{v4_access.tex}
 
 \subsection{Input Validation \& Output Encoding/Escaping}
 \input{v5_input.tex}
index 51e31d5..cf8a09a 100644 (file)
        \item\pass{} Verify that the runtime environment is not susceptible to buffer
                overflows, or that security controls prevent buffer overflows.
 
+               \begin{result}
                As of \emph{OWASP}'s statement\footnote{\url{%
                        https://www.owasp.org/index.php/Buffer_Overflows\#Platforms_Affected}}
                \PHP{} is not surceptible to buffer overflows as long no external
                programs or extensions are used which is not the case.
+               \end{result}
+
        % They skip 5.2
        \addtocounter{enumi}{1}
        \item\fail{} Verify that server side input validation failures result in 
                request rejection and are logged.
 
-               \texttt{filter\_var} is used for input validation and while errors are
+               \begin{result}
+               \code{filter\_var} is used for input validation and while errors are
                returned to the user, no logging taking place.
+               \end{result}
+
        % They skip 5.4
        \addtocounter{enumi}{1}
        \item\pass{} Verify that input validation routines are enforced on the
                server side.
 
+               \begin{result}
                Errors are accumulated in an array which, when non-empty, will fail the
                function and report the error.
+               \end{result}
+
        \notapplicable{\item Verify that a single input validation control is used
                by the application for each type of data that is accepted.}
 
        % They skip 5.7-5.9
        \addtocounter{enumi}{3}
-       \item\fail{} Verify that all \SQL{} queries, \texttt{HQL}, \texttt{OSQL},
-               \texttt{NOSQL} and stored procedures, calling of stored procedures are
+       \item\fail{} Verify that all \SQL{} queries, \code{HQL}, \code{OSQL},
+               \code{NOSQL} and stored procedures, calling of stored procedures are
                protected by the use of prepared statements or query parameterization,
                and thus not susceptible to \SQL{} injection.
 
+               \begin{result}
                This is not the case. For example in \srcref{classes/users.php}{45}.
                However, in some cases prepared statements are used, such as is
                \srcref{classes/users.php}{145}.
+               \end{result}
+
        \item\pass{} Verify that the application is not susceptible to LDAP
                Injection, or that security controls prevent LDAP Injection.
 
+               \begin{result}
                \LDAP{} is not used, thus the application is not susceptible.
+               \end{result}
+
        \item\pass{} Verify that the application is not susceptible to OS Command
                Injection, or that security controls prevent OS Command Injection.
 
+               \begin{result}
                This requirement heavily depends on the configuration of the \PHP{}
                interpreter and database, there are no system commands used but since
                it is trivial to do an \SQL{} injection it might be possible to run
                commands via the database. However, which a sufficiently secure \SQL{}
                config this can not take place.
+               \end{result}
 
        %TODO hier nog even naar kijken
        \item\pass{} Verify that the application is not susceptible to Remote File
                Inclusion (RFI) or Local File Inclusion (LFI) when content is used that
                is a path to a file.
 
+               \begin{result}
                Some file inclusion might be possible in the themes. Also in password
                recovery\\
                (\srcref{classes/user.php}{115}) filepaths are calculated on the
                hash of the password. All non standard filepaths, such as admin or
                theme files, are generated using functions. CMS urls are parsed using a
-               standard system wide \texttt{parse} function.
+               standard system wide \code{parse} function.
+               \end{result}
+
        \item\pass{} Verify that the application is not susceptible to common
                \XML{} attacks, such as XPath query tampering, \XML{} External Entity
                attacks, and \XML{} injection attacks. 
 
+               \begin{result}
                No \XML{} or related techniques are used and thus the application is
                not susceptible.
+               \end{result}
+
        \item\fail{} Ensure that all string variables placed into \HTML{} or other
                web client code is either properly contextually encoded manually, or
                utilize templates that automatically encode contextually to ensure the
                application is not susceptible to reflected, stored and DOM Cross-Site
                Scripting (XSS) attacks.
 
+               \begin{result}
                A lot of \HTML{} tags are allowed in the post screen, therefore an XSS
                attack is trivial. Even the comment section uses no input validation
                whatsoever.
+               \end{result}
+
        \item\pass{} If the application framework allows automatic mass parameter
                assignment (also called automatic variable binding) from the inbound
                request to a model, verify that security sensitive fields such as
                ``accountBalance'', ``role'' or ``password'' are protected from
                malicious automatic binding.
 
+               \begin{result}
                There is some automatic variable binding happening in the POST and GET
                however, defaults are always given and there is no possibility of
                accidentally binding extra variables. Also the variables are in an
                array.
+               \end{result}
+
        \item\pass{} Verify that the application has defenses against HTTP
                parameter pollution attacks, particularly if the application framework
                makes no distinction about the source of request parameters (GET, POST,
                cookies, headers, environment, etc.)
 
+               \begin{result}
                The system explicitly makes a difference with the different input
                types. As said in the previous item, the function that does this
                parameter parsing is system wide and uses defaults and filters unwanted
                parameters.
+               \end{result}
+
        \item\fail{} Verify that client side validation is used as a second line of
                defense, in addition to server side validation.
 
+               \begin{result}
                There is client side validation on comments in the email section. There
                is no validation for the comments itself to check for malafide \HTML{}.
                In the admin panel the email address is not validated.
+               \end{result}
+
        \item\fail{} Verify that all input data is validated, not only \HTML{} form
                fields but all sources of input such as REST calls, query parameters,
                HTTP headers, cookies, batch files, RSS feeds, etc; using positive
                greylisting (eliminating known bad strings), or rejecting bad inputs
                (blacklisting).
 
+               \begin{result}
                REST calls are validated using whitelisting, query parameters are not,
                headers are not, cookies not, batch files are non-existent and RSS feed
                output is not filtered.
+               \end{result}
+
        \item\pass{} Verify that structured data is strongly typed and validated
                against a defined schema including allowed characters, length and
                pattern (e.g.\  credit card numbers or telephone, or validating that two
                related fields are reasonable, such as validating suburbs and zip or
                post codes match). 
 
+               \begin{result}
                Email addresses are validated against \PHP's stander functionality.
                Note that the \PHP{} email validation is not perfect and some valid
                email addresses are rejected (such as email addresses with non-ASCII
                characters). The other requirements are not used.
+               \end{result}
+
        \item\pass{} Verify that unstructured data is sanitized to enforce generic
                safety measures such as allowed characters and length, and characters
                potentially harmful in given context should be escaped (e.g.\ natural
                names with Unicode or apostrophes, such as
                \begin{CJK}{UTF8}{min}ねこ\end{CJK} or O'Hara)
 
+               \begin{result}
                Emailaddresses with non-ASCII characters are rejected. Unicode
                characters are displayed correctly.
+               \end{result}
+
        \item\fail{} Make sure untrusted \HTML{} from WYSIWYG editors or similar are
                properly sanitized with an \HTML{} sanitizer and handle it
                appropriately according to the input validation task and encoding task. 
 
+               \begin{result}
                This is not the case, any \HTML{} is allowed.
+               \end{result}
+
        \item\fail{} For auto-escaping template technology, if UI escaping is disabled,
                ensure that \HTML{} sanitization is enabled instead.
 
+               \begin{result}
                See previous item.
+               \end{result}
+
        \item\pass{} Verify that data transferred from one DOM context to another,
-               uses safe JavaScript methods, such as using \texttt{.innerText} and
-               \texttt{.val}.
+               uses safe JavaScript methods, such as using \code{.innerText} and
+               \code{.val}.
 
+               \begin{result}
                The \JQuery{} framework is used for this.
+               \end{result}
+
        \item\pass{} Verify when parsing \JSON{} in browsers, that
-               \texttt{JSON.parse} is used to parse \JSON{} on the client. Do not use
-               \texttt{eval()} to parse \JSON{} on the client.
+               \code{JSON.parse} is used to parse \JSON{} on the client. Do not use
+               \code{eval()} to parse \JSON{} on the client.
 
+               \begin{result}
                There is no \JSON{} transfer outside the toolkits.
+               \end{result}
+
        \item\pass{} Verify that authenticated data is cleared from client storage,
                such as the browser DOM, after the session is terminated.
 
+               \begin{result}
                No DOM storage is used.
+               \end{result}
+
 \end{enumerate}