Category: Best Practices

Validating the Referer: Not as Useless as I Thought?

I used to validate the HTTP referer header to verify that users were accessing certain pages from certain other pages. For example, users accessing sampleapp/edit.cfm should be getting there from sampleapp/index.cfm. Anyone accessing sampleapp/edit.cfm without coming from sampleapp/index.cfm was probably monkeying around and should be send back to the index page, or possibly even logged out.

However, it is fairly trivial to modify your referer header, so anyone who wants to monkey around with sampleapp/edit.cfm can make it look like they are coming from sampleapp/index.cfm. (If you’re interested in modifying your HTTP headers, I suggest checking out the Tamper Data Firefox plugin.) The check provides absolutely no assurance that the user is really coming from the page. Therefore, I decided the check was useless.

I’ve been attending a weekly web application security study group with some of my colleagues for the past several weeks, where we’ve been reading and discussing The Web Application Hacker’s Handbook. The past couple sessions have been about cross-site scripting (XSS). Justin Klein Keane brought up a good point at today’s session: checking the referer may not keep a malicious user from altering his or her referer string, but could help identify victims of XSS attacks who were possibly directed to submit malicious data from a third-party site.

Checking the referer isn’t a sufficient protection against malicious users, by any means, but it could still be helpful. What do you think?

Encrypted versus hashed passwords

I’m trying to decide whether it is better to store passwords in a database as key-encrypted strings, or as the result of a hash function (with salt).

Padlock

An encrypted string is secure as long as the key is secure, which it seems to me is both its strength and its Achilles’ heel. Since the application that accesses the database needs to use the key, that means that if both the database and the application server are compromised, the data is compromised.

It also means that if the application developers have access to the database, or if the DBAs have access to the application code, the data is available to those individuals. Even though those users are most likely trustworthy, it is perhaps an unnecessary risk–not to mention their workstations may be compromised. On top of that, you need to worry about key escrow–if you lose the key, you no longer have access to your own data.

A hashed value is secure even if the database and the application are compromised, as it is the result of a one-way function. The value is also inaccessible to either the application developers or the DBAs, which provides an additional layer of security. On the other hand, since it uses a well-known hash function, such as MD5, creating a dictionary file of hashed values is trivial, and apparently an even more effective method to reveal hashed data is to use a rainbow table (the description of which goes a bit over my head right now).

That’s where the salt comes in: concatenate the original value along with extra data before creating the hash. I can see how this would foil a simple dictionary of hashed values. From what I’ve read, the salt value can be unique for each hashed value, and can be stored alongside the hashed value in the database. I’m not sure I entirely understand how that defends against rainbow tables, but it sounds good to me.

Using a hashed value, you can’t retrieve the original data–you can only match against it. This would not work well for data that you need to access again in its original form, e.g. phone numbers. This is a drawback in some cases, but probably not for passwords.

Right now I’m leaning towards salted hash over encryption, but maybe that’s because I’m hungry and it sounds more like breakfast. I’d love to know what other people think.

Create an XSL stylesheet for your RSS or Atom feeds

Internet Explorer 6 and, curiously enough, Google’s Chrome browser, don’t display RSS or Atom feeds in a particularly helpful manner. IE6 displays neatly-formatted XML, with color-coding and indentation, whereas Chrome displays the text node of all the XML tags without so much as a linebreak:

Slashdot's RSS feed in IE6 and Chrome, respectively
Slashdot's RSS feed in IE6 and Chrome, respectively

Either way is completely intimidating to an RSS novice. Fortunately, we can change that.
Continue reading Create an XSL stylesheet for your RSS or Atom feeds

Javascript textarea counter

I’ve been thinking more about the textarea counter issue that I mentioned in my previous post (“Users Paste Differently“).

First of all, I noticed that some of the textarea counter scripts date back to at least 2000, so this has been a problem that developers have been looking to solve for 8 years. I checked the HTML 5 specification and found that in HTML 5, the textarea element has a maxlength attribute. Presumably user agents will build in the most elegant solution.

But what is the current most elegant solution? Continue reading Javascript textarea counter

Code Reviews

I recently attended a code review at Wharton. We’ve put together some code reviews at my job, but I know that Wharton has been doing formal code reviews for years and I wanted to check out their process to compare notes. For this particular code review they were looking at a small ColdFusion application developed using Squidhead.
Continue reading Code Reviews

