report/v5_input.tex

   1 \begin{enumerate}[label={V5.\arabic*}]
   2         \item\pass{} Verify that the runtime environment is not susceptible to buffer
   3                 overflows, or that security controls prevent buffer overflows.
   4
   5                 \begin{result}
   6                 As of \emph{OWASP}'s statement\footnote{\url{%
   7                         https://www.owasp.org/index.php/Buffer_Overflows\#Platforms_Affected}}
   8                 \PHP{} is not surceptible to buffer overflows as long no external
   9                 programs or extensions are used which is not the case.
  10                 \end{result}
  11
  12         % They skip 5.2
  13         \addtocounter{enumi}{1}
  14         \item\fail{} Verify that server side input validation failures result in
  15                 request rejection and are logged.
  16
  17                 \begin{result}
  18                 \code{filter\_var} is used for input validation and while errors are
  19                 returned to the user, no logging taking place.
  20                 \end{result}
  21
  22         % They skip 5.4
  23         \addtocounter{enumi}{1}
  24         \item\pass{} Verify that input validation routines are enforced on the
  25                 server side.
  26
  27                 \begin{result}
  28                 Errors are accumulated in an array which, when non-empty, will fail the
  29                 function and report the error.
  30                 \end{result}
  31
  32         \notapplicable{\item Verify that a single input validation control is used
  33                 by the application for each type of data that is accepted.}
  34
  35         % They skip 5.7-5.9
  36         \addtocounter{enumi}{3}
  37         \item\fail{} Verify that all \SQL{} queries, \code{HQL}, \code{OSQL},
  38                 \code{NOSQL} and stored procedures, calling of stored procedures are
  39                 protected by the use of prepared statements or query parameterization,
  40                 and thus not susceptible to \SQL{} injection.
  41
  42                 \begin{result}
  43                 This is not the case. For example in \srcref{classes/users.php}{45}.
  44                 However, in some cases prepared statements are used, such as is
  45                 \srcref{classes/users.php}{145}.
  46                 \end{result}
  47
  48         \item\pass{} Verify that the application is not susceptible to \LDAP{}
  49                 Injection, or that security controls prevent \LDAP{} Injection.
  50
  51                 \begin{result}
  52                 \LDAP{} is not used, thus the application is not susceptible.
  53                 \end{result}
  54
  55         \item\pass{} Verify that the application is not susceptible to OS Command
  56                 Injection, or that security controls prevent OS Command Injection.
  57
  58                 \begin{result}
  59                 This requirement heavily depends on the configuration of the \PHP{}
  60                 interpreter and database, there are no system commands used but since
  61                 it is trivial to do an \SQL{} injection it might be possible to run
  62                 commands via the database. However, which a sufficiently secure \SQL{}
  63                 config this can not take place.
  64                 \end{result}
  65
  66         \item\pass{} Verify that the application is not susceptible to Remote File
  67                 Inclusion (RFI) or Local File Inclusion (LFI) when content is used that
  68                 is a path to a file.
  69
  70                 \begin{result}
  71                 Some file inclusion might be possible in the themes. Also in password
  72                 recovery\\
  73                 (\srcref{classes/user.php}{115}) filepaths are calculated on the
  74                 hash of the password. All non standard filepaths, such as admin or
  75                 theme files, are generated using functions. \CMS{} urls are parsed using a
  76                 standard system wide \code{parse} function.
  77                 \end{result}
  78
  79         \item\pass{} Verify that the application is not susceptible to common
  80                 \XML{} attacks, such as XPath query tampering, \XML{} External Entity
  81                 attacks, and \XML{} injection attacks.
  82
  83                 \begin{result}
  84                 No \XML{} or related techniques are used and thus the application is
  85                 not susceptible.
  86                 \end{result}
  87
  88         \item\fail{} Ensure that all string variables placed into \HTML{} or other
  89                 web client code is either properly contextually encoded manually, or
  90                 utilize templates that automatically encode contextually to ensure the
  91                 application is not susceptible to reflected, stored and DOM Cross-Site
  92                 Scripting (\XSS{}) attacks.
  93
  94                 \begin{result}
  95                 A lot of \HTML{} tags are allowed in the post screen, therefore an \XSS{}
  96                 attack is trivial. Even the comment section uses no input validation
  97                 whatsoever.
  98                 \end{result}
  99
 100         \item\pass{} If the application framework allows automatic mass parameter
 101                 assignment (also called automatic variable binding) from the inbound
 102                 request to a model, verify that security sensitive fields such as
 103                 ``accountBalance'', ``role'' or ``password'' are protected from
 104                 malicious automatic binding.
 105
 106                 \begin{result}
 107                 There is some automatic variable binding happening in the \POST{} and \GET{}
 108                 however, defaults are always given and there is no possibility of
 109                 accidentally binding extra variables. Also the variables are in an
 110                 array.
 111                 \end{result}
 112
 113         \item\pass{} Verify that the application has defenses against \HTTP{}
 114                 parameter pollution attacks, particularly if the application framework
 115                 makes no distinction about the source of request parameters (\GET{}, \POST{},
 116                 cookies, headers, environment, etc.)
 117
 118                 \begin{result}
 119                 The system explicitly makes a difference with the different input
 120                 types. As said in the previous item, the function that does this
 121                 parameter parsing is system wide and uses defaults and filters unwanted
 122                 parameters.
 123                 \end{result}
 124
 125         \item\fail{} Verify that client side validation is used as a second line of
 126                 defense, in addition to server side validation.
 127
 128                 \begin{result}
 129                 There is client side validation on comments in the email section. There
 130                 is no validation for the comments itself to check for malafide \HTML{}.
 131                 In the admin panel the email address is not validated.
 132                 \end{result}
 133
 134         \item\fail{} Verify that all input data is validated, not only \HTML{} form
 135                 fields but all sources of input such as \REST{} calls, query parameters,
 136                 \HTTP{} headers, cookies, batch files, \RSS{} feeds, etc; using positive
 137                 validation (whitelisting), then lesser forms of validation such as
 138                 greylisting (eliminating known bad strings), or rejecting bad inputs
 139                 (blacklisting).
 140
 141                 \begin{result}
 142                 \REST{} calls are validated using whitelisting, query parameters are not,
 143                 headers are not, cookies not, batch files are non-existent and RSS feed
 144                 output is not filtered.
 145                 \end{result}
 146
 147         \item\pass{} Verify that structured data is strongly typed and validated
 148                 against a defined schema including allowed characters, length and
 149                 pattern (e.g.\  credit card numbers or telephone, or validating that two
 150                 related fields are reasonable, such as validating suburbs and zip or
 151                 post codes match).
 152
 153                 \begin{result}
 154                 Email addresses are validated against \PHP's stander functionality.
 155                 Note that the \PHP{} email validation is not perfect and some valid
 156                 email addresses are rejected (such as email addresses with non-ASCII
 157                 characters). The other requirements are not used.
 158                 \end{result}
 159
 160         \item\pass{} Verify that unstructured data is sanitized to enforce generic
 161                 safety measures such as allowed characters and length, and characters
 162                 potentially harmful in given context should be escaped (e.g.\ natural
 163                 names with Unicode or apostrophes, such as
 164                 \begin{CJK}{UTF8}{min}ねこ\end{CJK} or O'Hara)
 165
 166                 \begin{result}
 167                 Emailaddresses with non-ASCII characters are rejected. Unicode
 168                 characters are displayed correctly.
 169                 \end{result}
 170
 171         \item\fail{} Make sure untrusted \HTML{} from WYSIWYG editors or similar are
 172                 properly sanitized with an \HTML{} sanitizer and handle it
 173                 appropriately according to the input validation task and encoding task.
 174
 175                 \begin{result}
 176                 This is not the case, any \HTML{} is allowed.
 177                 \end{result}
 178
 179         \item\fail{} For auto-escaping template technology, if UI escaping is disabled,
 180                 ensure that \HTML{} sanitization is enabled instead.
 181
 182                 \begin{result}
 183                 See previous item.
 184                 \end{result}
 185
 186         \item\pass{} Verify that data transferred from one DOM context to another,
 187                 uses safe JavaScript methods, such as using \code{.innerText} and
 188                 \code{.val}.
 189
 190                 \begin{result}
 191                 The \JQuery{} framework is used for this.
 192                 \end{result}
 193
 194         \item\pass{} Verify when parsing \JSON{} in browsers, that
 195                 \code{JSON.parse} is used to parse \JSON{} on the client. Do not use
 196                 \code{eval()} to parse \JSON{} on the client.
 197
 198                 \begin{result}
 199                 There is no \JSON{} transfer outside the toolkits.
 200                 \end{result}
 201
 202         \item\pass{} Verify that authenticated data is cleared from client storage,
 203                 such as the browser DOM, after the session is terminated.
 204
 205                 \begin{result}
 206                 No DOM storage is used.
 207                 \end{result}
 208
 209 \end{enumerate}