SoftwareSecurity2014/Group 6/Verdict

Uit Werkplaats
< SoftwareSecurity2014‎ | Group 6
Versie door Erik Poll (overleg | bijdragen) op 29 jun 2014 om 15:26 (V9.1 Verify that all forms containing sensitive information have disabled client side caching, including autocomplete features.)
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Ga naar: navigatie, zoeken

Inhoud

Overview of Roundcube

Classes-simple.png

Mvc diagram.png

General security measures

CSRF prevention

In index.php starting from line 236 there is a block of code that is dedicated to preventing CSRF. There is a whitelist for the login, spell and spell_html actions, for which the CSRF prevention check is not executed. For every other request the authenticity of the user is verified by checking whether the request contains certain parameter values that can only be known to a user that intentionally created the request, i.e. a valid user request and not a forged one. For AJAX calls, the X-Roundcube-Request header parameter value is checked against a token that is only known to the valid client. For non-AJAX calls, POST requests are similarly secured against CSRF, by comparing the input value from the _token field against the aforementioned request token.

For the validation checks the token which is compared against is retrieved with get_request_token() and is constructed by calculating the md5-hash of the concatenation of the string 'RT', the user ID, a DES-key from the configuration file and the session ID. Since the session ID should only be known to the valid user and the DES-key provides additional security, at least when this key has been changed to a different value than the default value in the configuration file, we conclude that this validation check is indeed effective for preventing CSRF attacks. The alter_form_tag() function in program/include/rcmail_output_html.php is the function that generates the _token input field. This function is called on the output of the parse() function, which is located in the same file. The parse() function parses a specific skin template and deliver to stdout (or return). From a quick inspection it seems that all output goes through this function, although it is unclear whether this is forced. (Erik:Nice approach and analysis. Not really related to V4, though, as I would see it.)

Verification requirements

V4 - Access Control Verification Requirements

The Access Control Verification Requirements define how an application can safely enforce access control. In most applications, access control must be performed in multiple different locations across the various application layers. These requirements define verification requirements for access controls for URLs, business functions, data, services, and files. (Erik: Fine and detailed analysis!)

V4.1 - Verify that users can only access protected functions for which they possess specific authorization.

Our interpretation of this requirement is that the 'pprotected functions' refer to functions such as an Administrative panel. In the case of Roundcube, these functions are not available (refer to V4.2) and therefore we omit this requirement from our analysis.

V4.2 - Verify that users can only access URLs for which they possess specific authorization.

In order to verify this requirement we followed the guidelines from the "OWASP Testing Guide v4: Testing for Bypassing Authorization Schema" (OWASP-AZ-002) [1]. This testing scheme specifies that for the different roles that a user is able to possess in an application (with respect to authorization), the different requests that are executed and functions that are called after the user has authenticated should be checked for the following properties:

Can the resource be accessed even if the user is not authenticated?

Is it possible to access these functions and resources with another user that holds a different (subordinate) role or privilege?

