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}
\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\pass{} Verify that the application is not susceptible to \LDAP{}
+ Injection, or that security controls prevent \LDAP{} Injection.
\begin{result}
\LDAP{} is not used, thus the application is not susceptible.
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
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
+ 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.
+ attacks, and \XML{} injection attacks.
\begin{result}
No \XML{} or related techniques are used and thus the application is
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.
+ Scripting (\XSS{}) attacks.
\begin{result}
- A lot of \HTML{} tags are allowed in the post screen, therefore an XSS
+ 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}
malicious automatic binding.
\begin{result}
- There is some automatic variable binding happening in the POST and GET
+ 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
+ \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,
+ makes no distinction about the source of request parameters (\GET{}, \POST{},
cookies, headers, environment, etc.)
\begin{result}
\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
+ fields but all sources of input such as \REST{} calls, query parameters,
+ \HTTP{} headers, cookies, batch files, \RSS{} feeds, etc; using positive
+ validation (white-listing), 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,
+ \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}
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