Completed V4: Access Control

diff --git a/report/v4_access.tex b/report/v4_access.tex
index f5a80fb..506eea7 100644 (file)
--- a/report/v4_access.tex
+++ b/report/v4_access.tex
@@ -1,21 +1,64 @@
+
+\noindent
+The CMS has the following access control mechanisms:
+
+\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
+Some typical objects of access control, in this case, are:
+
+\begin{itemize}
+  \item Database records
+  \item Editing capabilities
+  \item Role privileges
+  \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.
+
+These are the results of our check:
+
 \begin{enumerate}[label={4.\arabic*}]
 
+% Access controls:
+%   - principle of least privilege?
+%   - inter-role/context safety
+%   - fail safely?
+%   - presentation -- server side
+%   - cannot be manipulated
+%   - onion layers
+%   - safe/working auth in place
+
 \item
-\TODO{}
+\fail{}
 Verify that the principle of least privilege exists - users
 should only be able to access functions, data files, URLs,
 controllers, services, and other resources, for which they
 possess specific authorization. This implies protection
 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.
+
+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}
+
 \addtocounter{enumi}{2}
 \item
-\TODO{}
+\fail{}
 Verify that access to sensitive records is protected, such
 that only authorized objects or data is accessible to each
 user (for example, protect against users tampering with a
 parameter to see or alter another user's account).
 
+\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.
+\end{result}
+
 \item
 \fail{}
 Verify that directory browsing is disabled unless
@@ -32,20 +75,32 @@ such as \code{Thumbs.db}, \code{.DS\_Store}, \code{.git} or \code{.svn} folders.
 
 \addtocounter{enumi}{2}
 \item
-\TODO{}
+\pass{}
 Verify that access controls fail securely.
 
+\begin{result}
+The only remaining access control mechanism is that of logging in. It fails securely, in the sense that no info about the correctness of the username/password pair are leaked (response time analysis not included); the single error message reads: ``Incorrect details.''
+\end{result}
+
 \item
-\TODO{}
+\fail{}
 Verify that the same access control rules implied by the
 presentation layer are enforced on the server side.
 
+\begin{result}
+Fail, because the role and distinct user systems are stubs.
+\end{result}
+
 \item
-\TODO{}
+\pass{}
 Verify that all user and data attributes and policy
 information used by access controls cannot be
 manipulated by end users unless specifically authorized.
 
+\begin{result}
+This item is the main remaining security concern. I haven't found any obvious fail in the login system, but given the architecture and security status of the whole CMS, I'm not very sure of it.
+\end{result}
+
 \notapplicable{
 \item
 Verify that there is a centralized mechanism (including
@@ -86,21 +141,25 @@ No such prevention present.
 \end{result}
 
 \item
-\TODO{}
+\fail{}
 Verify the application has additional authorization (such
 as step up or adaptive authentication) for lower value
 systems, and / or segregation of duties for high value
 applications to enforce anti-fraud controls as per the risk
 of application and past fraud.
 
-(nope)
+\begin{result}
+No such mechanisms.
+\end{result}
 
 \item
-\TODO{}
+\fail{}
 Verify that the application correctly enforces context-
 sensitive authorisation so as to not allow unauthorised
 manipulation by means of parameter tampering.
 
-(nope)
+\begin{result}
+No such mechanisms.
+\end{result}
 
 \end{enumerate}