report/v4_access.tex

   1
   2 \noindent
   3 The CMS has the following access control mechanisms:
   4
   5 \begin{itemize}
   6   \item A login mechanism, where logged in users are allowed to access the backend, and anonymous users are not.
   7   \item For logged in users, a role system with three specified roles: admin, editor and regular user.
   8   \item Different users (cap.~diff?)
   9 \end{itemize}
  10
  11 \noindent
  12 Some typical objects of access control, in this case, are:
  13
  14 \begin{itemize}
  15   \item Database records
  16   \item Editing capabilities
  17   \item Role privileges
  18   \item Folders, files, info over these data
  19 \end{itemize}
  20
  21 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.
  22
  23 These are the results of our check:
  24
  25 \begin{enumerate}[label={V4.\arabic*}]
  26
  27 % Access controls:
  28 %   - principle of least privilege?
  29 %   - inter-role/context safety
  30 %   - fail safely?
  31 %   - presentation -- server side
  32 %   - cannot be manipulated
  33 %   - onion layers
  34 %   - safe/working auth in place
  35
  36 \item
  37 \fail{}
  38 Verify that the principle of least privilege exists - users
  39 should only be able to access functions, data files, URLs,
  40 controllers, services, and other resources, for which they
  41 possess specific authorization. This implies protection
  42 against spoofing and elevation of privilege.
  43
  44 \begin{result}
  45 The login system that is in place seems to work, and at least theoretically only allows registered users to access the backend.
  46
  47 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.
  48 \end{result}
  49
  50 \addtocounter{enumi}{2}
  51 \item
  52 \fail{}
  53 Verify that access to sensitive records is protected, such
  54 that only authorized objects or data is accessible to each
  55 user (for example, protect against users tampering with a
  56 parameter to see or alter another user's account).
  57
  58 \begin{result}
  59 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.
  60 \end{result}
  61
  62 \item
  63 \fail{}
  64 Verify that directory browsing is disabled unless
  65 deliberately desired. Additionally, applications should not
  66 allow discovery or disclosure of file or directory metadata,
  67 such as \code{Thumbs.db}, \code{.DS\_Store}, \code{.git} or \code{.svn} folders.
  68
  69 \begin{result}
  70 \begin{itemize}[leftmargin=*]
  71   \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}.
  72   \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.
  73 \end{itemize}
  74 \end{result}
  75
  76 \addtocounter{enumi}{2}
  77 \item
  78 \pass{}
  79 Verify that access controls fail securely.
  80
  81 \begin{result}
  82 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.''
  83 \end{result}
  84
  85 \item
  86 \fail{}
  87 Verify that the same access control rules implied by the
  88 presentation layer are enforced on the server side.
  89
  90 \begin{result}
  91 Fail, because the role and distinct user systems are stubs.
  92 \end{result}
  93
  94 \item
  95 \fail{}
  96 Verify that all user and data attributes and policy
  97 information used by access controls cannot be
  98 manipulated by end users unless specifically authorized.
  99
 100 \begin{result}
 101 This item is the main remaining security concern, as the login form allows SQL
 102 injections that are capable to alter any information stored in the database.
 103 This is described in more detail in item V2.6 on page~\pageref{auth:6}.
 104 \end{result}
 105
 106 \notapplicable{
 107 \item
 108 Verify that there is a centralized mechanism (including
 109 libraries that call external authorization services) for
 110 protecting access to each type of protected resource.
 111 }
 112
 113 \item
 114 \fail{}
 115 Verify that all access control decisions can be logged and
 116 all failed decisions are logged.
 117
 118 \begin{result}
 119 No such decision logging present. There is only a minor amount of logging, and this is related to not finding content (pages and articles).
 120 \end{result}
 121
 122 \item
 123 \fail{}
 124 Verify that the application or framework uses strong
 125 random anti-CSRF tokens or has another transaction
 126 protection mechanism.
 127
 128 \begin{result}
 129 There is no transation protection mechanism at all.
 130 \end{result}
 131
 132 \item
 133 \fail{}
 134 Verify the system can protect against aggregate or
 135 continuous access of secured functions, resources, or
 136 data. For example, consider the use of a resource
 137 governor to limit the number of edits per hour or to
 138 prevent the entire database from being scraped by an
 139 individual user.
 140
 141 \begin{result}
 142 No such prevention present.
 143 \end{result}
 144
 145 \item
 146 \fail{}
 147 Verify the application has additional authorization (such
 148 as step up or adaptive authentication) for lower value
 149 systems, and / or segregation of duties for high value
 150 applications to enforce anti-fraud controls as per the risk
 151 of application and past fraud.
 152
 153 \begin{result}
 154 No such mechanisms.
 155 \end{result}
 156
 157 \item
 158 \fail{}
 159 Verify that the application correctly enforces context-
 160 sensitive authorisation so as to not allow unauthorised
 161 manipulation by means of parameter tampering.
 162
 163 \begin{result}
 164 No such mechanisms.
 165 \end{result}
 166
 167 \end{enumerate}