The testing scheme also prescribes that the different actions that can be performed with the administrative user should be checked on certain properties that relate to unauthorized use. For Roundcube these do not apply at this time, because there is no administrative user/interface in this application (The "Admin interface" feature is part of the "Planned features" as described on the official website of Roundcube [2].

Roundcube does have a regular login functionality. The login handling, as well as every other request, is performed in index.php. Users that have not yet logged in are only able to perform the login or logout action. Whether or not a user is currently logged in is checked by evaluating the value of the $RCMAIL->user->ID property. When this property has not been set, the login page is shown. The only locations where this property is set is after a successful login and on each page request to index.php. In the latter case an instance of the rcmail class is created and subsequently the startup() function is called, which sets the ID property of a new instance of user to the value of $_SESSION['user_id'], which is only set on successful login. The user instance is also linked to the rcmail instance in this function. Since the login action is also handled in the index.php file, only those requests that go through this file will set $RCMAIL->user->ID. We observed that the separate pages (those besides index.php) do not include authorization checks with respect to whether the user is logged in. Therefore we will only have to make sure that these separate pages can not be accessed directly in a request (such as accessing program/steps/mail/sendmail.inc via the browser). After inspection we noted that the .htaccess file in the root folder is supposed to prevent this direct form of access. This file is generated by default after installation [3], including the regular expressions to strip out the applicable directories from the URL. Since the .htaccess file is not compatible with all web servers, in case of a nonsupporting web server such as Nginx, the system administrator is responsible for taking care of this configuration. But also for a supporting webserver, such as Apache, there is a possibility to configure the web server to ignore .htaccess files. Therefore the system administrator should always make sure that this functionality is indeed working effectively.

We conclude that as long as $_SESSION['user_id'] can not be altered and the system administrator makes sure that the rules in the default .htaccess file of Roundcube are working effectively (through enabling .htaccess overriding in the web server or translating the rules to include them in the configuration of a nonsupporting server), all pages that should only be accessible to logged in users can not be accessed when the user has not logged in. We have no indication that the first property does not hold. The second property depends on the experience of the system administrator, so this may cause setups to be vulnerable in the wild. Because it is noted in the official installation guide that the applicable directories/files should be protected against direct access, there will probably not be many setups that are vulnerable due to this property [4]. Therefore our verdict is that this requirement is probably met for Roundcube, but this may variate per setup depending on the installation procedure that is performed.

V4.3 - Verify that users can only access data files for which they possess specific authorization.

In order to verify this requirement we followed the guidelines from the "OWASP Testing Guide v4: Testing for Path Traversal" (OWASP-AZ-001) [5]. This testing scheme specifies that the application should be checked for possibilities to read or write files that are not intended to be accessible. This generally applies to files that are outside of the web server's root directory, such as /etc/passwd on a UNIX system, which may be accessed through directory traversal attacks in vulnerable applications. For the static code analysis we make use of checking the following properties:

Are there request parameters which could be used for file-related operations?

Is it possible to identify cookies used by the web application for the dynamic generation of pages or templates?

For analyzing the first property we searched for file includes in the code and whether the parameter that is passed to PHP's include and require functions contain unsanitized input. A search for occurrences of both these functions in all of the project's PHP files resulted in several matches in the /program directory and also a few matches in index.php. After analyzing the occurrences in the program directory we concluded that all parameters that represented the files to be included did not contain user input. In the index.php file however, there is the following block of code:

if (is_file($incfile = INSTALL_PATH . 'program/steps/'.$RCMAIL->task.'/func.inc')) {
    include_once $incfile;
}

$RCMAIL represents an instance of the rcmail class, which is created in index.php at the beginning of the file. The task property of this instance is set immediately after creating the instance, with a call to the startup() method of that class. The task property is set with the following line of code:

$this->set_task(rcube_utils::get_input_value('_task', rcube_utils::INPUT_GPC));

The parameter rcube_utils::INPUT_GPC that is passed to rcube_utils::get_input_value specifies that for the $_GET, $_POST as well as the $_COOKIE request variables it is checked whether the variable contains the property '_task' and if so, the corresponding value is returned without sanitization that would prevent directory traversal. However, the set_task() method, which eventually sets the task property for the rcmail instance, sanitizes the value with the asciiwords() function that is defined in the application. This function strips all characters off the string that do not match a-z, 0-9, "_" or "-". It is not possible to execute a directory traversal attack by using only these characters, so we conclude that this code block is safe from this kind of attacks.

The final file include that may be of interest in index.php is the following:

else if (($stepfile = $RCMAIL->get_action_file())
        && is_file($incfile = INSTALL_PATH . 'program/steps/'.$RCMAIL->task.'/'.$stepfile)
    ) {
        // include action file only once (in case it don't exit)
        include_once $incfile;
        ...
}

In this case the $RCMAIL->get_action_file() returns a string containing $RCMAIL->action, which has a value that is constructed by means of user input. However, further inspection reveals that this value is sanitized in the same way as the value of $RCMAIL->task, namely with the asciiwords() function that was described before.

We conclude that from the code analysis we did not get any indication that the application is vulnerable to path traversal attacks and therefore Roundcube meets this requirement.

V4.4 - Verify that direct object references are protected, such that only authorized objects are accessible to each user.

For the interpretation of this requirement we looked at the documentation on the OWASP Top 10 Vulnerability list of 2010, which contains an entry for "Insecure Direct Object References" [6]. The description from OWASP states that it may be harmful to allow a user to provide input values that are directly linked to objects, such as a database key as an <option> value in a <select> menu. OWASP states that it would be better to have a mapping of such object references on the server side and provide only meanlingless indirect references to the client. In the example of the <select> menu, the values for the <option> child elements could be numbered 1 to n, instead of the database keys. The mapping could be stored in a session or in the database and this mapping should include only the references to those objects which the user is authorized to access. If there still exist direct object references, they should be protected with strict access checks.

Roundcube uses direct object references in general, so proper access checks have to be performed after a request to such an object. An example is the edit action in the addressbook step. Here the database ID of the contact is passed in the URL as the value of the cid parameter. For the requests for showing, modifying or removing a contact an access check query will be executed before the action is performed. This query retrieves the contact ID from the database, but also filters on the user ID of the user that is currently logged in. If no match is found, the action is aborted. This prevents unauthorized users from executing these actions. This access checking policy is not centralized and therefore prone to error of a developer when new functionalities are added. It would be better to construct a data mapper based on only the authorized objects beforehand, as described earlier as a prevention of the misuse of direct object references. This would take more time to implement, but enfore a stricter policy for the developer with respect to this kind of access checks.

Apart from the above example the other actions that we investigated also made use of direct object references and the same kind of access checks (checking whether there are matching rows that are linked to the user that is currently logged in). We could not find any vulnerability related to direct object references in the application. Our final verdict is that Roundcube meets this requirement,

V4.6 - Verify that users can only access services for which they possess specific authorization.

We interpret this requirement as being related to securing the inter-communication between the web services that are part of the application's infrastructure. This may be, for example, an API that the the application exposes to the public, which may be used for applications created by a developer community. It may well be that some parts of the API are only available to paid subscribers and therefore this data has to be secured against unauthorized access. Refer to the OWASP documentation on the definition and security of web services for more information on this [7].

Because these services are not part of Roundcube, we omit the analysis of this requirement from our evaluation.

V4.7 - Verify that users can only access data for which they possess specific authorization.

The term "data" can be interpreted in different ways. The first aspect we will look at is the protection of the database, at which we look for possibilities for SQL injection. (Erik: I wouldn't consider SQL injection issues to be part of V4. I agree that V4.6 and 4.7 are pretty vague. I'd interpret them as saying that the web app implements all the access control speficially needed for this web application. This is of course very much dependent on the functionality it provides (eg if there are address books, can user X see user Y's addressbook), something that you consider as part of V4.9. The border between 4.6/7 and 4.9 is also a bit vague in my opinion.)

SQL injection

It is already stated in our analysis of V4.10 that the application makes use of PDO. There is a centralized database class roundcube_db, which contains the methods for interaction with the database. This centralized structure is a good thing, because it stimulates the developer to use this class for all database operations and sanitization will then always be performed when this feature has been implemented inside the methods of the database class. For Roundcube this sanitization has indeed been implemented, but it is important to note that instead of using prepared statements, the parameters are sanitized with the PDO::quote() method and the table names are sanitized with a custom function. An example is in the rcube_db::insert() method:

foreach ($save_data as $col => $value) {
    $a_insert_cols[]   = $this->db->quote_identifier($col);
    $a_insert_values[] = $this->db->quote($value);
}

The $save_data is a parameter that is passed to the rcube_db::insert() method, and as you can see the values are passed to $this->db->quote(), which sanitizes the value with PDO's quote() function. While the value is now safe to include in a query, it is still recommended to use prepared statements, because sometimes values may be overlooked. In this case, for the insert() function we described, there are a few parameters that are put into the query string without going through this loop. Although this particular value, which is $this->user_id, is sanitized with PHP's intval() function, this policy is not enforced and when the database class is extended the developer may easily make a mistake here, such that some parameters may not be sanitized in the end.

The most interesting part may even be the way in which column identifiers are sanitized. This is done with a custom function in the roundcube_db class, called quote_identifier(). This function strips all double quotes from the value and puts double quotes around the value. Although we did not test this possible vulnerability and we could not find any column names that were constructed from user input, this still may pose a threat to the database. Sanitizing column names should best be done with a whitelist approach.


Sensitive PHP functions

Another possible interpretation of unauthorized access to "data" can be that an attacker has the ability to view/modify/remove data on the server itself (possibly outside of the web document root). A possible entry point to the server are some PHP functions that we here categorize as being "sensitive". Calls to these functions are often referred to as "Sinks", as in RIPS and RATS. We have obtained an unofficial list of a large part of these functions, many of which are not included in the Roundcube source code or have only a few entries with only static input paramters, but some of them are more interesting [8]. Our analysis is below.


Command execution:

(shell_)exec() There are several calls to exec(), some of which do not contain user input, but some of them do. On example is the following:

@exec("nslookup -type=MX " . escapeshellarg($domain_part) . " 2>&1", $lookup);

It is located in the check_email() function of the rcube_utils class and one instance where it is called is when a user adds a new contact to his/her address book. In that case the provided email address will be passed to that function. The $domain_part that is part of the parameter that is passed to exec() is retrieved from the email address. It is sanitized beforehand as a valid domain name and finally it goes through the escapeshellarg() function of PHP. This function escapes all quotes and puts quotes around the string, so that it can safely be used as an argument for a shell command [9]. The other exec() calls that are in the application are structured the same way: parameters are escaped with escapeshellarg(). We therefore consider the exec() calls as being safe from tampering. The same counts for the calls to shell_exec().


PHP Code Execution:

create_function() One possibly sensitive sink is in rcube_ldap::add_autovalues ():

// replace {attr} placeholders with (escaped!) attribute values to be safely eval'd
$code = preg_replace('/\{\w+\}/', '', strtr($templ, array_map('addslashes', $attrvals)));
$fn   = create_function('', "return ($code);");

Attribute values are presumably being made safe with addslashes(), but is is unclear whether this prevents an attacker from inserting arbitrary PHP code (without the need for the few characters that are escaped by addslashes()). The $attrvals come from the input to the containing function and are not sanitized. The only instance where this function is called is in the insert() function in rcube_ldap.php, again with unsanitized input. Subsequently this function is called when adding contacts with the ldap setting enabled in the Roundcube configuration. We did not test this further, but a dynamic analysis may possibly identify a threat here.


Filesystem Functions:

We found several occurrences of fopen(), readfile() and file_get_contents(), but we could not identify any user input reaching these sensitive sinks. There also are a few calls to copy(), which may pose a threat when allow_url_fopen is set to On in php.ini; in that case a url can be used as a file path, so a call to copy($_GET['s'], $_GET['d']); can be used to upload a PHP script anywhere on the system. However, no user input is passed to this function.


Concluding:

From a security perspective it may be better to create custom callers for the sensitive PHP functions. For (shell_)exec this has indeed been done in Roundcube with the rcube::exec() function, which constructs a shell command and by default sanitizes all parameters with escapeshellarg(). However, separate exec() calls are still scattered around the application and the developer has the responsibility to properly escape the arguments. Having a custom wrapper eliminates this threat and it is important to try to enforce this to the developer (one way may be to override the sensitive PHP functions from the default PHP library).

From our analysis we don't know for sure whether Roundcube completely meets the verification requirement, but a lot of work has been done to prevent exploits related to the requirement.

V4.8 Verify that access controls fail securely.

As described in V4.9 the main access controls depend on session cookies to authenticate a user and give a user authorization to access their specific data. The session cookies are comprised of a session ID and a session authentication token. The latter is the concatenation of the character 'S' with a SHA1 or MD5 hash of the concatenation of the session ID, a DES key and a maximum life time value (rcube_session.php:782). The session authentication token is checked at every request, except for login and logout requests. If the session authentication token has been tampered with, the request is denied, the session is terminated, and the user is logged out (index.php:192).

Another access control mechanism is the _token field in POST requests, as described in the General security measures section. On every POST request the token is checked. If the check fails an error message is displayed and the request is denied.

Thus, we conclude that Roundcube's access controls fail securely.

V4.9 Verify that the same access control rules implied by the presentation layer are enforced on the server side.

The presentation layer of Roundcube consists of the website shown in the user's browser. It offers typical mail user agent functionality, such as reading e-mails, composing new e-mails, organizing e-mails and providing a list of all e-mails. In addition, Roundcube provides an address book, and also allows the user to specify several identities, which are e-mail addresses with which the user may send e-mails from. Further, Roundcube offers various settings to, for example, configure the view or the default configuration for composing e-mails.

The access control rules implied by the presentation layer are therefore the inability for users to gain access to the e-mails, address book, identities and further settings of other users. Users may only access their personal data.

In its default configuration Roundcube itself does not have user accounts. It tries to authenticate to the given IMAP server with the given credentials. If successful, the user is logged in to Roundcube. To nevertheless be able to store settings, address books and identities, Roundcube uses a database. The tuple (username, hostname) is used as a key.

By default a Roundcube installation does not store any information about e-mails on the server. Every request regarding reading, listing and organizing e-mails is sent to the IMAP server. For that Roundcube stores the password encrypted with 3DES in the PHP session variable $_SESSION['password'] and not in the database. The encrypted password never leaves the server.

Roundcube uses session cookies to distinguish between logged in users and therefore to control their access permissions. The session cookies are linked to a (user name, host name) pair in the database and Roundcube only returns data linked to the respective pair. To mitigate session stealing, the session cookies contain an encrypted life time value that expresses how long the session cookies are valid, and which is checked at every request except for login and logout (index.php:192). By default this value is set to ten minutes. This means that if an attacker is able to steal the session cookie from a victim, but is not able to use the cookie within the configured life time, the attacker has not gained anything.

We therefore conclude that Roundcube does enforce the access control rules implied by the presentation layer.

V4.10 Verify that all user and data attributes and policy information used by access controls cannot be manipulated by end users unless specifically authorized.

All policy information is stored in a configuration file on the server (config.inc.php), which is never accessible by any user. To be able to edit this file an administrator needs shell access to the server and additionally needs the permissions required by the underlying operating system.

User and data attributes used by access controls are comprised of the session cookies, as described in V4.9, and the _token field, as described in the General security measures section. Although a user is able to change these values, the server side of Roundcube checks these values on every request and if they were manipulated, the request is denied.

Thus, we conclude that user and data attributes and policy information used by access controls cannot be effectively manipulated by end users.

However, this analysis suggests two main attack vectors: cross-site scripting attacks (XSS) and variations thereof (e.g. cross-site request forgery (CSRF)), and SQL injection attacks.

SQL injection

Roundcube does not use prepared statements. It mainly uses PHP's PDO::quote function. The PHP manual itself and the OWASP SQL Injection Prevention Cheat Sheet warn that this method is not as fail-safe as using prepared statements. Thus, there might be a possibility for an SQL injection, especially by using the username field when logging in.

Other fields are additionally checked, e.g. when adding an identity, the e-mail address is checked to be a valid e-mail address using code from PEAR's Validation class.

Cross-Site scripting

Roundcube uses PHP's strip_tags function to strip HTML tags from GET and POST values. However, this alone does not protect against XSS attacks, for example it is also possible to insert javascript without using tags, e.g. through CSS.

E-mails are sanitized with WasHTML by Frederic Motte. In the authors own words "Wahstml take an untrusted HTML and return a safe html string" (rcube_washhtml.php:49). It, for example, filters out javascript: and only allows specific tags, with specific attributes and specific inline styles.

For POST requests CSRF is prevented as explained in the General security measures section.

V4.11 Verify that all access controls are enforced on the server side.

As described in V4.9 the implied access control rules by the presentation layer are enforced on the server side. These implied rules are an exact overlap with the actual access controls. Though Roundcube does some preliminary checking in the browser, for example whether an identity contains a valid e-mail address, these checks are also done on the server and therefore also enforced on the server side.

Thus, we conclude that Roundcube does enforce all access controls on the server side.

V4.12 Verify that there is a centralized mechanism (including libraries that call external authorization services) for protecting access to each type of protected resource.

There are a number of protected resources to consider:

Directories/files of the roundcube installation

Like every web application, roundcube has files that need to be protected from leaking outside the web server. In the case of roundcube this includes especially the folders /config, /temp and /logs that are located in the roundcube installation directory which needs to be accessible by the web server. However, the named folders must not be served to the outside by the web server. This is a matter of web server configuration and needs to be taken care of by the administrator. It is clearly documented in the roundcube installation manual.

PGP / S/MIME keys handled by the enigma plugin

Roundcube seems to provide server side mail encryption functionalities via the enigma plugin. The code is included in the downloaded roundcube package. However, the website states that the enigma plugin has never been finished. We also couldn't find a way how to enable it. Therefore, we omitted this part from our audit.

User passwords

Passwords for mail servers seem not to be stored in roundcube in the default installation (since roundcube pretty much acts only as IMAP client). However, there are several plugins that handle password changing. There are drivers available for changing passwords. The most common approach is to use the underlying operating system's functionalities or services like LDAP. Access to passwords is therefore handled by these mechanisms and our review did not reveal any obvious flaws. This part was also examined in the level 1B verification, already.

User data in the database

Database connection is handled by a generic interface class and database-dependent driver classes. Access to specific data is restricted by the access control checks as described in V4.14. It occurs, that roundcube is not using prepared SQL statements (which is considered to be more secure, as it ensures that most SQL injection attacks don't work). This might be due to the generic interface. However, data passed to the database is escaped by the quote_identifier function (in rcube_db.php:735) and quote function (in rcube_db.php:652).

V4.13 Verify that limitations on input and access imposed by the business on the application (such as daily transaction limits or sequencing of tasks) cannot be bypassed.

Existing limitations:

Restricting Sender Identities

Roundcube offers the configuration option to restrict the user from editing some identity information for outgoing mails. However, the detailed enforcement of this is left to the mail transfer agent. The following part from the roundcube manual states the possible options for restricting sender identities.

As with almost any other email client, Roundcube users are free to set any number of sender identities for outgoing mail. This also includes 
to set an arbitrary email as sender address. A proper SMTP sending policy should prevent people from sending emails with other From: addresses 
than the one assigned with their account. In order to restrict the sender identity configuration and to avoid WTF when sending is rejected by 
the SMTP server, the Roundcube config offers the 'identities_level' option which can be set to one of the following values:

    0 - multiple identities with possibility to edit all parameters
    1 - multiple identities with possibility to edit all parameters except email address
    2 - one identity with possibility to edit all parameters
    3 - one identity with possibility to edit all parameters except email address
    4 - one identity with possibility to edit only signature

As far as our code audit showed, the restriction is checked on the server side each time the user tries to use or edit one of the identities. It doesn't seem possible to bypass the mechanism.

V4.14 Verify that all access control decisions can be logged and all failed decisions are logged.

Successful logins are logged via the central logging system in index.php:119, while failed logins are logged in index.php:164. A dedicated logfile for user logins is used. Additionally, for every request, an authentication check is performed (rcube_session.php:733). Failed checks are logged with the reason for the authentication failure. However, it is not possible to log successful authentications via the check_auth function.

V9 - Data Protection Verification Requirements

The Data Protection Verification Requirements define a set of requirements that can be used to verify the protection of sensitive data (e.g., credit card number, passport number, personally identifiable information).

V9.1 Verify that all forms containing sensitive information have disabled client side caching, including autocomplete features.

This requirement has to do with the protection of client side cached data. Sensitive data such as passwords must be ensured not to be stored in cache so as not to be accessible by attackers. File killcache.inc (code below) ensures that the cache at client side is deleted.

There is also the autocomplete.inc file which has to do with the autocompletion feature of the e-mail addresses while composing a message. We should draw a line separating the sensitive and the non-sensitive data. If we consider an e-mail address as sensitive piece of data then V9.1 requirement is not met. Otherwise the requirement is met.

(Erik: Here you touch upon an interesting point, namely what is considered to be "sensitive" anyway? For V9 one could consider explicitly listing all data that is consider sensitive, given the functionality of Roundcube, to make it clear how this has been interpreted. Ideally of course, the documentation of ROundcube - or the the functional and security requirements that have been gathered for it - would say that.)

V9.2 Verify that the list of sensitive data processed by this application is identified, and that there is an explicit policy for how access to this data must be controlled, and when this data must be encrypted (both at rest and in transit). Verify that this policy is properly enforced.

This requirement can be "broken" into 3 subrequirements:

a. verify that sensitive data are identified

In the user manual is stated that:

Protect your installation

Access through your webserver to at least the following directories should be denied:

/config
/temp
/logs
Roundcube use .htaccess files to protect this directories, be sure to allow override of the Limit directives to get them taken into account.

b. verify that there is a policy for access control to sensitive data

In the plugins\acl.php file specific access control lists are created. The rights of each folder are displayed in the Info field. Rights Tables are created to control the access rights to non protected folders.

c. verify that there is a policy for encryption of sensitive data during storage as well as during transmission

In the plugins\password.php file all functions concerning the encryption of the passwords during the storage and the transfer are described. We could not find any other info concerning similar encrypting operations for other sensitive data.

So in total we think that the requirement is met.

V9.4 Verify that all cached or temporary copies of sensitive data sent to the client are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data (e.g., the proper no-cache and no-store Cache-Control headers are set).

In file program\lib\Roundcube\rcube_cache.php, a class for accessing the Roundcube cache (client side) is specified. In this class.

  • All variables in class rcube_cache are private.
  • The user is specified by $userid identifier variable in order for access control to be enforced. This is done with the creation of a per user cache key and index cache key name.
  • The variable $ttl sets the expiration time of memcache/apc items with a default value of 1 month (2592000 seconds) of inactivity and the function expunge() removes cache records older than $ttl.
  • The functions:
    • private function write_record($key, $data) writes single cache record in database
    • private function write_record($key, $data) deletes cache records
  • function remove($key=null, $prefix_mode=false) clears the cache.

In file program\lib\Roundcube\rcube_cache_shared.php

The situation is exactly the same as above (program\lib\Roundcube\rcube_cache.php) except for the fact that there is not a variable $userid and the functions that create per user cache key and index key name. Which is reasonable because this file has to do with the shared cache.

We have not found any indications about the no-cache or no-store cache-control headers. The cache memory is used but the userid is specified which means that it can be accessed only by the legitimate user. Special care has been taken for the deletion of the cache memory after the use or after a specific period of time. In total our verdict for the V9.4 requirement is that it is met.

see also: using a caching IMAP proxy and Caching.

V9.5 Verify that all cached or temporary copies of sensitive data stored on the server are protected from unauthorized access or purged/invalidated after the authorized user accesses the sensitive data.

For this requirement we could not find any indication about the server side caching feature. This means that there is not a file or any lines of code in the roundcube source code package stating how cached data are treated ot the server side. As a matter of fact roundcube is a browser-based IMAP client with an application-like user interface. It works with every IMAP server. We cannot know or have access to the config files of the IMAP server. So we think that it is out of the scope of the present case study to determine if the V9.5 requirement is met or not since it is a client side software case study.