returned to the user, no logging taking place.
% They skip 5.4
\addtocounter{enumi}{1}
- \item\pass{} Verify that input validation routines are enforced on the server
- side.
+ \item\pass{} Verify that input validation routines are enforced on the
+ server side.
Errors are accumulated in an array which, when non-empty, will fail the
function and report the error.
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.
+
+ %TODO hier nog even naar kijken
+ \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.
+
+ Some file inclusion might be possible in the themes. Also in password
+ recovery (\srcref{system/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 \texttt{parse} function.
+ \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.
+
+ No \XML{} or related techniques are used and thus the application is
+ not susceptible.
+ \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.
+
+ 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.
+ \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.
+
+ 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.
+ \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.)
+
+ 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.
+ \item\fail{} Verify that client side validation is used as a second line of
+ defense, in addition to server side validation.
+
+ 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.
+ \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).
+
+ 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.
+ \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).
+
+ 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.
+ \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)
+
+ Emailaddresses with non-ASCII characters are rejected. Unicode
+ characters are displayed correctly.
+ \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.
+
+ This is not the case, any \HTML{} is allowed.
+ \item\fail{} For auto-escaping template technology, if UI escaping is disabled,
+ ensure that \HTML{} sanitization is enabled instead.
+
+ See previous item.
+ \item\pass{} Verify that data transferred from one DOM context to another,
+ uses safe JavaScript methods, such as using \texttt{.innerText} and
+ \texttt{.val}.
+
+ The \JQuery{} framework is used for this.
+ \item Verify when parsing \JSON{} in browsers, that \text{JSON.parse} is
+ used to parse \JSON{} on the client. Do not use \texttt{eval()} to
+ parse \JSON{} on the client.
+
+ \item Verify that authenticated data is cleared from client storage, such
+ as the browser DOM, after the session is terminated
\end{enumerate}
repositories / ssproject1617.git / commitdiff