\begin{enumerate}[label={8.\arabic*}]
	\item\fail{} Verify that the application does not output error 
		messages or stack traces containing sensitive data 
		that could assist an attacker, 
		including session id, 
		software/framework versions and personal 
		information.

		\begin{result}
		Disabled by default but there is no way to enable error logging 
		without outputting detailed error information. \emph{PDOException::getMessage}
		is directly logged to the specified logging target (user or logfile).
		\end{result}
	
	\item\pass{} Verify that error handling logic in security controls 
		denies access by default.

		\begin{result}
		The limited number of errors actually handled do block access. 
		The software passes this check, this however is a side effect of limited error handling.
		\end{result}
	
	\item\fail{} Verify security logging controls provide the ability 
		to log success and 
		particularly failure events that 
		are identified as security-relevant.

		\begin{result}
		Failed login attempts or password resets are not logged at all.
		Only actual crashes/unrecoverable errors are logged.
		Failed/unauthorized installation attempts won't get logged either.
		\end{result}
	
	\item\fail{} Verify that each log event includes necessary 
		information that would allow for a detailed 
		investigation of the timeline when an event 
		happens.

		\begin{result}
		Log information is very minimal and doesn't include the date and time unless it's part of the exception message. 
		Only information available regarding the moment an error occoured is the date used as the log filename.
		\end{result}
	
	\item\pass{} Verify that all
		events that include untrusted data 
		will not execute as code in the intended log 
		viewing software.

		\begin{result}
		Plaintext logfiles are used and if any data injected into the logfile ends up being executed this would be a security flaw of the text editor used as a viewer.
		\end{result}
	
	\item\pass{} Verify that security logs are protected from 
		unauthorized access and modification.

		\begin{result}
		There is a htaccess which is supposed to block access to the log files.
		Blocking access to the logs depends on the server configuration
		because the log files are part of the main program directory.
		Clear documentation which warns users about this behavior is missing.
		\end{result}
	
	\item\pass{} Verify that the application does not log 
		sensitive 
		data as defined under local privacy laws or 
		regulations, organizational sensitive data as 
		defined by a risk assessment, or sensitive 
		authentication data that could assist an attacker, 
		including user's session identifiers, passwords, 
		hashes, or AP
		I tokens.

		\begin{result}
		The application itself does not log any usernames/passwords.
		\emph{PDOException}'s end up in the log files however, the database driver implementation
		could append sensitive data to the exception message.
		Documentation suggesting users should verify that the database driver they end up using doesn't include sensitive data in exception messages is absent.
		\end{result}
	
	\item\pass{} Verify that all non-printable symbols and field 
		separators are properly encoded in log entries, to 
		prevent log injection.

		\begin{result}
		\end{result}
	
	\item\pass{} Verify that log fields from trusted and untrusted 
		sources are distinguishable in log entries.

		\begin{result}
		\end{result}
	
	\item\fail{} Verify that an audit log or similar allows for non-repudiation of key transactions.

		\begin{result}
		Failed login attempts, password reset, login/logout... are not logged at all.
		It's not possible to retreive the IP address from which a password reset has been issued.
		Only potential requests are logged even before it's verified such an action exists.
		\end{result}
	
	\item\pass{} Verify that security logs have some form of 
		integrity checking or controls to prevent 
		unauthorized modification.

		\begin{result}
		\end{result}
	
	\item\pass{} Verify that the 
		logs are stored on a different 
		partition than the application is running with 
		proper log rotation.

		\begin{result}
		\end{result}
	
	\item\fail{} Time sources should be synchronized to ensure 
		logs have the correct time.

		\begin{result}
		Time information is not inserted into log messages. 
		The actual log files however are named after the current system date, this gives a precision of 24 hours.
		\end{result}
\end{enumerate}