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

diff --git a/report/v5_input.tex b/report/v5_input.tex
index 7a01436..5e81429 100644
--- a/report/v5_input.tex
+++ b/report/v5_input.tex
@@ -1,4 +1,4 @@
-\begin{enumerate}[label={5.\arabic*}]
+\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.
 
@@ -11,7 +11,7 @@
 
 	% They skip 5.2
 	\addtocounter{enumi}{1}
-	\item\fail{} 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}
@@ -45,8 +45,8 @@
 		\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\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.
@@ -72,13 +72,13 @@
 		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
+		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. 
+		attacks, and \XML{} injection attacks.
 
 		\begin{result}
 		No \XML{} or related techniques are used and thus the application is
@@ -89,10 +89,10 @@
 		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.
+		Scripting (\XSS{}) attacks.
 
 		\begin{result}
-		A lot of \HTML{} tags are allowed in the post screen, therefore an XSS
+		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}
@@ -104,15 +104,15 @@
 		malicious automatic binding.
 
 		\begin{result}
-		There is some automatic variable binding happening in the POST and GET
+		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
+	\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,
+		makes no distinction about the source of request parameters (\GET{}, \POST{},
 		cookies, headers, environment, etc.)
 
 		\begin{result}
@@ -132,14 +132,14 @@
 		\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
+		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,
+		\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}
@@ -148,7 +148,7 @@
 		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). 
+		post codes match).
 
 		\begin{result}
 		Email addresses are validated against \PHP's stander functionality.
@@ -164,13 +164,13 @@
 		\begin{CJK}{UTF8}{min}ねこ\end{CJK} or O'Hara)
 
 		\begin{result}
-		Emailaddresses with non-ASCII characters are rejected. Unicode
+		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. 
+		appropriately according to the input validation task and encoding task.
 
 		\begin{result}
 		This is not the case, any \HTML{} is allowed.
@@ -180,7 +180,7 @@
 		ensure that \HTML{} sanitization is enabled instead.
 
 		\begin{result}
-		See previous item.
+		Just as with the previous item, any \HTML{} is allowed.
 		\end{result}
 
 	\item\pass{} Verify that data transferred from one DOM context to another,