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