X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=report%2Fv5_input.tex;h=5e8142962602e89cc5498ffcd5b2dd5fa199ccdd;hb=9c1499262174ffd37af6f6e94de0da1901e2dc66;hp=618c2bfbe38adc7fa8bd75046192039fb8d22d1b;hpb=5675de2255bdfceb293ed7418a0478bc0af7cd75;p=ssproject1617.git

diff --git a/report/v5_input.tex b/report/v5_input.tex
index 618c2bf..5e81429 100644
--- a/report/v5_input.tex
+++ b/report/v5_input.tex
@@ -1,30 +1,209 @@
-\begin{enumerate}[label=5.\arabic*]
-	\item Verify that the runtime environment is not susceptible to buffer
+\begin{enumerate}[label={V5.\arabic*}]
+	\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 Verify that server side input validation failures result in 
+	\item\fail{} Verify that server side input validation failures result in
 		request rejection and are logged.
 
+		\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 Verify that input validation routines are enforced on the server
-		side.
+	\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}
 
-	\item\notapplicable{Verify that a single input validation control is used
+	\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 Verify that all SQL queries, HQL, OSQL, 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.
+	\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.
 
-	\item 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 Verify that the application is not susceptible to OS Command
+	\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}
+
+	\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 \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
+		validation (whitelisting), then lesser forms of validation such as
+		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}
+		Email addresses 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}
+		Just as with the previous item, any \HTML{} is allowed.
+		\end{result}
+
+	\item\pass{} Verify that data transferred from one DOM context to another,
+		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
+		\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}