I see that Alfresco has been re-licensed under the GPL, to a model that is quite similar to that of MySQL. I've come across a lot of fear of the GPL in the Java world over the years so until Java demonstrated that it was possible to get past that fear I would have thought this was a bad idea.

I happened to be talking to John Newton earlier today and I asked him if the Java/GPL thing inspired him. He said:

We have been thinking about this for a long time. Some of us were not super comfortable with the attribution clause. [in the old BSD license] Matt Asay, who has been looking at open source licenses for a long time and is on the OSI board, has been a big advocate of GPL.
When it became clear that you could legally combine other non-GPL components (e.g. Apache and BSD) into a GPL package and the FLOSS exception that MySQL developed was really taking hold, then it was just a matter of time. Timing around the Java initiative was coincidental.

It's also good to see that they are now eating their own dog-food: Alfresco can now host Alfresco, because they've added a new Web content management section. (Hey Matt: your CMS eval was a year and a half early!)

John's blog has an up-to-date new features list:

• Simple import of existing web sites
• Simple Xforms-based entry of XML data based upon the open source Chiba project with AJAX extensions
• Templating of XML and HTML based upon XSLT and Freemarker
• Virtual sandboxes for staging of web sites without copying files
• Timeline snapshot of web sites with zero effort
• Standard web production workflows extending the JBoss jBPM engine with group and queue support

Do you buy an extended warranty when you buy a new laptop? I think there might be good reasons for buying - and with Dell, at least, there might be a warranty scam.

Outside of computers, electrical stores push extended warranties quite hard (at least they do in the UK, I can't say I've bought a Hi-Fi, etc in the US). Clearly they do this because they make money from it and this means that for most people, the extended warranty will be a loosing proposition.

However I strongly suspect that laptops are different - I always buy extended warranties on laptops and I've never lost out so far; the extended warranty has always cost me less than repair costs.

I accept that I'm not statistically significant, so I'd be interested in your comments. I'm also aware that manufacturers must do the sums, and on the face of it you'd expect that they wouldn't be giving handouts. But hang on...

If extended warranties were a win for the laptop retailers, you'd expect then to push them harder, but in my experience they don't, and this really tells when your warranty runs out. My experience of both Dell and others of Apple is that neither of them remind you when your warranty has run out. You have to remember yourself. It's almost as if they don't want you to take them up on the offer.

Maybe laptop manufacturers have to offer extended warranties or their goods look shoddy. And they charge the most they can, but if they charge too much, their goods look like they are expected to break.

So for many manufacturers the extended warranty is a loss leader. They charge what they can, but they are never going to cover their costs.

To some extent Apple looks bad compared to Dell - it costs around 50% to insure a MacBookPro than it does for an Inspiron. Are Inspirons really that much more reliable? Maybe Dell want you to think so. Maybe Apple feel they can charge more for offering you a Genius in a black t-shirt. Either way, you should probably always buy extended warranties.

But there's more. I think there's a scam with Dell warranties.

My Inspiron recently refused to boot. Again. (To date, I've had the screen and motherboard replaced - maybe I'm up for another motherboard)

I checked the extended warranty site to discover that my warranty had run out without warning. However, I was allowed to buy another one! So it appears that you can wait until your laptop breaks and then purchase an extended warranty. If your laptop doesn't break then you win. If it does break then you get the fix for the cost of the extended warranty.

Apple seems to be wise to this - they don't allow you to buy an extended warranty once the original has timed out. Is this a scam against Dell?

In short: If you still have the default password on your router then go and change it now. Don't stop to read this post before you change it.

This post describes an attack that combines CSRF with an older technique - Pharming (see particularly the section on "Pharming vulnerability at home").

CSRF allows an attacker to script an attack on a foreign website, this could potentially be used against a user's home router to change DNS settings, and affect a pharming attack by DNS poisoning. Having altered the DNS settings for a victim, they are at heightened risk of man-in-the-middle attacks, phishing and cookie theft.

CSRF Pharming makes use of the fact that a large number of home routers have the default passwords unchanged. However default passwords are easy to find. There are several lists of default passwords in home routers published on the internet. Google ranks one at phenoelit.de highly. My guess is that something like 25% of home users have default passwords set on their routers.

Exploiting the Flaw

