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={4.\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 \pass{}
  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. 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.
 102 \end{result}
 103
 104 \notapplicable{
 105 \item
 106 Verify that there is a centralized mechanism (including
 107 libraries that call external authorization services) for
 108 protecting access to each type of protected resource.
 109 }
 110
 111 \item
 112 \fail{}
 113 Verify that all access control decisions can be logged and
 114 all failed decisions are logged.
 115
 116 \begin{result}
 117 No such decision logging present. There is only a minor amount of logging, and this is related to not finding content (pages and articles).
 118 \end{result}
 119
 120 \item
 121 \fail{}
 122 Verify that the application or framework uses strong
 123 random anti-CSRF tokens or has another transaction
 124 protection mechanism.
 125
 126 \begin{result}
 127 There is no transation protection mechanism at all.
 128 \end{result}
 129
 130 \item
 131 \fail{}
 132 Verify the system can protect against aggregate or
 133 continuous access of secured functions, resources, or
 134 data. For example, consider the use of a resource
 135 governor to limit the number of edits per hour or to
 136 prevent the entire database from being scraped by an
 137 individual user.
 138
 139 \begin{result}
 140 No such prevention present.
 141 \end{result}
 142
 143 \item
 144 \fail{}
 145 Verify the application has additional authorization (such
 146 as step up or adaptive authentication) for lower value
 147 systems, and / or segregation of duties for high value
 148 applications to enforce anti-fraud controls as per the risk
 149 of application and past fraud.
 150
 151 \begin{result}
 152 No such mechanisms.
 153 \end{result}
 154
 155 \item
 156 \fail{}
 157 Verify that the application correctly enforces context-
 158 sensitive authorisation so as to not allow unauthorised
 159 manipulation by means of parameter tampering.
 160
 161 \begin{result}
 162 No such mechanisms.
 163 \end{result}
 164
 165 \end{enumerate}