\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.
\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}:
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}
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}
disclosure.
\begin{result}
- No surch features are implemented.
+ No such features are implemented.
\end{result}
\item