Web Browser Prefetching

Web Browser Prefetching A succinct description can be found from the link to Mozilla's FAQ: "Link prefetching is a browser mechanism, which utilizes browser idle time to download or prefetch documents that the user might visit in the near future. A web page provides a set of prefetching hints to the browser, and after the browser is finished loading the page, it begins silently prefetching specified documents and stores them in its cache. When the user visits one of the prefetched documents, it can be served up quickly out of the browser's cache." With this in mind, there could be scenarios where URL's are identified in internet history records which the user has not selected to visit. For this to happen there are a couple of fundamental requirements:

1. A web page contains a prefetch link
2. The web browser is set to act upon a prefetch link

For a quick test it's possible to use gemal's psyched site, but for a more real world example I used Google and Firefox to do a quick test. Google has, since March 2005 included the ability to prefetch the first result from a Google search which caused a few webmasters to get ruffled feathers from the fear of false hits skewing their stats (can be identified from Firefox clients with the X-moz: prefetch header). Interestingly none of the links to Google pages explaining their prefetching are working anymore. Firefox is by default set to enable prefetching and as far as I know can only be turned off by going to about:config and setting the value network.prefetch-next to False. I've not yet looked at IE or any of the additional plugins and tools that could also make use of prefetching.

I used the neat Firefox add on, HTTPFox to view the activity relating to the test.

The Test

I tried a few Google searches to see if the browser (Firefox 3) would then prefetch the first link but it wasn't working consistently.

Looking at the source for Google results page showed that a prefetch link wasn't always inserted. A bit more digging, and it appears that Google only inserts a prefetch link when the first result is a simple host name (e.g. www.microsoft.com).

I don't know when or if this has always been the case.

A search for microsoft (funnily enough) gives Microsoft's website as the first hit. Shortly after the Google results page had loaded a GET request appeared for www.microsoft.com, and then redirected to http://www.microsoft.com/en/us/default.aspx. A few times I see an aborted request, shown in HTTPFox as text/html (NS_BINDING_ABORTED). I suspect that this could be as a result of Firefox discarding the prefetch hint.

Just to confirm that this is recorded in internet history records, I did an internet history search in EnCase which showed the Google search and the subsequent Microsoft caching with no obvious sign that the Microsoft record was as a result of the prefetch and not of the user selecting the link.

Lab Standards

If you were to skip briefly back to my first post I referred to a document by the European Network of Forensic Science Institutes. Whilst it's slightly dated, their best practice guide for forensic IT labs is still an excellent summary of requirements for a 'quality focussed' digital forensics lab. It doesn't tell you what tools to use, where to find the 'smoking gun' you've been looking for or how to image a hard drive but it does describe the processes you'll need to work these out for yourself and prove to another party that you've been thorough in your preparation, examination and reporting. In fact it does an excellent job of translating the internationally recognised standard for forensic labs ISO 17025 for our juvenile corner of forensic science (yes, we're not that different from the other forensic disciplines, see HogFly's blog).

But who uses it? Well without conducting a survey, I could only reason that the fact that the best practice guide follows so closely the international standard, anyone who follows this guide would have attained, or would be in the process of attaining the ISO 17025 certification. After all, why not pay the few extra pounds to get a certificate if you've done the hard work already? Well, for the UK it's just two organisations, in the whole country, who are accredited (do a search for 'forensic' and look for 'data capture'). One for just 'Mobile Phone Handsets and SIM cards' and the other also including 'Computers and Computer Media' and whilst I know that a few labs have the generic quality certification (ISO 9001) and fewer still also have the Information Security certification (ISO 27001), they both seem to skirt around the issue of standards in digital forensic labs. Even ISO 17025, a standard for calibration and testing labs, but regularly used in traditional forensics, requires skillful use of the shoehorn to make it fit. Which brings me back to the ENFSI best practice guide as an example of such a shoehorn that seems to look quite usable.

Unfortunately for the UK/ European digital forensic community, ENFSI membership is normally restricted so that wider participation in developing and promoting these standards
would be limited through this organisation. The American Society of Crime Laboratory Directors / Laboratory Accreditation Bord (ASCLD/LAB) isn't so restrictive and has a scheme whereby a lab can be accredited to a standard that includes ISO 17025 and is 'enhanced' for our specialism.

Is this the way forward then? Have I found the lab standard I've been looking for? Maybe not, but it's the best I'm aware of so I think I'll give it a shot.

Date & Time stamps for files and folders

This is something I've been meaning to do for a while. Transposing the Microsoft article on what happens to the time stamps into a quick reference table seems to make sense. Of course, like when using a calculator in maths exams, you can get away without doing the reasoning mentally but I think it's a good exercise to think through the reasons for the results aswell.

Forensic tool testing

Edited 01 Jan 08 to make the ENFSI document link work, but I'm sure everyone could work out the problem anyway!

My first ever blog post so I might aswell dive straight in!

The verification and validation of tools should be one of the most important routine aspects of computer forensics as it is for the other forensic sciences but whenever I see it mentioned there's usually somewhere, a shrug of the shoulders, a half hearted attempt to convince someone (including themselves) that they do it sufficiently and regularly and a fall back position of having to balance efficiency against the (unrealistic) requirements of academics (or am I being too cynical?).

For hardware or software with limited functions, such as write blockers, there really is no excuse. Prior to purchase, as with other critical purchases checks should be made to ensure that it is fit for purpose. ENFSI have a best practice document that specifically addresses Commercial Off The Shelf hardware and requires the lab to get a maintenance agreement and some kind of assurance that the manufacturer will provide statements, certificates or other proof that it's fit for purpose should it be questioned in court.

The forensicfocus blog talks about some methodologies for testing write blockers including the all singing and dancing NIST tests and the more feasible 'Helix test'. The NIST testing is excellent in its detail but you wouldn't be buying much kit if you limited it to those already tested. Maybe, if there were an international standard for these and organisations applied more commercial pressure to the manufacturers such as described by ENFSI, we could see these critical tools tested sooner.

Once purchased though, they need to be maintained and checked regularly, just as other critical items are. I mean, we get our fire extinguishers checked, why not our write blockers? Tableau, who's products I use regularly, fairly recently released a critical firmware update which just goes to show that 'hardware' does not 'mean purchase and forget'.

As I see it, the only times a hardware write blocker needs to be checked is before first use and after any firmware upgrades. With software write blockers, where the risk of mis-configuring it is greater a limited (Helix methodology) test ought to be done every time, unless you can verify a setup script. In that case you'd just need to show that the script followed (electronic or even manual checklist?) was identical to that that was validated.