Archive for February, 2006

Being too secure with a CGI script

Monday, February 27th, 2006

Oooops. I mean, it seemed like such a good idea, right?

While working on the new Asman IT Consulting website a couple of months ago, I wrote a new “Contact Us” CGI script. I often work in the IT Security space, so I always have the security angle high on my list of priorities. So, I did the usual things:

  • I made sure that it wasn’t too flexible. Case in point – While chasing down a spam problem for a client, I discovered they had used a well known “Contact Us” script that was widely available that let you set the “to” address, such as the website administrator, as a hidden field. It worked well, until the spammers realised they could override that in their POSTs and use your Contact Us page as a spam relay…!
  • I sanity checked all fields to make sure only legal characters were present. Not, by the way, the common mistake of checking for illegal characters. Seems so tempting, as there are far fewer illegal characters to check for….. right up until you discover that you overlooked a dangerous character!
  • I checked that the script was only accessed from my “search” web page. Anything else would suggest some automated tool randomly accessing it directly
  • And a host of other checks and practices for things like rate of sending, data size, logging improper use, etc, etc

So far, so good. A few tests showed things working fine. And 2 months later the number of malicious hacking attempts made through it numbered exactly 0.

Exactly as many legitimate “contact us” messages I’ve received, as it happens. ;)

A look through the logs showed the problem. And it was all because of that second-last point.

Turns out I’ve had a few people try to send me messages this month. But a number of the more tech-savvy users (and I’m flattered they’re among those accessing my site!) turn off the “Referrer” facility in their browsers. The “Referrer” field normally allows a site to see where visitors have come from. With this disabled, my “Contact Us” facility refused to process their message as it looked like they had bypassed the appropriate web page within the Asman IT Consulting site.

All fixed now, and my apologies to those who were rejected up till now! But an interesting example of the “Security” vs “Ease of Use” balancing act that comes up time and time again. There was nothing intrinsically wrong with my initial approach. And there is nothing intrinsically wrong with people choosing to configure their browsers in that fashion. Everyone needs to pick a security stance that suits their particular situation.

And, based on their experiences and changing needs, amend that stance as required.

Upgrading to dual flush toilets

Friday, February 17th, 2006

As of a week or so ago, my 20 year old townhouse now sports two new dual-flush toilets instead of the original single flush toilets.

This may need explanation in some quarters of the world (if my American friends are to be believed!). In Australia, most toilets are dual flush – one option for “Number Ones” and one for “Number Twos”! ;) The advantage is that you can use a lot less water to flush liquids than solids.

(I should apologise at this point – this post is a little more “earthy” than my usual fare!).

The water savings I achieved are even more dramatic, though, due to improvements in the design of toilets in the last 20 years. Whereas my old toilets used 11 litres per flush, my new toilets use at most 4.5 litres (and only 3 litres for the “number ones” option).

The total cost was $1300. $700 for two new toilets, and $600 for installation.

So, I’ve done a few back-of-the-envelope type calculations and worked out how much water I’ll be saving. Care to guess? Go on, I dare you! :)

16,000 litres a year.

Wow.

Kind of impressive. So I quickly moved on to figure the dramatic saving this would have on my water bill. Turns out this depends on whether I’m a big water user or not, but it works out to be between $8 to $16 a year.

Wow again. But this time, its the other sort of Wow…..

Now, I didn’t go into this to save money – I did it because it was the Right Thing ™. Glad I did it, and I’d urge everyone to do the same. 16,000 litres of water per household is a lot of water. But there’s a lot of people out there who are either unable to afford the cost of upgrading or (to be less generous) to self-focussed to do it unless theres something in it for them.

Full credit at this point to the ACT Government – they have a rebate program that gives you $100 rebate for doing the upgrade – there’s a few rules and conditions, and you can get all the details at http://www.thinkwater.act.gov.au. That amounted to a 15% discount, which is great.

Of course there are cheaper toilets out there (there are also way more expensive ones – do you know there are toilets that cost $1500 each?! How good can using the bathroom be?). And there may be cheaper plumbers. And many people may only want to upgrade a single toilet. Still, householders need to expect to pay at least a couple of hundred dollars.

Wouldn’t it be nice if water was charged at closer to its actual value? Imagine if, for instance, households were allocated some subsistence amount of water for free (or some small fixed sum), then a much higher cost for every kilolitre above that. I’m sure I’m grossly oversimplifying, but I imagine you could come up with some figures that match the average households current water bill. The difference would be that there is suddenly a big incentive to save water.

I’m sure this isn’t a new idea (although I haven’t seen any extensive discussion on it during my travels on the Net). What do you think?

Java coders have it easy – crashing constructors

Friday, February 10th, 2006

I came across this entry while scanning Java Blogs yesterday about how to handle exceptions within a constructor. The essence of the article is how do you handle the situation where you couldn’t instantiate your object?

So, if the user passes invalid parameters, do you throw an exception? And, slightly more subtly, if your constructor encounters an exception during object setup, how does it handle this?

Interesting article and well worth the read.

