If, like me, you were unable to attend the Open Web Application Security Project (OWASP) AppSec Conference in Krakow, Poland last month, you can now view the videos from the conference online.
I posted on Friday about my experimental code for session token rotation and I got some great comments (thanks Peter and Brian). Brian stated in his comment that because I am using a <cflocation>, which is a 302 HTTP redirect, it could cause problems with legitimate deep-linking, plus, using <cflocation> feels like a hack. I agree with the latter. I was not happy with using <cflocation>, but it was all I could think to do at the time.
So I gave it some more thought this weekend and came up with a new way of doing it that uses <cfhttp> instead of a redirect. I am MUCH happier with this method for a couple of reasons.
This is a continuation of a topic that I have been blogging about and thinking about for a long time. Session management and cookie security are really interesting topics that I could yammer on about for hours. Go ahead, ask my wife.
About 3 months ago, Ben Nadel blogged about a behavior of ColdFusion that I found troubling.
I've stated before how highly I think of the Open Web Application Security Project (OWASP) and I am now very glad to see that they have started a new blog. Hopefully the OWASP Blog will be a great resources for staying up-to-date on security related current events, and to learn more about the status of on-going OWASP projects.
My wife and I are leaving in the morning to go on a week long vacation. It's been a while since we've done this, so we are looking forward to it. I'm sure going to miss the kids though. Our two children will be staying with my parents.
We are renting a cabin in Northern Minnesota (near Fargo, ND) and we are going to relax. It should be nice, especially with my new Kindle DX to help pass the time. I am looking forward to doing a lot of reading, and resting. We may do some fishing and boating. It should be a blast.
I was going to try to schedule some security tip posts for while I was away, but it just didn't happen. But I will probably work on some while I am away, so hopefully I will have some fresh content ready to go when I get back.
This is my first ever product review, so don't expect much.
I opened up my Amazon Kindle DX last night and my first thought was that I was over whelmed by the packaging. I had to open the outer box, tear off a paper sleeve and then open an inner box. Opening a lot of boxes makes me nervous. I think because I get the feeling that it will make it impossible to return if I can't get it all back in the way I found it.
The Kindle itself was, of course, in pristine condition. I read the instructions (no really I did), but they were short and to the point. Plug it in - Turn it on - Start to use.
I got a weird request from one of my internal customers today. In one of our applications he wanted to be able to "uncheck" radio buttons.
We all know that if you have a group of radio buttons, like this, that once you select one option, you cannot unselect an option, you can only change from one option to another.
The use of JavaScript is becoming increasingly popular with the availability of incredible JavaScript libraries. These libraries make creating Ajaxified web application easy, and fun! We can use them to create interactive and beautiful applications that rarely, if ever, require the page to refresh.
A lot of the JavaScript libraries also have helpful tools and plugins to implement form validation. These tools are great, and I don't want to discourage their use, but I do want to point out that these tools ARE NOT for security and should not be used to prevent malicious data from getting to your application.
It seems like a no-brainer to me, but I will say it anyway. Code reviews are a good thing. Some people may shy away from them because it may make them feel inadequate or like they are being judged. But the idea behind a code review is to learn.
Code reviewing is a great way for a developer (novice or otherwise) to track down inefficiencies or architectural problems with their code by using the experience of other developers as a tool. We all know that two heads are better than one, right?
Failing securely is one of those things where, when you think about it, you say "duh". But I, for one, did not realize until it was pointed out to me that I was not always doing it. Let's look at an example of failing insecurely.
In this example, we have an application that has three types of user roles. The three roles are "admin", "superuser" and "user". Let's say we have a piece of content that we don't want regular users to access, so we do this:
