report/v5_input.tex

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