Year Of Security for Java – Week 32 – Access Control (2)

No Gravatar

What is it and why should I care?
We defined access control in part 1 of the access control sub-series, so let’s move on to talk more about what we do about it.

What should I do about it?
In part 1 we discussed limiting your users’ interactions with your application by functionality. This time I’d like to discuss an additional consideration for limiting interaction: by data. This simply means does your user have access to this specific data. A simple example should help clarify. Consider online banking, where millions of people might have access to the same function (view account), but only you (and bank employees) have access to view your specific account data.

One generally painful issue here is that there’s no generic way for me to say how this specific recommendation will play out in your application. The “data” aspect of this issue means that it is usually coupled to your data model. If users are limited to their bank accounts, you need to consider the way you store data and see how you link users to bank accounts. You then need to limit your queries in the appropriate manner. There are more generically applicable techniques that generally involve data labeling or tagging, but they’re often very involved and complex to get setup, and if you need a large solution like that, you probably are already aware of that fact.

A related issue is that most frameworks (save maybe ESAPI‘s interfaces) do not provide any API help with regards to access control related to data, or even a reminder that you should do it. For the most part, there are always custom APIs within an application to deal with this issue. That means that there’s often spotty coverage. Some APIs are protected properly, but then others will be wide open.

This means that part of your development process will include identifying those pieces of data that should be restricted to only certain users or groups, and providing centralized access control APIs that are used to evaluate permissions to the given data. You might have a simple API that looks something like the following:

if(isAuthorized(Bill, VIEW, Account.class, 17398)) {
    //do real work
} else {
    //user is doing something bad, or there's a bug in the app, fire off event to appsensor intrusion detector
}

The access control check above asks if “Bill” (user) has access to perform a “view account” (function) on the account (data) represented by id 17398. If you’ve done authentication correctly and performed a check like this, you’re better off than many applications out there.

The next post will look at a few other data points to consider in your access control decision matrix. However, the basic function/data checks described in the first 2 posts are good enough for many uses. However, it’s critical that both be applied correctly and consistently.

In conclusion, we saw that performing access control checks by considering access to data is an important part of any access control scheme. It can be more difficult to build than functionality checks since there’s rarely help from common frameworks and it is dependent in large part on the data model of the individual application, but rigorous focus on building the appropriate common APIs can make it much easier to apply consistently.

References
———–
https://www.owasp.org/index.php/Category:Access_Control
https://www.owasp.org/index.php/Guide_to_Authorization
https://www.owasp.org/index.php/Access_Control_Cheat_Sheet

Be Sociable, Share!

Technorati Tags: , ,

Leave a Reply

Your email address will not be published. Required fields are marked *