\fail{}
Verify all pages and resources by default require
authentication except those specifically intended to be
-public (Principle of complete mediation).
+public (principle of complete mediation).
\begin{result}
All admin pages are private. Unpublished posts are also private.
\fail{}
Verify that forms containing credentials are not filled in by
the application. Pre-filling by the application implies that
-credentials are stored in plaintext or a reversible format,
+credentials are stored in plain-text or a reversible format,
which is explicitly prohibited.
\begin{result}
\begin{result}
All authentication controls (login credentials and client cookies) are
enforced by the application. Note however item~\ref{auth:6}, about the
- security of these controls in the immplementation.
+ security of these controls in the implementation.
\end{result}
\setcounter{enumi}{5}
\begin{result}
The input to various forms is not sanitized at all. This makes the implementation
- in (not only) \code{Users::find} vulnerable to \SQL{} injections. The login form
- is also vulnerable. Any user can execute arbitrary \SQL{} code from the username field.
+ in (not only) \code{Users::find} vulnerable to \SQL{} injections. Through this vulnerability,
+ an attacker can execute arbitrary \SQL{} code from the username field in the login form.
The following example code can submitted as username in the login form, which
will set the password of the \code{admin} user to \code{s3cret}:
\item
\pass{}
Verify password entry fields allow, or encourage, the use
-of passphrases, and do not prevent password managers,
-long passphrases or highly complex passwords being
+of pass-phrases, and do not prevent password managers,
+long pass-phrases or highly complex passwords being
entered.
\begin{result}
- The application allows the user to use any password (except ones that contain
- \SQL{} code).
+ The application allows the user to use any password (except ones that trigger
+ errors in injected \SQL{} code).
\end{result}
\item
force and password hash recovery attacks.
\begin{result}
- Password are stored in database using the \PHP{} function \code{crypt}. Internally, this
- function uses salted MD5. This is way too reverse with brute-force attacks using dictionary files.
-
- Instead it would be better to use the \code{argon2} password hashing algorithm
- or the \PHP{} \code{password\_hash} function (which currently uses BCRYPT).
+ Password are stored in database using the \PHP{} function \code{crypt}. Internally, this
+ function uses salted MD5 on modern UNIX systems. On legacy systems, this uses an old DES
+ based algorithm, which uses only the first eight characters of the supplied password.
+ This is way too easy to reverse with brute-force attacks using dictionary files.
+
+ Instead the \CMS{} should use the \code{argon2} password hashing algorithm
+ or the \PHP{} \code{password\_hash} function (which currently uses BCRYPT) which are
+ (at this moment) considered safe to use.
\end{result}
\setcounter{enumi}{15}
link.
\begin{result}
- The app allows admin users to log in over \HTTP{}. This is insecure, as it allows
- eavesdroppers to intercept password.
- The app should force \HTTPS{} for at least the login form, the \code{admin\_controller} and
+ The app allows admin users to log in over \HTTP{}. This is insecure, as it allows
+ eavesdroppers to intercept any password.
+ The app should force \HTTPS{} for at least the login form, the \code{admin\_controller} and
for the installation script (because the users posts secrets like the database
- password to this page).
+ password to this page and the \CMS{} supplies the user with the credentials of the \code{admin}
+ account).
\end{result}
\item
\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 some CAPTCHA software).
+ using some CAPTCHA software.
\end{itemize}
\end{result}
stored in a protected location.
\begin{result}
- The database credentials are hardcoded in \code{config.php}. While it
+ The database credentials are hard-coded in \code{config.php}. While it
would be better to pass secrets as environment variables, this is not
really bad practice.
However, the installation instructions state the following:
\begin{verbatim}
Change the file permissions to allow all users write access to the
-folder you extracted testcms to.
+folder you extracted TestCMS to.
\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
transaction signing is in place for high value transactions.
\begin{result}
- There are no (really) risk based action or which re-authentication would be
+ There are no (really) risk based action for which re-authentication would be
fit.
\end{result}
\item
\fail{}
Verify that measures are in place to block the use of
-commonly chosen passwords and weak passphrases.
+commonly chosen passwords and weak pass-phrases.
\begin{result}
No password strengthening measures are implemented. The app should
disclosure.
\begin{result}
- No surch features are implemented.
+ No such features are implemented.
\end{result}
\item
\item
\pass{}
-Browser autocomplete, and integration with password
+Browser auto-complete, and integration with password
managers are permitted unless prohibited by risk based
policy.
\begin{result}
- Browser autocomplete functionality is not restricted in any way.
+ Browser auto-complete functionality is not restricted in any way.
\end{result}
\end{enumerate}
repositories / ssproject1617.git / blobdiff