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.
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.
13 \addtocounter{enumi
}{1}
14 \item\fail{} Verify that server side input validation failures result in
15 request rejection and are logged.
18 \code{filter
\_var} is used for input validation and while errors are
19 returned to the user, no logging taking place.
23 \addtocounter{enumi
}{1}
24 \item\pass{} Verify that input validation routines are enforced on the
28 Errors are accumulated in an array which, when non-empty, will fail the
29 function and
report the error.
32 \notapplicable{\item Verify that a single input validation control is used
33 by the application for each type of data that is accepted.
}
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.
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}.
48 \item\pass{} Verify that the application is not susceptible to LDAP
49 Injection, or that security controls prevent LDAP Injection.
52 \LDAP{} is not used, thus the application is not susceptible.
55 \item\pass{} Verify that the application is not susceptible to OS Command
56 Injection, or that security controls prevent OS Command Injection.
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.
66 %TODO hier nog even naar kijken
67 \item\pass{} Verify that the application is not susceptible to Remote File
68 Inclusion (RFI) or Local File Inclusion (LFI) when content is used that
72 Some file inclusion might be possible in the themes. Also in password
74 (
\srcref{classes/user.php
}{115}) filepaths are calculated on the
75 hash of the password. All non standard filepaths, such as admin or
76 theme files, are generated using functions. CMS urls are parsed using a
77 standard system wide
\code{parse
} function.
80 \item\pass{} Verify that the application is not susceptible to common
81 \XML{} attacks, such as XPath query tampering,
\XML{} External Entity
82 attacks, and
\XML{} injection attacks.
85 No
\XML{} or related techniques are used and thus the application is
89 \item\fail{} Ensure that all string variables placed into
\HTML{} or other
90 web client code is either properly contextually encoded manually, or
91 utilize templates that automatically encode contextually to ensure the
92 application is not susceptible to reflected, stored and DOM Cross-Site
93 Scripting (XSS) attacks.
96 A lot of
\HTML{} tags are allowed in the post screen, therefore an XSS
97 attack is trivial. Even the comment section uses no input validation
101 \item\pass{} If the application framework allows automatic mass parameter
102 assignment (also called automatic variable binding) from the inbound
103 request to a model, verify that security sensitive fields such as
104 ``accountBalance'', ``role'' or ``password'' are protected from
105 malicious automatic binding.
108 There is some automatic variable binding happening in the POST and GET
109 however, defaults are always given and there is no possibility of
110 accidentally binding extra variables. Also the variables are in an
114 \item\pass{} Verify that the application has defenses against HTTP
115 parameter pollution attacks, particularly if the application framework
116 makes no distinction about the source of request parameters (GET, POST,
117 cookies, headers, environment, etc.)
120 The system explicitly makes a difference with the different input
121 types. As said in the previous item, the function that does this
122 parameter parsing is system wide and uses defaults and filters unwanted
126 \item\fail{} Verify that client side validation is used as a second line of
127 defense, in addition to server side validation.
130 There is client side validation on comments in the email section. There
131 is no validation for the comments itself to check for malafide
\HTML{}.
132 In the admin panel the email address is not validated.
135 \item\fail{} Verify that all input data is validated, not only
\HTML{} form
136 fields but all sources of input such as REST calls, query parameters,
137 HTTP headers, cookies, batch files, RSS feeds, etc; using positive
138 validation (whitelisting), then lesser forms of validation such as
139 greylisting (eliminating known bad strings), or rejecting bad inputs
143 REST calls are validated using whitelisting, query parameters are not,
144 headers are not, cookies not, batch files are non-existent and RSS feed
145 output is not filtered.
148 \item\pass{} Verify that structured data is strongly typed and validated
149 against a defined schema including allowed characters, length and
150 pattern (e.g.\ credit card numbers or telephone, or validating that two
151 related fields are reasonable, such as validating suburbs and zip or
155 Email addresses are validated against
\PHP's stander functionality.
156 Note that the
\PHP{} email validation is not perfect and some valid
157 email addresses are rejected (such as email addresses with non-ASCII
158 characters). The other requirements are not used.
161 \item\pass{} Verify that unstructured data is sanitized to enforce generic
162 safety measures such as allowed characters and length, and characters
163 potentially harmful in given context should be escaped (e.g.\ natural
164 names with Unicode or apostrophes, such as
165 \begin{CJK
}{UTF8
}{min
}ねこ
\end{CJK
} or O'Hara)
168 Emailaddresses with non-ASCII characters are rejected. Unicode
169 characters are displayed correctly.
172 \item\fail{} Make sure untrusted
\HTML{} from WYSIWYG editors or similar are
173 properly sanitized with an
\HTML{} sanitizer and handle it
174 appropriately according to the input validation task and encoding task.
177 This is not the case, any
\HTML{} is allowed.
180 \item\fail{} For auto-escaping template technology, if UI escaping is disabled,
181 ensure that
\HTML{} sanitization is enabled instead.
187 \item\pass{} Verify that data transferred from one DOM context to another,
188 uses safe JavaScript methods, such as using
\code{.innerText
} and
192 The
\JQuery{} framework is used for this.
195 \item\pass{} Verify when parsing
\JSON{} in browsers, that
196 \code{JSON.parse
} is used to parse
\JSON{} on the client. Do not use
197 \code{eval()
} to parse
\JSON{} on the client.
200 There is no
\JSON{} transfer outside the toolkits.
203 \item\pass{} Verify that authenticated data is cleared from client storage,
204 such as the browser DOM, after the session is terminated.
207 No DOM storage is used.