ChromaTweet
July 3rd, 2009Just pushed ChromaTweet.com live, a little 1-day project that displays tweets mentioning colours in colourful boxes. Go check it out! Works best on a big screen, if left for a while.
Boagworld podcast 171
June 25th, 2009Featured on this weeks Boagworld podcast, talking about Headscape’s migration to Google Apps
Simple steps for security
June 3rd, 2009Security is a complicated monster to tackle, so it helps to think about it in really, really basic terms. Stuff comes in, stuff goes out. We have to assume that anything that comes from the user is dangerous, or tainted, and can’t be trusted in any way what so ever. We don’t even know for sure that the user is who they claim to be. Trust no-one. We also have to be 100% sure that anything we send back to the user is safe, un-tainted, and uncompromising. You don’t want to send dodgy scripts to your users, and neither do you want to send back valuable clues to the inner workings of your code. This is not meant to be an all-encompassing guide to preventing attacks, but instead a set of guidelines to writing applications in secure way.
Minimise
The first rule is this. Minimise areas that accept input from the request, and minimise areas that send response. Sanitisation and validation should be the first thing you perform on data received and the last thing before you return it. Following a sensible architecture such as the Model View Controller approach separates data received by the Controller area and data returned to the View. This will make your life far simpler when you start tackling such issues. This applies to all forms of input (form data, querystrings and cookies) and all forms of output (HTML, redirect, file download).
Validate
A commonly overlooked validation is confirming the data has been intensionally sent from the user. There’s nothing to stop a 3rd party website posting to your website, so it doesn’t matter how secure your login form is, the posted data could be coming from any of the dodgy websites your user has open. An easy solution is to use a random key as part of every posted form, unique to the users session. This way you can easily verify the form has been posted from a tightly controlled page you served to your user. It’s not enough to look at referrer headers, because these are easily faked. ASP.Net web forms, to their credit, do this by default.
Use White-lists over Black-lists. Lets say for example you’re validating a phone number, you don’t specifiy every non-digit character you want to remove, you strip everything that isn’t 0-9. A little too obvious? The same applies to the classic script tag. If you start trying to remove every form of <script> tag, you’ll end up playing catch-up against tricks using <img>, <body> and clever encoding. If allowing any kind of HTML through is necessary, you’d better be damned sure who submitted it and who is going to be able to see it.
Storage
So you’ve received your data, it looks pretty good. Whatcha gonna do with it? If it’s heading towards a database, you can’t be too careful. Escape it, or better yet use parameterised queries. If it’s the file system that your data is ending up, put it somewhere sensible. Ideally, this would be somewhere outside of your webroot, or in a protected folder. Whatever happens, you don’t want anything here directly accessible or executable. Just to be sure.
Responses
OK, so we’re sending a response. Just because the data we received passed our tried-and-tested validations doesn’t mean it’s safe to send back to the user. We HTML encode everything, unless absolutely necessary. If it’s plain text, fairly straight forward. If you’re putting suspect data into an HTML attribute, it might be an idea to verfify the format. If you think you’re outputting an SRC or HREF, check it at least looks like a path. If your response happens to be a redirect, double check nothing funny is going on with the URL. If your response is a (serious) error, make it look friendly, but don’t give away exactly what went wrong. If you want to send them a file, attaching it and manually setting the MIME type is more controlled to simply pointing them at the file.
This is not intended as a set of golden rules, rather a few key points to help you think about the code you write. Most new forms of injection and hackery are just clever ways of attacking poor code. Writing sensible code will keep you one step ahead of such attacks.
Summary from SXSW 09
March 21st, 2009OK, so SXSW is great for meeting people, parties, twittering, eating out etc. But there were also some fine talks from excellent speakers and panels. Here is a summary of what I took away from this years southby.
Websites are so much more than print
Most websites are built like people design magazines, posters and books. Websites are built as pages and adorned with pictures and video. This is akin to early filmmakers drawing inspiration from the theatre. It was only when filmmakers got creative and allowed the camera to be part of the action instead of an audience member that the industry came into its own. Good example: skittles.com – Their site is a mashup of a twitter search, youtube channel, flickr search etc. This is brave, but cool.
Sitemaps and navigation. Traditionally they have always been deemed necessary, and from an information architecture point of view, they are very handy. Clients like them so they can organise their pages into a natural hierarchy. This is wonderful, except as a site grows, it breaks. Eventually there comes the realisation that content could be categorised in different sections. An event may appear on multiple listing pages. A photo may be part of several galleries. This fine when navigating a site from top to bottom, but who really visits a site and thoroughly works their way through the sitemap?
Most people arrive at a site from a search engine or link, jumping right in on a page in the middle of a sitemap. So where do they go from here? There can be multiple routes back up the navigation tree. What we have here people is many-to-many relationships. This is a tricky thing to consider when building a sitemap. So don’t. Think about content, think about tagging, think about related content. If you get the little pictures right, the big picture will take care of itself.
Inspired by Dan Willis‘ SXSWi talk.
Unnatural experiments in Web Design
Paul Annett’s talk on using clever design tricks to entertain, amuse and inspire visitors was in itself inspiring. Often we go to great lengths to ensure our sites are usable, friendly and don’t break. We rarely go the extra mile to add the “Ooh, that’s clever!” factor to a site. The value of this is also underestimated, and can transform a site that makes a client happy, to one they rave about. The flip side is that if a nicety interferes with the functionality of a site, the opposite effect can occur. Classic examples are Silverback, with it’s parallax vines, webleeddesign, with the scolling paint and kyanmedia (click the worm in the footer). The justification for the added flare can be found in the Kano Model of customer satisfaction.
Creating a great API
Thanks to Greg Pollack for the down-to-earth How not to Fail at Web Services. There are some really simple rules to creating a great API that many have failed to follow.
- The URL is for nouns
- HTTP method is for action (GET, POST, PUT, DELETE)
- pronouns (or ids) should follow regular nouns (or types)
Bad example: /get/users?id=1
Good example: /users/1
Due to browsers only supporting GET and POST, it’s fine to compromise by using POST and pass in the method as a value. This keeps the url clean, readable and semantic.
The Future
Naturally, there was plenty of people looking for someone to tell them they can stop “supporting” older browsers. The best practice is not to ignore older browsers, but if the client is happy, just give them a simpler layout / style. New browsers can then receive a progressively enhanced interface. No browser should be left unusable or inaccessible. Naturally, it is up to the client to decide how much time is spent developing for older browsers.
Accessible Rich Internet Applications. It is becoming increasingly popular to use AJAXian methods of document manipulation, and this can be confusing for both screen readers and screen reader listeners. Work is being done to improve the control developers have over marking content and content areas as dynamic or prioritise announcements.
CSS3 always makes for an impressive demo. I particularly enjoyed Opera’s demo of rotating and shearing iFrames, even though I doubt it has a real world use. The principle of having that level of control of elements is exciting. Microsoft’s approach to compatibility and standards with IE8 is kinda convoluted, but clever and probably ultimately the safest approach. We’re still in a transition period, remember.
Ask yourself why
March 4th, 2009When it comes to writing really helpful comments in code, the only important question is why. It’s all too easy to make a quick note of what or how the block of code may work, but usually this ain’t too tricky to figure out. Coming back to old code, it’s the though process behind the logic that you wish you understood.
Whether it’s Style sheets, javascript or .Net, at some point in the development decisions require thinking outside the box, or working in a counter intuitive way to solve a weird problem. This is the snippet of understanding that needs to be captured to ensure the next time the code is looked at, it makes a little more sense.
