% 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}
\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.
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
+ 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,
+ \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.
\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