-\begin{enumerate}[label=5.\arabic*]
- \item Verify that the runtime environment is not susceptible to buffer
+\begin{enumerate}[label={V5.\arabic*}]
+ \item\pass{} Verify that the runtime environment is not susceptible to buffer
overflows, or that security controls prevent buffer overflows.
+ \begin{result}
+ As of \emph{OWASP}'s statement\footnote{\url{%
+ https://www.owasp.org/index.php/Buffer_Overflows\#Platforms_Affected}}
+ \PHP{} is not surceptible to buffer overflows as long no external
+ programs or extensions are used which is not the case.
+ \end{result}
+
% They skip 5.2
\addtocounter{enumi}{1}
- \item Verify that server side input validation failures result in
+ \item\fail{} Verify that server side input validation failures result in
request rejection and are logged.
+ \begin{result}
+ \code{filter\_var} is used for input validation and while errors are
+ returned to the user, no logging taking place.
+ \end{result}
+
% They skip 5.4
\addtocounter{enumi}{1}
- \item Verify that input validation routines are enforced on the server
- side.
+ \item\pass{} Verify that input validation routines are enforced on the
+ server side.
+
+ \begin{result}
+ Errors are accumulated in an array which, when non-empty, will fail the
+ function and report the error.
+ \end{result}
- \item\notapplicable{Verify that a single input validation control is used
+ \notapplicable{\item Verify that a single input validation control is used
by the application for each type of data that is accepted.}
% They skip 5.7-5.9
\addtocounter{enumi}{3}
- \item Verify that all SQL queries, HQL, OSQL, NOSQL and stored
- procedures, calling of stored procedures are protected by the
- use of prepared statements or query parameterization, and
- thus not susceptible to SQL injection.
+ \item\fail{} Verify that all \SQL{} queries, \code{HQL}, \code{OSQL},
+ \code{NOSQL} and stored procedures, calling of stored procedures are
+ protected by the use of prepared statements or query parameterization,
+ and thus not susceptible to \SQL{} injection.
- \item Verify that the application is not susceptible to LDAP
+ \begin{result}
+ This is not the case. For example in \srcref{classes/users.php}{45}.
+ However, in some cases prepared statements are used, such as is
+ \srcref{classes/users.php}{145}.
+ \end{result}
+
+ \item\pass{} Verify that the application is not susceptible to LDAP
Injection, or that security controls prevent LDAP Injection.
- \item Verify that the application is not susceptible to OS Command
+ \begin{result}
+ \LDAP{} is not used, thus the application is not susceptible.
+ \end{result}
+
+ \item\pass{} Verify that the application is not susceptible to OS Command
Injection, or that security controls prevent OS Command Injection.
+
+ \begin{result}
+ This requirement heavily depends on the configuration of the \PHP{}
+ interpreter and database, there are no system commands used but since
+ it is trivial to do an \SQL{} injection it might be possible to run
+ commands via the database. However, which a sufficiently secure \SQL{}
+ config this can not take place.
+ \end{result}
+
+ \item\pass{} Verify that the application is not susceptible to Remote File
+ Inclusion (RFI) or Local File Inclusion (LFI) when content is used that
+ is a path to a file.
+
+ \begin{result}
+ Some file inclusion might be possible in the themes. Also in password
+ recovery\\
+ (\srcref{classes/user.php}{115}) filepaths are calculated on the
+ hash of the password. All non standard filepaths, such as admin or
+ theme files, are generated using functions. CMS urls are parsed using a
+ standard system wide \code{parse} function.
+ \end{result}
+
+ \item\pass{} Verify that the application is not susceptible to common
+ \XML{} attacks, such as XPath query tampering, \XML{} External Entity
+ attacks, and \XML{} injection attacks.
+
+ \begin{result}
+ No \XML{} or related techniques are used and thus the application is
+ not susceptible.
+ \end{result}
+
+ \item\fail{} Ensure that all string variables placed into \HTML{} or other
+ web client code is either properly contextually encoded manually, or
+ utilize templates that automatically encode contextually to ensure the
+ application is not susceptible to reflected, stored and DOM Cross-Site
+ Scripting (XSS) attacks.
+
+ \begin{result}
+ A lot of \HTML{} tags are allowed in the post screen, therefore an XSS
+ attack is trivial. Even the comment section uses no input validation
+ whatsoever.
+ \end{result}
+
+ \item\pass{} If the application framework allows automatic mass parameter
+ assignment (also called automatic variable binding) from the inbound
+ request to a model, verify that security sensitive fields such as
+ ``accountBalance'', ``role'' or ``password'' are protected from
+ malicious automatic binding.
+
+ \begin{result}
+ There is some automatic variable binding happening in the POST and GET
+ however, defaults are always given and there is no possibility of
+ accidentally binding extra variables. Also the variables are in an
+ array.
+ \end{result}
+
+ \item\pass{} Verify that the application has defenses against HTTP
+ parameter pollution attacks, particularly if the application framework
+ makes no distinction about the source of request parameters (GET, POST,
+ cookies, headers, environment, etc.)
+
+ \begin{result}
+ The system explicitly makes a difference with the different input
+ types. As said in the previous item, the function that does this
+ parameter parsing is system wide and uses defaults and filters unwanted
+ parameters.
+ \end{result}
+
+ \item\fail{} Verify that client side validation is used as a second line of
+ defense, in addition to server side validation.
+
+ \begin{result}
+ There is client side validation on comments in the email section. There
+ is no validation for the comments itself to check for malafide \HTML{}.
+ In the admin panel the email address is not validated.
+ \end{result}
+
+ \item\fail{} Verify that all input data is validated, not only \HTML{} form
+ fields but all sources of input such as REST calls, query parameters,
+ HTTP headers, cookies, batch files, RSS feeds, etc; using positive
+ validation (whitelisting), then lesser forms of validation such as
+ greylisting (eliminating known bad strings), or rejecting bad inputs
+ (blacklisting).
+
+ \begin{result}
+ REST calls are validated using whitelisting, query parameters are not,
+ headers are not, cookies not, batch files are non-existent and RSS feed
+ output is not filtered.
+ \end{result}
+
+ \item\pass{} Verify that structured data is strongly typed and validated
+ against a defined schema including allowed characters, length and
+ pattern (e.g.\ credit card numbers or telephone, or validating that two
+ related fields are reasonable, such as validating suburbs and zip or
+ post codes match).
+
+ \begin{result}
+ Email addresses are validated against \PHP's stander functionality.
+ Note that the \PHP{} email validation is not perfect and some valid
+ email addresses are rejected (such as email addresses with non-ASCII
+ characters). The other requirements are not used.
+ \end{result}
+
+ \item\pass{} Verify that unstructured data is sanitized to enforce generic
+ safety measures such as allowed characters and length, and characters
+ potentially harmful in given context should be escaped (e.g.\ natural
+ names with Unicode or apostrophes, such as
+ \begin{CJK}{UTF8}{min}ねこ\end{CJK} or O'Hara)
+
+ \begin{result}
+ Emailaddresses with non-ASCII characters are rejected. Unicode
+ characters are displayed correctly.
+ \end{result}
+
+ \item\fail{} Make sure untrusted \HTML{} from WYSIWYG editors or similar are
+ properly sanitized with an \HTML{} sanitizer and handle it
+ appropriately according to the input validation task and encoding task.
+
+ \begin{result}
+ This is not the case, any \HTML{} is allowed.
+ \end{result}
+
+ \item\fail{} For auto-escaping template technology, if UI escaping is disabled,
+ ensure that \HTML{} sanitization is enabled instead.
+
+ \begin{result}
+ See previous item.
+ \end{result}
+
+ \item\pass{} Verify that data transferred from one DOM context to another,
+ uses safe JavaScript methods, such as using \code{.innerText} and
+ \code{.val}.
+
+ \begin{result}
+ The \JQuery{} framework is used for this.
+ \end{result}
+
+ \item\pass{} Verify when parsing \JSON{} in browsers, that
+ \code{JSON.parse} is used to parse \JSON{} on the client. Do not use
+ \code{eval()} to parse \JSON{} on the client.
+
+ \begin{result}
+ There is no \JSON{} transfer outside the toolkits.
+ \end{result}
+
+ \item\pass{} Verify that authenticated data is cleared from client storage,
+ such as the browser DOM, after the session is terminated.
+
+ \begin{result}
+ No DOM storage is used.
+ \end{result}
+
\end{enumerate}
repositories / ssproject1617.git / blobdiff