+
+ \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}
+