overflows, or that security controls prevent buffer overflows.
\begin{result}
- As of \emph{OWASP}'s statement\footnote{\url{%
+ As of 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
+ \PHP{} is not susceptible 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\fail{} 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}
\addtocounter{enumi}{3}
\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,
+ protected by the use of prepared statements or query parametrization,
and thus not susceptible to \SQL{} 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.
+ commands via the database. However, with a sufficiently secure \SQL{}
+ configuration this can not take place.
\end{result}
\item\pass{} Verify that the application is not susceptible to Remote File
\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.
+ attacks, and \XML{} injection attacks.
\begin{result}
No \XML{} or related techniques are used and thus the application is
\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
+ validation (white-listing), then lesser forms of validation such as
greylisting (eliminating known bad strings), or rejecting bad inputs
(blacklisting).
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).
+ post codes match).
\begin{result}
- Email addresses are validated against \PHP's stander functionality.
+ Email addresses are validated against \PHP's standard 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.
\begin{CJK}{UTF8}{min}ねこ\end{CJK} or O'Hara)
\begin{result}
- Emailaddresses with non-ASCII characters are rejected. Unicode
+ Email addresses 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.
+ appropriately according to the input validation task and encoding task.
\begin{result}
This is not the case, any \HTML{} is allowed.
ensure that \HTML{} sanitization is enabled instead.
\begin{result}
- See previous item.
+ Just as with the previous item, any \HTML{} is allowed.
\end{result}
\item\pass{} Verify that data transferred from one DOM context to another,
repositories / ssproject1617.git / blobdiff