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}
\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}
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}
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.
repositories / ssproject1617.git / blobdiff