Request Forgeries and ColdFusion - Security Series #9
It's been a while since I posed an entry, and it has been even longer since I posted for my on-going security series. So today I would like to get back to it by looking at Request Forgeries.
It's been a while since I posed an entry, and it has been even longer since I posted for my on-going security series. So today I would like to get back to it by looking at Request Forgeries.
I just got home from my second presentation to the Twin Cities ColdFusion User Group. I had a great time, I thought the presentation went well. I got a lot of great questions and comments from the floor, and we even went out afterward.
Thanks again Troy from having me. I look forward to doing it again soon.
Just came across the video on YouTube that has a very simple demonstration of a SQL injection attack. It demonstrates just how easy it is to get past JavaScript authentication control and how easy it is to inject SQL into a site once you take control of the web form.
Cross-site Scripting (XSS), to me, is one of those subjects that I feel like I am just barely keeping up with. I understand what it is, but It seems like every time I feel like I have a handle on the ways it can be done, I learn about something new. I am not going to claim to be the be-all-end-all authority on any security subject. It seems like there is always something new, but with XSS, it is especially so.
So, with this post, I am only presenting the information about XSS with which I am familiar. It is not intended to be the ultimate XSS guide. Think of it as in intro to some Cross-Site Scripting exploits and solutions. After reading this, I encourage you to research more on your own, as I will. As I learn more I will post about it.
If you have an application of any complexity, or if you use any of the available frameworks that are out there, whether it is Model-Glue, Mach-II, ColdBox, Transfer, ColdSpring, etc. then you are going to have config files, custom tags, template files or some other files that need to be protected.
Config files can contain a lot of sensitive information that you do not want others to see. DNS names, usernames, passwords, file paths, reinit strings, etc.
Well, I'm sure most will be glad that I am not going to try to beat this SQL Injection/cfqueryparam stuff any further into the ground. We get it now, right? Use cfqueryparam!! Unless you have a good reason not to, then use something else that will serve the purpose of creating a prepared statement for use in a query. You'll also have to do something to handle dynamic table names, dynamic sort statements, etc. These topics have been so well handled by other bloggers that I am not going to try to take it any further. Look at the bottom of the page for links to some of the best explanations.
But this post is not about SQL Injection or about <cfqueryparam> it is about having our eyes opened.
OK, so I have been putting of this access control stuff for too long. So let's get to it.
In "the basics" we are going to continue our discussion of access control by focusing on controlling how our application is accessed. We are not going to worry about source code files, media or image files, servers, non-web document files, or DBMSs. We are just going to worry about accessing the application from the browser, controlling program flow, etc.
So I have been working on my first ColdBox application the last couple of week, and one of the things I have been struggling with is Form Handling and Validation. I have not been struggling because these concepts are difficult, but with not knowing how they should be implemented in ColdBox or any other MVC framework.
The heart of my question is, when I want to display a form with values pre-populated (like when a user clicks on an 'edit' button for page in a CMS), do I pass the whole bean to the view for insertion into the input tags using getter and setter methods, or do I use the getter and setter methods in the controller to insert the values into the event/request context object and then using the events getValue and setValue() method in the view?
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.