\begin{result}
Password are stored in database using the PHP function \texttt{crypt}. Internally, this
- function uses salted MD5. This is way too reverse with brute-force attacks using dictionary files.
+ function uses salted MD5. This is way easy too reverse with brute-force attacks using dictionary files.
Instead it would be better to use the \texttt{argon2} password hashing algorithm
or the PHP \texttt{password\_hash} function (which currently uses BCRYPT).
\item Email validation, to harden brute force email address discovery
\item Installation database check, to prevent guessing attacks for the database password
\item Login, to prevent login guessing
- \item And comment submission, to prevent spam, phishing et cetera (by using CAPTCHA).
+ \item And comment submission, to prevent spam, phishing et cetera (by
+ using some CAPTCHA software).
\end{itemize}
\end{result}
\end{verbatim}
This implies making the configuration file readable for all users on the
system. This information should not be accessible for any user other than
- running the PHP script.
+ the one running the PHP script.
\end{result}
\item
\begin{result}
No password strengthening measures are implemented. The app should
- use some password strength estimator like \texttt{zxcvbn}.
+ use some password strength estimator like \texttt{zxcvbn}\footnote{\url{https://github.com/dropbox/zxcvbn}}.
\end{result}
\item
% 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}
\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
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.
\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.
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,
\begin{enumerate}[label={V8.\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
+ \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
+ 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
+
+ \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 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
+
+ \item\fail{} Verify security logging controls provide the ability
+ to log success and
+ particularly failure events that
are identified as security-relevant.
\begin{result}
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
+
+ \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.
+ 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
+ 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
+
+ \item\pass{} Verify that security logs are protected from
unauthorized access and modification.
\begin{result}
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.
+
+ \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 API tokens.
\begin{result}
The application itself does not log any usernames/passwords.
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}
-
-\notapplicable{\item Verify that all non-printable symbols and field
- separators are properly encoded in log entries, to
+
+\notapplicable{\item Verify that all non-printable symbols and field
+ separators are properly encoded in log entries, to
prevent log injection.}
-\notapplicable{\item Verify that log fields from trusted and untrusted
+\notapplicable{\item Verify that log fields from trusted and untrusted
sources are distinguishable in log entries.}
-
+
\item\fail{} Verify that an audit log or similar allows for non-repudiation of key transactions.
\begin{result}
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}
-
-\notapplicable{\item Verify that security logs have some form of
- integrity checking or controls to prevent
+
+\notapplicable{\item Verify that security logs have some form of
+ integrity checking or controls to prevent
unauthorized modification.}
-
-\notapplicable{\item Verify that the
- logs are stored on a different
- partition than the application is running with
+
+\notapplicable{\item Verify that the
+ logs are stored on a different
+ partition than the application is running with
proper log rotation.}
-
- \item\fail{} Time sources should be synchronized to ensure
+
+ \item\fail{} Time sources should be synchronized to ensure
logs have the correct time.
\begin{result}
- Time information is not inserted into log messages.
+ 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}
repositories / ssproject1617.git / commitdiff