Writing A Spec Way Too Late

So what was a wonderful project to start with became a nightmare, but I finally see the light at the end of the tunnel with it. Because this project started off so innocently, and became such a disaster, I feel like I should share some of the mistakes I made along the way, and some of the insights that I have gained in both 1) extracting myself from the problem and 2) not allowing myself to get sucked into issues like this again. So lets start with a little bit of history of the project and the situation and go from there.

The development company, which I will refer to as “E” in this post is one that I have worked with for a while. They are good, skillful and friendly, they also do have a history of not generating sufficient (or any) spec’s for projects before they sign deals. This is a known problem, and something that both developers and designers have been complaining about for a while.

Continue reading Writing A Spec Way Too Late

Building your own libraries

About 4 months ago I finally got the hang of building my own libraries, and having them consistently come out as useful bits of software that I found myself reusing over and over. More than anything else I stumbled across the secret to this simply as the result of some random flailing, but it’s a very good principle, and I would like to share it because I think that it’s easily adaptable.

The secret is: Write sample code first

This is not the same thing as writing test cases first, its about figuring out how you want to USE your lib, before you sit down and write the lib. you should write sample code that makes use of your library, and if it’s ugly, then you should re-write it. Try not to worry about how you are going to actually make the library do what it will have to at all, just think about writing code exactly the way you want to, in your dream scenario, when you apply the library. Go through it, are there Param’s that can be left out most of the time because 90% of the cases they will always be the same? (set rational defaults)

Now write some more sample code, this time come up with the most absurd, obtuse, edge case applications of your library. Things that it was just not meant to do properly. Write some sample code that is able to do them. Unlike the previous sample code, this does not need to be pretty, you just need to make sure that its possible. I strongly suggest making use of optional closures in order to keep yourself out of boxes.

Now go back over your ideal sample code, polish it even more. You have probably come up with some things that could be made simpler, easier and more obvious after writing the really evil edge cases.

And then finally, start writing the actual library. Figure out how to make it leap through whatever hoops you need to in order to make it fit the sample code that you have written. Try hard not to compromise your original sample code vision. If you must, make sure that you do it in a way that leaves the sample code still graceful. (sometimes it makes sense to change several things if you have to change just one)

I have found that this leaves me with two advantages for actually re-using my libraries later:
1) When I want to use them, they tend to work just how I want them to. This is a result of writing them to an ideal use case
2) I have two big lumps of sample code so I can remember how the hell I was supposed to use them without re-reading the whole body of code. Often I actually paste the simple sample into what I’m doing and then just transform it into what I need.

User Interface Issues

I just recently finished up some pretty cool feature adds to a lightweight CMS that I have built for a client. (they are happy and impressed with it, and It looks like I’m going to pick up another two jobs, where all I need to do is install the code I have written. Yey! I have been trying to get to that point for quite some time now)

One of the major reasons behind the feature upgrade was to fix some huge User Interface problems with “list management”, and they are fixed, but of course now that I’m playing with it, I have discovered that the new UI has some big issues as well. In particular, administrators now see the list exactly as it normally would be, but there are a few links next to each item that allow you to edit it, delete it, or move it up or down. It’s neat but the extra text very much breaks up the visual flow of the list in a lot of cases, and in one case is actually pretty darned hard to access.

Continue reading User Interface Issues

Code refactoring VS feature addition.

I’m currently working on a pretty major overhaul to a custom Content Management System that I wrote for some clients, and I have found that I am both reworking the interface, and doing code refactoring at the same time. I notice that I often end up performing these two tasks simultaneously, partially because its hard to sell clients on pure code refactoring but it does have to happen, and partly because feature creep is an ever-present evil.

The question is, would I do much better to try to wear these hats one at time? would code refactoring first, without changing any features, followed by a round of feature changes result in a more manageable process? Or am I just deluding myself, thinking that something else looks better because I’m not elbows deep in it at the moment?

Does releasing code to the public inspire extra effort?

About 2 years ago, I created a javascript image/photo gallery to embed gallery functionality into a web site using only client-side processing. Although I created it for a specific purpose, it was generic enough that I decided to make it available for other people to use on their sites.

Imagine my surprise when people took me up on that offer.

Continue reading Does releasing code to the public inspire extra effort?