SoftwareSecurity2012/Group 11/Verdict

Uit Werkplaats
Ga naar: navigatie, zoeken

It is important to mention that the results of the verdict are based on analysis over samples of the code (e.g. checking how it behaves in certain file and then verifying if it is replicated). In order to produce a more correct evaluation, it is necessary to have more knowledge about the whole function of the system.

Inhoud

V4 - Access Control Verification Requirements

In order to perform a manual code review for the Access Control Verification Requirement, we first have to define the categories of users and the functionality they have access to. With the manual code review, we found out that the four preset groups of users are the Administrator, the Moderator, the Members and the Guests (these four preset groups are initialized in the file install.php).

These groups are initialized in the table named groups. In this table, the fields give information about the privileges each group have. These information include: the name of the group (g_title), the user title to be used for members of this group (g_user_title), moderator privileges (g_moderator), editing of users profiles (g_mod_edit_users), renaming users (g_mod_rename_users), changing users passwords (g_mod_change_passwords), option to ban users (g_mod_ban_users), option to view the boards (g_read_board), viewing user list (g_view_users), posting replies (g_post_replies), starting new topics (g_post_topics), editing own posts (g_edit_posts), deleting own posts (g_delete_posts), deleting own topics (g_delete_topics), adding likst to their posts or signatures (g_post_links), setting their own user title (g_set_title), using search features (g_search), searching the user list (g_search_users), the number of posts required for the users of the group to be promoted (g_promote_min_posts), the ID of this group (g_promote_next_group), sending emails to users (g_send_email), the waiting time between making posts (g_post_flood), the waiting time between making search requests (g_search_flood) and the waiting time between sending emails (g_email_flood).

According to OWASP Verification Requeriments list, in this page we give our verdict if these requirements are met or not. We did a manual code review through all the classes of FluxBB forum application, in order to look for motivations to our verdicts. Here we have the set of requirements related to our case.

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

PASS! For every specific function on the code (e.g. delete, edit, etc) it was verified that it is not possible to access the resource if the user is not authenticated, since in every file there is access control to check this. Also, it is not possible after you log out to have access to functions available only to login users. Moreover, only the administrator has access to administration menu in the profile. We made some testing with moderators, users and guests, and they did not have access to this menu.

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

Because Fortify can not help us in this requirement, it was really difficult to find the parts of the code that the users accessed URL's. So, we don't know if this requirement is satisfied or not.

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

For the same reason as in the requirement V4.2, we were not able to identify whether this condition is satisfied or not.

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

Not checked.

V4.5 Verify that directory browsing is disabled unless deliberately desired

(Not in level 2B)

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

For the same reason as in the requirements V4.2 and V4.3, we were not able to identify whether this condition is satisfied or not. (Erik: I understand that this is tricky to check (as you note in your reflection what people can access is really up to the application logic and there are no generic rules for this) but I don't see the essential difference between checking acces to services here and checking acess to information in V4.7. For each you'lll have to makje some ad-hoc decision on which services and information should be avaliable to a particular (type of) user. )

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

PASS! The data the user have access in a forum are the posts he writes. Given that, a user have authorization to view and edit his own data, which means the posts he wrote. (Erik:Note that editing posts could be considered a service and considered under 4.6 instead of 4.7.) The users are not allowed to edit other users posts, however they have access to view what they write, because the forum permits all users to view the posts.

V4.8 Verify that access controls fail securely.

PASS! It was verified that before every access control the kind of user is checked, and if he does not have access to this service or function, the FluxBB gives a message of error, stating No View or 403 Forbidden.

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

For us, the difference between this requirement and the requirement V4.11 is unclear. So, we are not sure if this requirement is satisfied too like the other requirement. (Erik: I guess what the ASVS means here is that if a certain button is not shown on a webpage to a certain user, it also means that that user really cannot access that function.)

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.

PASS! The end users do not have access to any data attributes that is not their own.

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

PASS! There is no sign of Access Control on the client side, therefore, nor 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

In our view, the way FluxBB checks and guarantees access control can be considered centralized, given that it uses a pun_user global variable, that is an array containing all the information about the current user. We believe that this is a centralized approach to access control. However, we are not sure whether this can be considered as a centralized mechanism or not.

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.

As far as we could verify, there are some constraints on the wiki, for example, the user cannot register with same IP in the interval of one hour. This could be a motivation to affirm that the limitation on access imposed by the wiki cannot be bypassed, however, we are not sure that it is the case for all limitations, given that we could not identify other limitations on access. (Erik: Could you not identify limitations of access in the code or could you not think of sensible limitations of access that this type of application might implement? Obvious limitations would be restricting people to a limited numers of posts for a given time period, or a limit on the maximum length of a post, to prevent DoS type attacks. I can imagine that fluxbb won't check this, and it's hard to say if it is is really necessary for this type of application, and typical uses of such a bulletin board,which are unlikely to be highly security-critical.)

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

FAILS! During our Manual Code Review we could not find any method that creates a log for the access failures or even to the access control decisions. This logging features could be used by administrators to review, however, they do not exist in FluxBB. Actually some error messages are giving as a feedback to the user, but in our point of view they can not be considered as logging features.

V4.15 Verify that all code implementing or using access controls is not affected by any malicious code

(Not in level 2B)

V9 - Data Protection Verification Requirements

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

This requirements fails, because the autocomplete is not disabled for passwords in the forms to login, to change email address and the form to change the password.

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

The e-mail address of the user is stored in plain text.

I consider the e-mail address as sensitive data, because it can be easily used to break the anonymity of users (lots of email address consists of name.surname@mail.com), but it can also be used to send malicious emails like spams, hidden malwares (virus, worms, key-loggers), or phishing attempts.

There's also an option supposed to hide the e-mail to certain category of users, not sure if it's reliable or not, because I got lost in the PHP code.

V9.3 Verify that all sensitive data is sent to the server in the HTTP message body (i.e., URL parameters are never used to send sensitive data)

(Not in level 2B)

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 nocache and no-store Cache-Control headers are set)

We could not find any Cache-Control headers or other options for handling with caching in client-side system. This way, we cannot be sure about the protection of sensitive data. In addition, the manipulation of the expiration time of cookies may generate a vulnerability for Data Protection, providing cookies which can persiste for a long time.

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

PASS! It checks if the user has the correct privileges to access cache before allowing it and, after changes in the content of cache, it uses a banning list in order to invalidate the use of unecessary data. (e.g. it calls a function generate_bans_cache() after changing users' information.)

V9.6 Verify that there is a method to remove each type of sensitive data from the application at the end of its required retention period

(Not in level 2B)