SoftwareSecurity2014/Group 8/Verdict

ASVS Verification Requirements

This page lists the verification requirements together with our verdict for level 2B of V5: input validation. Please note that we were not able to look through all Wordpress files, as there were too many files. Instead, we prioritized on a specific subset of files and would then trace through the files that were included and the functions that were called. The results of our manual code review can be found on the page Level 2B Code Review. The verdicts on this page are all based on our findings during the manual code review and are therefore brief conclusions based on the level 2B code evaluation . The requirements were assessed in a strict sense.

We started with the following files:

• wp-signup.php
• xmlrpc.php
• wp-login.php
• wp-comments-post.php
• includes/wp-db.php

The initial subselection was based on the knowledge about the Wordpress core and partially on the knowledge that we gained from performing part 1B. Furthermore, we did some basic grepping to find files that contained the $_GET and $_POST variables, which were bound to contain user supplied input.

We didn't look through the parts that contained the main functionality for site administrators, which are mainly within the wp-admin directory, because we found this a less interesting part of the application (although administrators have a lot more input fields to their disposal)

Below is the entire set of files that were traced trough manually:

includes/class-IXR.php
includes/class-wp-xmlrpc-server.php
includes/comment.php
includes/default-filters.php
includes/formatting.php
includes/kses.php
includes/ms-functions.php
includes/pluggable.php
includes/query.php
includes/user.php
includes/wp-db.php
wp-comments-post.php
wp-login.php
wp-signup.php 
xmlrpc.php

V5.1	Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.	Not applicable
V5.2	Verify that a positive validation pattern is defined and applied to all input.	No
V5.3	Verify that all input validation failures result in input rejection or input sanitization.	Yes
V5.4	Verify that a character set, such as UTF-8, is specified for all sources of input.	No
V5.5	Verify that all input validation is performed on the server side.	Yes
V5.6	Verify that a single input validation control is used by the application for each type of data that is accepted.	No
V5.7	Verify that all input validation failures are logged.	No

V5.1 - Verify that the runtime environment is not susceptible to buffer overflows, or that security controls prevent buffer overflows.

All files that we investigated are PHP files. These are executed by a HTTP web server, such as Apache or nginx. Of course it is important to run a safe version (free of buffer overflows and other vulnerabilities) of these web servers, otherwise a website can get compromised easily. Because this actually applies to any PHP website or framework, we decided this verification requirement was actually out of scope for the current assessment, so this requirement will not be verified at the moment.

Something that we'd like to add as a side note however is that the PHP runtime environment can be configured with a default filter, which is really useful for input filtering. This can be done by setting the filter.default to a certain value in php.ini. An example of this is the following: filter.default = full_special_chars. This makes the PHP runtime environment filter all input in the $_GET, $_POST, $_COOKIE, $_REQUEST and $_SERVER variables as if they were passed through htmlspecialchars(). Other options are specified on http://www.php.net/manual/en/filter.filters.sanitize.php and http://www.php.net/manual/en/filter.filters.validate.php. It is of course possible to override the default behavior inside the code again.

V5.2 - Verify that a positive validation pattern is defined and applied to all input.

We conclude that Wordpress 3.8.1 does not apply a positive validation pattern to all its inputs. We thought of input validation in the strictest sense, e.g. when an integer is expected as input, it should actually pass it to a function that checks if it's really an integer, such as passing it to the PHP functions is_int() or is_numeric(). After this check, it can be used as an integer. Wordpress has a function is_email() available that checks if an input conforms to the format of an email address. There is also a function is_string() available that checks whether user input is in the form of a string. These are the only functions that we found during the investigation that follow a real positive input validation pattern. All queries to the database, which are handled by wp-db.php go through the prepare()-function, which will take care of preparing an SQL-statement in a safe way. This is a form of positive input validation, as an SQL-statement functions as a kind of whitelist for the input that is expected.

In general, Wordpress does a lot of input sanitization. We do not consider this input validation.

V5.3 - Verify that all input validation failures result in input rejection or input sanitization.

All the files we checked perform some form of input validation when processing input. In most cases the input is first sanitized to remove invalid characters or forbidden HTML codes. When the input still isn't valid after sanitization, it is rejected in cases like an invalid email address or login name. Input for database queries are escaped before they are used as input to a query to the database, which is of course a measure against SQL injection. Database statements are prepared and will result in a rejection of the input when the input is not valid.

V5.4 - Verify that a character set, such as UTF-8, is specified for all sources of input.

In the files that were considered in the level 2B evaluation, no general character set for input was specified. The character set for output is specified with the UTF-8 character set, but this doesn't seem relevant for the input. The standard configuration for Wordpress is to save input in the UTF-8 encoding in the database. Since no character set checks are applied by the input handling functions either, we conclude that no character set is specified for input sources. Therefore, this security requirement is not met.

V5.5 - Verify that all input validation is performed on the server side.

All of the files that are relevant for input validation, such as wp-db.php, wp-login.php, xmlrpc.php, wp-signup.php and wp-comments-post.php, which we all checked manually, are executed on the server. Therefore, we conclude that the input validation is performed on the server side. There may be some JavaScript in other Wordpress files that have little to do with input validation, but we did not find any JavaScript in the files that were checked manually, so it is safe to say that Wordpress succeeds in verifying all input validation on the server side. Of course we have to add that even the presence of JavaScript based input validation, there is no reason to omit the input validation on the server side. It should merely serve as a user convenience as an attacker could alter the JavaScript on its client machine.

V5.6 - Verify that a single input validation control is used by the application for each type of data that is accepted.

We can conclude that for most user input (about 90%), a single control is used to validate and escape/sanitize the data. This control is the prepare() function in wp-db.php. It is called before user input is used in a SQL query to be executed on the database. In about 10 other cases the esc_sql() and like_escape() functions are used for sanitizing. The esc_sql() calls the _real_escape() function for its arguments and the like_escape() escapes the SQL LIKE special characters % and _. The rest of the user input is sanitized by several filter hooks (using apply_filters()), that validate and escape the user input. Often these filters use the same _real_escape<() function that is also used by the prepare() function.

For other files, this works about the same.

V5.7 - Verify that all input validation failures are logged.

All failures in executing database queries are logged after the queries have been tried to be executed. This is of course the case when input is not valid for usage in a query. For all other inputs that we have checked, it does not seem to be the case that failues are logged. There are functions available that could be used to log to a file, but they don't seem to be used every time they are needed. Of course it is possible to make PHP report on errors it encounters, but this is a runtime configuration option in php.ini. It is part of a the PHP functionality and is not Wordpress specific.