But it struck a bit of a chord with me – I recently bought a Nokia N70 phone, and have been cruising the net looking at how you can code for these things. The N70 is a Symbian phone, and while it has J2ME support, the hardcore stuff seems to be done in C++. Now, C++ is an … interesting language, but is not really known for its in-built protection against memory leaks, and when you’re running a program on a device with limited memory, where your app may well run for the order of days or months this suddenly becomes a big deal.

OK, so you just code, really, really carefully. ;)

Well, turns out that constructors are a special case in terms of memory leaks. Symbian doesn’t use standard C++ exceptions, but it does have an analagous concept called “leaving” grafted on. And not being a C++ guru, I couldn’t tell you what difference there is between normal C++ exceptions and the Symbian variety. In any case, the issue when writing Symbian programs appears to be this:

  1. Constructor called
  2. Constructor initialises an instance variable that points to some new object
  3. On the next line, the constructor encounters an error and leaves

So, we now have allocated memory for some new object (step 2 above), but the object that owns it no longer exists – it crashed during construction. And because the object never fully formed, the destructor wasn’t run on it and so couldn’t free up the memory. Ladies and gentlemen, we have memory leak…. :(

Turns out that Symbian programs have an accepted idiom on how to handle this stuff. Objects that can suffer this way have a static construction method (like the whole getInstance() idiom you see in Java). This static constructor creates the object using a constructor that only performs trivial operations that won’t crash, then once the object exists, calls an instance method on the new object that performs 2nd-phase construction. If things turn to jelly, there is at least a concrete object in existence, so the destructor will be called as normal.

Pretty neat. And pretty eye-opening as to the kind of issues you can be exposed to without garbage collection.

(Which is not to say that Java doesn’t have its own issues with memory leaks, but thats a whole other blog post… :) )

Great site – lifehacker.com

Friday, February 3rd, 2006

www.lifehacker.com. Bookmark it. Add it to your aggregator. Print out the URL, frame it, and put in on your bedside table (marginally behind the picture of your “Significant Other” – you don’t want to go too far….)

You get the idea… ;)

I can’t even recall how I found this site now – some random google or another, I think. But I’ve subscribed to the feed for the last few weeks and I’m hooked. What is it? Well, I think they describe it best:

Computers make us more productive. Yeah, right. Lifehacker recommends the downloads, web sites and shortcuts that actually save time. Don’t live to geek; geek to live.

In the last couple of weeks, they’ve posted short reviews and links to cute Firefox plugins and Mac OS X apps, links to stories on hybrid cars, and a number of really interesting links to stories on personal organisation and time management. So far, I’ve been seeing around 10 – 20 posts a day, of which I find at least 75% are worth the read.

Kind of ironic – despite their mission statement, I’ve just lost 5-10 minutes of my life each day to their website! Here’s hoping thats offset by the efficiencies I’ll no doubt gain….. :)

End of rave. We now return you to your regularly scheduled programming…

Thinking about power consumption when buying a TV

Wednesday, February 1st, 2006

Power consumption isn’t the first thing that enters your mind when buying a TV. Picture quality is a big one. How many different inputs it has. And the most importantly – whether its just a bit bigger than the new TV your work mate just bought! ;)

Its worthwhile thinking about power consumption though. I’ve just been trawling a few manufacturers’ sites, trying to get an idea of the differing power consumptions. Obviously, the big difference is between technologies – CRT, LCD, or Plasma. Comparisons are a bit tricky – Plasma TVs are universally at the big end of the size spectrum, followed by LCD, followed by good, old CRTs. In my quick google around the Net, I couldn’t find a size that was available in all technologies, but for the purposes of comparison I’ve looked at 32″ (which you can get in both LCD and CRT), and 42″ for the plasma.

From a quick sample, you’re looking at the following sort of power consumption:

  • 32″ CRT – 220 Watts
  • 32″ LCD – 170 Watts
  • 42″ Plasma – 370 Watts

To put this into a sample scenario, lets say you watch television 6 nights a week. A lot of people turn on the box around 6:30pm, and watch till around 10:30pm. But, you do take that trip to the coast each year for a fortnight. So, over a year, you have the TV on for 50 weeks x 6 days x 4 hours = 1200 hours. (Wow! Thats 50 full days, or 150 8 hour working days. We have to start getting out more!)

What does that mean in terms of power consumption? Over the year, we’re looking at the following:

  • CRT: 264 KwH/year
  • LCD: 204 KwH/year
  • Plasma: 444KwH/year

Here in Canberra we currently pay 9.9c/KwH for our electricity. So, it costs around $20/year for the CRT, $26/year for the LCD, and $44/year for the plasma. Obviously electricity prices can vary widely from area to area – this just gives an idea.

Aside from cost, though, there’s the environmental issue to consider. Depending on your electricity provider, there’s typically 1.44 Kg CO2 produced for every KwH, so in the case of the Plasma TV, that’s over half a tonne of CO2 per year… :(

Just one more thing to think about, as if TV buying wasn’t complicated enough…