\begin{itemize}
\item A login mechanism, where logged in users are allowed to access the backend, and anonymous users are not.
\item For logged in users, a role system with three specified roles: admin, editor and regular user.
- \item Different users (cap.~diff?)
\end{itemize}
\noindent
\item Folders, files, info over these data
\end{itemize}
-Our check reveales that the access control mechanisms are basically only a stub, and haven't been developed to their usually implied meaning, thus flattening the access control to the single ascept of being logged in or not. Hence, the main remaining security consideration deal with whether this login mechanism protects `backend' objects from anonymous users.
+Our check reveales that the access control mechanisms are basically only a stub, and haven't been developed to their usually implied meaning, thus flattening the access control to the single aspect of being logged in or not. Hence, the main remaining security consideration deal with whether this login mechanism protects `backend' objects from anonymous users.
These are the results of our check:
against spoofing and elevation of privilege.
\begin{result}
-The login system that is in place seems to work, and at least theoretically only allows registered users to access the backend.
+Aside from the authentication issues as described in V2, the login system that is in place works as intended, and theoretically only allows registered users to access the backend.
There is a role system, but it seems only to be a stub, for the role of a user has no effect whatsoever on their capabilities.
\end{result}
\begin{result}
There is no different access context for distinct users. In particular, they
are allowed to access and edit each others' account info, including
- password. Taken one way, this could be said to be by design and thus OK\. But in any reasonable design concept allowing for distinct user accounts, this is clearly not the desired setup.
+ password. Taken one way, this could be said to be by design and thus OK. But in any reasonable design concept allowing for distinct user accounts, this is clearly not the desired setup.
\end{result}
\item
\begin{result}
\begin{itemize}[leftmargin=*]
- \item \code{.gitignore} accessible, as well as any other dot-preceded file (except \code{.htaccess} itself by default Apache rules), as well as files such as \code{Thumbs.db} and \code{.DS\_Store}.
+ \item \code{.gitignore} is freely accessible, as well as any other dot-preceded file (except \code{.htaccess}, which is hidden by default Apache rules), as well as files such as \code{Thumbs.db} and \code{.DS\_Store}.
\item Directory contents were listed in my simple setup. A global apache setting may disable by default, but the \code{.htaccess} file doesn't explicitly disable (with \code{Options -Indexes}), so that the \CMS{}'s codebase basically enables the listing by default.
\end{itemize}
\end{result}
presentation layer are enforced on the server side.
\begin{result}
-Fail, because the role and distinct user systems are stubs.
+The role and distinct user systems are stubs.
\end{result}
\item
manipulated by end users unless specifically authorized.
\begin{result}
-This item is the main remaining security concern, as the login form allows SQL
+This item is the main security concern, as the login form allows \SQL{}
injections that are capable to alter any information stored in the database.
This is described in more detail in item V2.6 on page~\pageref{auth:6}.
\end{result}
all failed decisions are logged.
\begin{result}
-No such decision logging present. There is only a minor amount of logging, and this is related to not finding content (pages and articles).
+No such decision logging present. There is only a minor amount of logging, and
+this is only related to not finding content (pages and articles).
\end{result}
\item
repositories / ssproject1617.git / blobdiff