Let's get cracking on Access Control. In my last security post we looked at some bad examples of access control. It was good for a laugh and remembering simpler times, but we really need to see how access control can be better handled.
Now, before we begin I will throw out that the examples I am going to show in this sub-series are simplified. I am not going to try to work them into frameworks, or AOP, or any thing else that could make them "better". This is about demonstrating the concepts of access control to those that may be unfamiliar with it.
As I have been thinking about this sub-series on Access Control, I have been realizing what a HUGE area this is. There are so many aspects to access control and so many different methods of doing it. So first I think we need to expand on our definition of what access control is, then in future post discuss some ways to implement them.
Access Control is used to protect the assets of our web applications. By controlling who is accessing our assets and how they access them we ensure that they are only accessible by those who are entitled.
So what are our assets?
You might be surprised to learn that ever element of our application is an assets, and every assets needs protection. You may think, "every asset?!?, That's crazy!" But is it? First, let's look at what out assets are:
- Source Code Files
- System Files
- Images/Flash/Media Files
- Document Files (pdf, doc, xls, etc)
- Configuration Files
- Data(Usernames, passwords, Credit Card Numbers, Users' personal data, etc)
So now that we know what some of our assets are, do we still think they all need at least some access control? Absolutely! Yes, even your image files need some level of access control. You may want to let any one view them, but do you want just anyone to be able to delete them? Or worse, overwrite them? Access control is about more than just making sure that your /admin section is only available to the admin, (not to be redundant or repeat myself) it is about controlling access to all of your application resources.
So, now that I beat the hell out of that, let's move on. How do we control access to our application?
Source Code Files
Access control takes place at different levels. For the most part, control of how your source code files are viewed and whether or not they can be overwritten is controlled by the web server. It the server is mis-configured, files could be overwritten or deleted or the source code could be exposed. I am not going to get into web server configuration right now. Maybe someday.
Multimedia and Documents
Access control for your multimedia files and documents should be handled at the web application level in most cases. If needed you can also try to control them at the web server level, but my opinion is that if you need to control access to these types of files, that they should be stored behind the web accessible directories on your system. So in other words, above(behind) the web root. Then they can be delivered to your end users' clients on request. We will get into more detail on this in a future post.
Configuration files are an asset that need to be tightly controlled. They can contain usernames and passwords, important file paths, and other sensitive information. They can be secured either by storing them behind the web root, by storing them with an access control file (like .htaccess), or by securing them programatically (like renaming xml config files to .cfm so that they can be secured with an Application.cfm/cfc file). I will have a short post on this in the coming days. This is one of the easiest access control methods there is and it can be used to secure a lot of different file types.
The bulk of this sub-series will be focused on controlling access to our data. This is what most developers are going to spend their time securing. This includes keeping users out of secure areas of our applications, preventing circumvention of application flow, stopping application misuse and tampering for obtaining or destroying information, and other equally dull, yet important, topics
I will not be discussing securing the database, system files, or servers in this sub-series. These are administrative tasks. To some extent, we as developers can help protect these assets through following best practices for avoid SQL injection attacks and by making sure we think through implementations of tags like cfexecute
Surprised as you may be to read this, I don't like repeating myself. So I am not going to discuss authentication, session management, or password security. However, these are items you need to understand in order to provide proper access control and to get the most out of this sub-series. So I will refer you to my other posts on these topics.
Password Security with Hashing Functions
More on Hashing Functions
Salting and Hashing Code Example
User Login with Salted and Hashed Passwords
Session Security in ColdFusion Subseries