Continuing from my last week's progress, this week was more theoritical than practical. For this week I focussed on:
- Nonce Validator, more specifically ensuring it works.
- Learning about Oz and how it can applied.
Last week went into implementing the nonce validator as was detailed in my previous entry, this week I spent some time ensuring it works. For this I fired up two of my personal computers, both had a working Apache/PHP/MySQL environment and fired requests at my server simulating replay attacks. The result was a success, it blocked any malicious requests as it should have.
Nonce validation information is stored using Drupal's Cache API, while this works really well, if the server is using something like File cache or Memory based cache over multiple servers it can cause problems. For example, if server A has information for some client's nonce request but a replay attack hits server B which doesn't have the same information on cache, it can cause the replay attack to occur. A solution for this is to force DB backend which removes the possible ambiguity between servers, however it might cost performance in high frequency request environments. Still, for the moment I've judged it's safer to use DB than File/Memory and since it's a single table operation it shouldn't be much slower.
Of course these were some simple cases of replay attacks, high frequency attacks can be a challenge of their own. For example, an user is making a legitimate request but an interceptor copies the request and sends it at more or less the same time. In this scenario, before the validator has finished processing the first request, it receives the second request. Since the validator hasn't stored first request's information by the time second request arrives, it validates both. This is a problem to which's solution I still haven't found, a potential solution would be to lock the table as soon as the request arrives so that a simultaenous request has to wait until the first one has completed. This might cause further slow downs but the reward would be increased security.
Oz is an authorization protocol, Hawk tells who this particular user is and Oz tells what that particular user can do. Take a scenario for example (courtesy of my mentor, skyred):
Suppose AllinOnePhoto (D) is a site that let users to store all their photos, built on D8. It has user 0, 1, 2, 3, 4, ..., where 0 is anonymous user and 1 is admin (a user with enough access); other users are authenticated users. P is a third party site that offering printing service.
Hawk Auth and Oz Auth together should offer authentication solutions to the user stories below:
- D or User 1 developed a mobile app for authenticated users to sync photos to D. There are Android version and iOS version. Each version uses one key that D issues.
- User 2, 3, 4, .... have mobile phones; they use the app that D has developed, but they only know their usernames and passwords.
- P offers printing service, but it ask their user to grant the access that they have on D. Once P has the permission, P can only access one particular user's photos.
The above scenario is a fairly standard occurance with any site providing RESTful access to it's content and resources, it's also a scenario we need to solve with this summer's project. The first case is simple, User 1 is admin and simply needs to be identified by the application. This can already be solved using the existing Hawk module, the admin can generate and feed the keys into the application and everybody wins.
The second case, however, becomes trickier. Users don't have direct access to creating credentials, which would be fair since credentials provide unfettered access to a lot of parts the admin might not want to give directly to end users. However, they still want to use the application. In this scenario, Oz kicks in. Oz allows the application to identify on behalf of the users and for the users to grant certain explicit permissions to the application which can then be used to interact with the server. This is very similar to how Facebook's Graph API or Twitter's OAuth API works. Similar is the case with third scenario except P is the application users will be granting permissions to instead of the mobile application developed for the site.
To provide support for the above scenarios, Oz is a vital component and the implementation of Oz by the original author seems close to feature complete. However, it has zero documentation which makes it a challenge to figure out the original intent of each end point and component of the protocol. I've spent the better part of the week understanding the intent behind each Oz' component and I believe I have a understanding solid enough to start working on an implementation in PHP.
During my next week I will be working on porting Oz to PHP as well as documenting it enough so that it's easier to start with. Once I'm done with that, I'll start implementing the module for it in Drupal. Over the next few weeks, I'll write a few posts about Oz, how it works as well as how it is being implemented within Drupal.