The victim of a CSRF Pharming attack visits a web page that has been created or manipulated by an attacker to include some Javascript that uses CSRF to pass the default admin username and password to the default IP address of a number of common home routers. Sometimes the attack is simple enough that Javascript is not required and a single iframe resource is all that is needed.

Having altered the DNS settings to query an alternative DNS server, the attacker can provide accurate IP addresses for most queries, but fake IP addresses for banking and other important services. The users are then at heightened risk of man-in-the-middle attacks, phishing and cookie theft.

The attacker can use a number of CSS based techniques to detect routers or it can simply cycle through all known vulnerable routers since each attack is fairly quick.

There are 2 methods of authentication used in most home routers: http-auth and form/cookie.

http-auth

Routers using http-auth are vulnerable to attacks from older browsers that allow URLs with the following style: http://<username>:<password>@<address>/ This allows scripted access to http-auth protected resources.

Routers from the following manufacturers use http-auth: DLink, Modern Netgear and Linksys.

For some routers a single line of HTML is all that is required:

<iframe src="http://admin:@192.168.0.1/cgi-bin/prim?attack-params-here"></iframe>

form/cookie

Using CSRF it is possible to script a sequence of URLs, although it is not possible to read the responses. Routers using form/cookie authentication are susceptible attacks from almost any web browser with Javascript enabled.

Routers from the following manufacturers use form/cookie authentication: Belkin, Buffalo, SMC, Asante, Zyxel and reportedly Older Netgear and Linksys routers.

Issues for the Attacker

An attacker wishing to exploit this problem must discover a URL sequence which affects each model of home router. Frequently sets of routers from a manufacturer will use similar firmware, so often an attack will work across a large number of router models. Knowledge of the attack URL sequences can be easily shared.

An attacker must also persuade a user to view some attack HTML. There are a number of mechanisms by which this may happen. Spyware vendors have had significant success placing spyware in many websites around the internet. Since this attack does not require the website to host binaries it may also be possible to host the attack-HTML on bulletin boards.

Protection

The only side effect of the attack is altered DNS settings in the router, so detecting the attack is hard. Detection probably involves making assumptions about the correct IP settings and comparing with those found from a lookup.

Patching home routers to protect them from CSRF attacks is unlikely to be successful since it is generally too complex a task for many users.

Altering browsers to not allow URL based http-auth will not protect against all CSRF attacks, and has been done in most common browsers.

The best current solution is for users is to change the password on their router. Since many users will know less about their routers than their attackers, this is still tricky.

It may be possible for trusted websites to detect default passwords on vulnerable routers by attempting to read a protected resource like an image, using Javascript and CSS to read image attributes like 'clientWidth', and then using the reported values to infer if the image read was successful. A trusted website could then re-direct the user to a page with instructions on how to change the router password. This technique, whist technically possible does come with some legal challenges - could this be classed as 'hacking'?

Website owners can provide some extra protection by using HTTPS. An attacker may be able to redirect web traffic using this attack, however they are theoretically not able to provide SSL certificates to match the spoofed URL. This protection does rely on user's ability to recognize correct HTTPS connections. This would be a shaky reliance.

The credit for applying these techniques to pharming should really go to Mark Goodwin who had the original idea, although Jeremiah Grossman wrote about using CSRF against network devices first; he comes very close to it in this paper without actually mentioning it specifically.

It occurred to me that there is another way of providing protection against CSRF attacks, in addition to the ones already mentioned on Wikipedia.

There are several ways to forge a request in a CSRF attack: iframe, script tag, image tag, scripted window.open() etc. As far as I know XHR is not one of these, because cross-domain rules kick in before the request is sent and not when the reply is read.

Both iframe and XHR will allow you to construct POST requests, the other attack mechanisms are restricted to GET only. With the iframe method, you use some DOM scripting to create a form that points to an iframe. This implies that only form-formatted data can be sent over an iframe POST request.

So in the Ajax world, it might be possible to have a CSRF-safe application that works simply by insisting on POST, and denying anything that is application/x-www-form-urlencoded. Clearly this technique won't work for non Ajax requests because it requires the browser to use XHR.

Obviously this is a fairly advanced technique, but it might be useful for anyone writing an Ajax library like for example DWR. I should see if I can't find a DWR tech-lead around here somewhere.

Anyone any clues on whether this might help as part of a defence in depth policy?