Virtualisation should have helped to reduce Internet security risks by now

Virtualisation could have helped (and still can help) reduce the security threats people are facing using their computers on the Internet. I am not sure why the industry is not yet exploring this, at least they’re not appearing to be publicly doing this so far.

For a while now I’ve held the view that virtualisation was (and still is) an effective way of reducing some of the Internet security threats people are facing all the time. Imagine that the most enticing computer uses would be completely sandboxed. For example, if you start internet banking, the browser would run on a sandbox that only communicates with your bank and potentially the token hardware in your possession, anything outside of that would simply stop working: no other network connection, the sandboxed browsers’ access to hardware is completely isolated from the rest of your computer, except for printing perhaps. The sandboxed browser does not support any plugins or extensions, its only features are those of a dumbed down banking terminal. The protection could go as far as vendors creating special device memory regions that get automatically reserved and wiped out for secure computing purposes, no third party programs allowed to touch it. Conversely, the banks would only accept terminals that had previously been registered, much the same way that they issue hardware tokens to their clients. Such virtual machines would not be patched the usual ineffective way, instead they could be less frequently updated and each update would be coordinated by the VM issuers.

Something like this might not totally eliminate Internet security risks, but it could rid us of many of the most common threats in a very simple way. This is achievable with virtualisation and it should be cheap to realise.

We know that Security and Convenience are often at odds, by pushing out security patches all the time software vendors are causing user fatigue, just look over the shoulder of every other user to see the number of updates pending their approval. So, the current security patching practice is clearly ineffective. With BYOD gaining traction, the situation is likely to worsen. I think a new radical approach may be a better answer to the growing pain that we are experiencing at the moment.

Recent Ruby on Rails SQL injection vulnerability: lack of developer awareness, type safety

The much publicised Ruby on Rails SQL Injection vulnerability is also down to a lack of developer awareness of secure coding practices.A type safe programming language would have protected against this vulnerability too. An id is typically an auto-incremented database field, a number. So, any attempt to pass a spurious SQL string in such function would have been rejected by the type safe code. Ruby isn’t type safe.

The recently publicised Ruby on Rails SQL injection vulnerability is really down to a single issue: many developers are not aware of hardening their code. The article linked at the bottom of this post showcases both issues.

Lack of awareness of Rails secret token file

This file, as its name implies, is where the token used to further protect user sessions is configured. Inquisitive people would spot such a file quickly and ensure they won’t expose it where it shouldn’t be. Apparently many are blissfully ignorant of this file and they just push everything to Github.

The First rule of SQL injection 101

If you examine how SQL injection is achieved, it’s just a very basic mistake that has been known forever: unchecked input parameters.This points to where SQL injection could occur

A security aware developer, writing this single line of code would wonder what could happen if the input parameter were to be manipulated, and whether that were even possible. And that is the second awareness awareness that would have caught the issue.

A type safe programming language would have protected against this vulnerability too. An id is typically an auto-incremented database field, a number. So, any attempt to pass a spurious SQL string in such function would have been rejected by the type safe code. Ruby isn’t type safe.

Here is the blog that apparently uncovered this recent vulnerability: let me github that for you.

The Safari Reader button is a little unassuming gem

Apple initially introduced this feature with OSX Lion. When I saw it I immediately tried it then just as quickly forgot about it. The feature is still there on OSX Mountain Lion, and I only recently realised that I have actually been using it all the time without having noticed the point in time when I changed habits.

Your Mac, just like your Windows machine I guess, is full of nice features that you seldom use. If they were truly metering the usage of all the features that get thrown on new OS releases, I think it would be astonishing to see how much bloat creeps around unused.

Safari Reader isn’t such a bloated stuff, it comes in really handy for folks who frequently read articles on the web. Look at the two pictures attached below, it is immediately obvious which one you would prefer to see, that’s how useful the Reader button is. It is not available on all sites as I’ve experienced it, I didn’t try to find out why, but if you are aware of it, it can nicely enhance your reading experience without a sweat. That’s why I use it all the time.

Normal view of an article on Safari, before pressing the Reader Button
Normal view of an article on Safari, before pressing the Reader Button

 

After pressing Reader button
The same article on Safari, after pressing the Reader button