X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=report%2Fv5_input.tex;h=51e31d59db81ea2fb690cb74efc17ce7d1ad7e88;hb=46c16a01449f1337ecc88bacc7ab6f1c24372475;hp=3660b5468acc86274db2e53b7976ac0b38344829;hpb=11f60376ef15f5e3288c81c05bb597a6faac6062;p=ssproject1617.git

diff --git a/report/v5_input.tex b/report/v5_input.tex
index 3660b54..51e31d5 100644
--- a/report/v5_input.tex
+++ b/report/v5_input.tex
@@ -15,8 +15,8 @@
 		returned to the user, no logging taking place.
 	% They skip 5.4
 	\addtocounter{enumi}{1}
-	\item\pass{} Verify that input validation routines are enforced on the server
-		side.
+	\item\pass{} Verify that input validation routines are enforced on the
+		server side.
 
 		Errors are accumulated in an array which, when non-empty, will fail the
 		function and report the error.
@@ -25,14 +25,14 @@
 
 	% They skip 5.7-5.9
 	\addtocounter{enumi}{3}
-	\item\fail{} 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.
-
-		This is not the case. For example in \srcref{users.php}{45}. However,
-		in some cases prepared statements are used, such as is
-		\srcref{users.php}{145}.
+	\item\fail{} Verify that all \SQL{} queries, \texttt{HQL}, \texttt{OSQL},
+		\texttt{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.
+
+		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}.
 	\item\pass{} Verify that the application is not susceptible to LDAP
 		Injection, or that security controls prevent LDAP Injection.
 
@@ -41,8 +41,111 @@
 		Injection, or that security controls prevent OS Command Injection.
 
 		This requirement heavily depends on the configuration of the \PHP{}
-		interpreter and database. There are no system commands used but since
+		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.
+
+	%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.
+
+		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.
+	\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. 
+
+		No \XML{} or related techniques are used and thus the application is
+		not susceptible.
+	\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.
+
+		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.
+	\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.
+
+		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.
+	\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.)
+
+		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.
+	\item\fail{} Verify that client side validation is used as a second line of
+		defense, in addition to server side validation.
+
+		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.
+	\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).
+
+		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.
+	\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). 
+
+		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.
+	\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)
+
+		Emailaddresses with non-ASCII characters are rejected. Unicode
+		characters are displayed correctly.
+	\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. 
+
+		This is not the case, any \HTML{} is allowed.
+	\item\fail{} For auto-escaping template technology, if UI escaping is disabled,
+		ensure that \HTML{} sanitization is enabled instead.
+
+		See previous item.
+	\item\pass{} Verify that data transferred from one DOM context to another,
+		uses safe JavaScript methods, such as using \texttt{.innerText} and
+		\texttt{.val}.
+
+		The \JQuery{} framework is used for this.
+	\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.
+
+		There is no \JSON{} transfer outside the toolkits.
+	\item\pass{} Verify that authenticated data is cleared from client storage,
+		such as the browser DOM, after the session is terminated.
+
+		No DOM storage is used.
 \end{enumerate}