Unfortunately, there seemed to be a problem with the new security feature: it wasn't working...or at least, so it seemed. As it turns out, the problem was that users weren't informed as to how to properly activate the anti-phishing protection, an issue that points to a poor implementation of what could and should have been a major breakthrough in mobile computing technology.

Although Apple touted the anti-phishing protection back in March when they announced their 3.0 update, the new feature didn't actually materialize until this month when the company released the OS 3.1 iPhone/iPod Touch software. According to Apple, the anti-phishing protection feature will display an on-screen warning message when you attempt to visit a known malicious website.

Once the update was released, security researchers and other Apple enthusiasts began testing the new technology. The results were immediately disappointing. "I've not been able to get it to block anything," Michael Sutton, vice president of research at security firm Zscaler was quoted as saying. He had been testing the feature using known phishing websites identified by the anti-phishing database hosted at PhishTank. The Mac Security Blog also found after extensive testing that it simply "does not seem to work." MacWorld, however, found that the feature worked sometimes, but the inconsistency hinted that the technology was not "ready for public consumption," they reported.

What gives? Did Apple really release a broken feature? Were they even aware of the problem? Blogger Jim Dalrymple of The Loop decided to go straight to the source: he asked Apple.

Apple Says "You're Doing it Wrong"

Apparently, this was not a case of the anti-phishing technology being broken. It was a case of everyone simply "doing it wrong." As it turns out, in order for Safari's anti-phishing database to update, there are a few particular steps that need to be followed, explained an Apple spokesperson. After updating the phone to the OS 3.1 update, users need to do the following:

1. Launch the Safari web browser.
2. Connect to a Wi-Fi network.
3. Charge the iPhone with the screen off.

The spokesperson added that for "most users" this process should happen automatically when they charge their phone. We would have to disagree. "Most users" don't launch the Safari browser prior to charging their device - if anything, they close down any open applications before plugging in the phone to charge.

Poorly Implemented, Poorly Explained

If you follow the above steps, the feature will work. However, most users will never know to do this unless they happen to closely follow technology news and blogs. The general mainstream population - the very demographic Apple so craftily attracts via their billion dollar marketing campaigns - expects things to "just work." That is the Apple promise, after all.

Yet even on Apple's own website where they detail the various new features in the OS 3.1 update, there is no mention as to how the anti-phishing protection should be utilized. It simply lists that the feature exists. A helpful link to a "how to" guide would seem appropriate here or, at the very least, a footnote.

Having to perform the somewhat unintuitive steps to get the anti-phishing protection feature to function properly seems like an unusual miss for a company who generally makes things simple and straightforward. Why does it need Wi-Fi, for example? Apple claims that the Wi-Fi connectivity is required so as not to incur any additional data fees for the end user. But launching the browser? We almost wonder if it wouldn't have made better sense for Apple to implement the feature in the new iTunes update instead. The desktop software could retrieve the updated anti-phishing database from the internet upon launch and could then sync it to the iPhone or iPod Touch the next time it was plugged in. That would also alleviate another common problem with the current implementation - if the phone isn't plugged in long enough, the update won't complete and users will only be partially protected. On the other hand, the inclusion of the database via a sync would have ensured that all the data was copied over to the phone.

In the end, though, Graham Cluley, a senior technology consultant at Sophos, reminds us that maybe we shouldn't be too hard on Apple. "Many other smartphones don't offer even the most elementary form of anti-phishing protection to their users," he says. That may be true but, unfortunately, the way Apple chose to deliver their anti-phishing protection feature means that most iPhone users won't be protected either.

Says Sophos' Senior Technology Consultant Graham Cluely in a blog post, "The bogus warnings look near identical to previous fake anti-virus software attacks that we have seen in the past - with a scrolling green progress bar and a list of alleged threats found on your computer displayed in a dramatic red colour scrolling up."

Phishers are designing site pop ups that mimic system anti-virus warnings in order to lure users into giving up personal information and in some cases, downloading malware. According to the Anti-Phishing Working Group more than 9000 scareware packages have been in circulation since late 2008.

For a list of some of these potential issues, check out ReadWriteWeb's Top Online Security Threats for 2009 or visit the US Computer Emergency Readiness Team site for industry updates.

During tests this weekend, we discovered the company who claims to "keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams," has several cross-site scripting (XSS) vulnerabilities and provides the bad guys with a brilliant - albeit ironic - launching pad from which to unleash their attacks.

It can't get much worse than this. This is not "yet another embarrassing incident on the Web;" not by a long shot.

Lance James, co-founder of Secure Science Corporation and author of Phishing Exposed, noted that when a criminal locates an XSS vulnerability within a well-known Anti-Virus site, it only makes the attack more effective. "It generates misplaced trust (being that computer users trust AV companies) and is paradise for miscreants involved in Scareware (Rogue Anti-Virus) distribution, as they can infect a legit copy of MacAfee's product and distribute it under their name." James said. "A win for the bad guys through the power of branding; a major loss of trust for McAfee," he added.

Not only do security vulnerabilities harm a company's brand, they can also ultimately harm its bottom line, particularly when the company in point has made millions from the software it produces to protect you online; this will surely injure the McAfee brand.

It all began when we came across a post that described some of the issues facing McAfee. Very quickly, we realized the potential for phishing on one of McAfee's sites, the McAfee Rebate Center, which allows you to inject HTML code into one of the fields it provides on its site.

If you've never seen an HTML injection in action, try this out, it's an interesting experiment.

How To: HTML Injection

1. Go to the McAfee Rebate Center
2. Click on Get Rebate
3. Include this line of code into the 'Date Purchased' field:
   
4. Click on continue

This is a very basic redirect that will take you to ReadWriteWeb.

And voila - you've just effected your first HTML injection.

Although our example is extremely simple; a no-brainer for clever coders, it illustrates a significant and more sinister point: McAfee is clearly vulnerable to XSS attacks. Much like the recent Mikeey worm on Twitter, this XSS issue is a result of poor output filtering. And while Twitter can be forgiven for not laying down the correct foundation in the beginning, the same cannot be said of McAfee, which has built its entire business around its knowledge and expertise in the field of information security.

McAfee Secure May be Providing Incorrect Information to Users

And it gets worse. McAfee has a product called McAfee Secure which helps corporations determine whether their sites are open to malicious attack. The way it works is that sites participating in the McAfee Secure program are checked daily, and if they pass muster, they receive a McAfee Secure badge which is branded with the day of testing.

Unfortunately, it appears McAfee either doesn't run McAfee Secure across all of its sites, or if it does, the product is missing the bleeding obvious.

From the https, to the McAfee domain, this phish site that James created even includes a valid and dated McAfee Secure certificate.

To demonstrate how easily the exploit can be used, James created a phishing site to give ReadWriteWeb readers a real-time example. Go ahead, follow this link, and click on the "add to cart" button (we promise it won't hurt you).

What you are seeing is a cross-site scripting exploit in action. "Imagine," James said, "just how easy it would be to exploit home computers with Trojans that cause harm or steal information." A phishing site, like the one he created, could easily ask you to click a link for more information. "Or," he said, "imagine the e-mail: 'you're eligible for a McAfee rebate on your products, just click here!'" "Basically, the main use I see it for is to spread malware as McAfee."

What he's describing is ominous. The bad guys can create a modified version of a McAfee product or a bogus McAfee update that installs a Trojan, or whatever they like, and it arrives on your home machine, special delivery. You'd never know.

In creating the fake site, James points out that he didn't need to spoof the McAfee Secure logo. "We're using their certificate to validate our attack," he said.

Go ahead. Look up at the URL on the phishing site. See that https://?

Secure right?

Note: We've created a screencast (embedded below) of the redirection exploit for when McAfee fixes this; we hope it's soon.

Update May 5, 2009

It appears the vulnerability on McAfee's rebate site has been fixed; however, the test phishing site is still going strong. James gave us an update: My assumption is that remote referrers are blocking it based on firewall rules but a refresh locally shows it's still vulnerable. An attacker can simply do a meta refresh to redirect to it since that scrubs referrers.

Currently, national information security responsibilities are divided between the Department of Homeland Security, the Department of Defense, and the National Security Agency. The new National Office for Cyberspace would involve cooperation between all these agencies as well as from the private sector. Potential costs of the new office and related initiatives are as yet unknown.

Areas of federal concern span government agencies and private enterprise, from ISPs to oil and power companies.

Alexander Howard, associate editor of SearchCompliance.com at TechTarget, cited the Joint Strike Fighters Program attack as an example of national susceptibility.

"National security organizations are aware of the risk to our infrastructure," he said, "and our defense is currently not well coordinated."

Both Howard and Gourley named Russia and China as having coordinated cyber espionage efforts and the ability to launch attacks with the potential for costly results. And no one is overlooking the possibility of attack from extranational terrorist groups.

So, How Much Is This Going to Cost?

Will the government subsidize any information security measure in the private sector? Howard said, "It's not clear who is going to get how much of the budget, but the lack of security is costing us all as it is."

By way of example, Howard noted that 10 million people had their identities stolen in 2008; he continued that such measures can be thought of as preventative health care for information security.

Fortunately, there are relatively inexpensive steps private organizations can take to improve their security; Gourley hopes Common Audit Guideline compliance will be part of new security measures.

He also cited cloud computing and open-source software as being "less expensive and more secure" and cited certain commercially available processors as having "capabilities that information security professionals have dreamed about for years."

The Big Brother Question

Although the creation of a national information security office will mean more regulation, oversight, and filtering of Internet traffic, Howard said, "There is a palpable feeling of excitement about national cyber defense."

So, Who's the Lucky Fella... Or Lady?

Gourley imagines the position will call for "an information security superstar... with the national stature of a Colin Powell, someone who can really get things done."

Howard raises the point that the need for top-level security clearance might necessitate a candidate from inside the intelligence community.

The ICE Act will be presented before the Senate tomorrow; full text of the Act should be available through the Library of Congress' THOMAS page or through Sen. Carper's site.

It shouldn't be this hard, Peter Soderling, founder of Stratus Security told ReadWriteWeb yesterday. "It appears Twitter is solving the problem by focusing on the input filtering, but a simpler and more effective solution would have been to focus on output escaping; encoding the script tags so they could not execute in any victim's browser."

Input Filtering in Plain English

Input filtering is the way in which developers validate data coming into their applications, and thwart any invalid, incorrect or malicious data from being used or executed.

Typically, when an application needs a user to input data, the site will offer a form, containing one or more fields.

For instance, Twitter users have the ability to input data in a variety of places within their settings. From the obvious - such as in the account tab - where you can type in your name, username, e-mail, URL, bio, location etc., to the less obvious such as the 'change design colors' that allows you to enter data to specify color.

As a result, all of these fields need to be 'filtered' by the site - not just by making the input validation 'nice' for the user [as described below], but making it safe on the server.

From a user point of view, when you go to change the background color for example, Twitter has ensured you can only input 6 hexadecimal characters; that is, the letters A through F and the digits 0 through 9.

While this may provide users with a sense of relief that nothing malicious can be 'injected' into this field, it may also be providing a false sense of security if Twitter is not filtering the input on its servers.

Here's why.

When you hit the 'save changes' button after you have input your data, your browser sends that information to Twitter's server, which in turn will then store that information.

But what if the information Twitter's server receives tells it to do something malicious? And, what if Twitter's server thinks that the information it has received was from the form where nothing 'bad' can be entered? This is what Mikeyy did. "It basically let me do anything I want within a browser on their Web site," Michael Mooney, the worm's creator, told Andy Sorcini in an interview last week.

Think of it this way. You're sending ReadWriteWeb a letter via snail mail. The postman steams it open, rewrites it and delivers it to us. The information we receive, while still appearing to come from you, may have nothing to do with the original information you sent us.

But how do you send information to Web apps without entering them in the specified fields? Simple, if you have the tools. Programs such as Paros, a security tool created for Web application vulnerability assessment also allows those who are tech savvy enough to monitor, intercept and modify the data being sent to Twitter before it hits Twitter's server.

Of course, this means Twitter is now storing information - not about a color, but potentially, instructions to do something malicious.

Input Filtering at a Server Level

When Twitter's server receives a request (such as to change the background color), it must validate that the information received corresponds to the values Twitter has assigned to it. Continuing with the color example, it must validate that only hexadecimal data has been received.

Clearly, Twitter did not do this from the get-go and is now furiously chasing input vulnerabilities that may be sprinkled in a variety of places within its code; patching them as it finds them; a long, painful and tedious process when done retrospectively.

Think of it this way. A mouse is in your house. You search to find the hole in the floor and you plug it. Then you find another mouse. Again, you search for the hole and plug it. This can go on indefinitely. However, had you, during the building stage, put down a concrete floor, there would be zero chance of mice living under your house, and fewer ways they could get in.

"Understanding why and where to filter is more important than understanding how," Chris Shiflett, CTO of OmniTI explains. "It's important to appreciate just how easily a form submission can be spoofed, so that you realize that absolutely nothing about the client's request can be blindly trusted." He has written a good technical overview on input filtering if you are interested in learning more.

The Flip Side of the Coin: Output Escaping

Output escaping, much like input filtering, is an additional precaution that developers can take when creating Web applications.

According to Soderling, it effectively renders any malicious code that is stored in a database useless.

Rather than focus on plugging holes in the input one by one, Soderling suggest Twitter focus on escaping outputs, which is easier from a developer point of view because it effectively requires only five steps to implement.

So simple in fact, that PHP, a common programming language, has created htmlspecialchars to automate this process in the PHP world.

"All Twitter needs to do is code the script tags so they cannot execute in any browser," Soderling explained. "This particular type of attack is not entirely uncommon."

And while it is likely that the majority of sites in the world are vulnerable, Twitter, with its team of capable developers should be better locked down.

However, Twitter is not alone in this. Guillermo Rauch found a similar vulnerability in Digg today that he tested and quickly alerted Digg to (Digg has since fixed the bug). You can read about the process here.

Whether Twitter is dealing with this problem by focusing on input filtering or output escaping is still to be determined. We've sent them an e-mail in an attempt to find out more and will update this post as soon as we hear back.

Dubbed GhostNet, the operation is notable. Not only can it phish for information, it has remote access capabilities that can quickly and easily turn any computer into a giant listening device.

While researchers believe the operation is based in China, they are quick to point out that this does not necessarily mean the Chinese government was involved. "This could well be the C.I.A. or the Russians. It's a murky realm that we're lifting the lid on," Ronald Deibert, an associate professor of political science at Munk told The New York Times.

The researchers' findings, Tracking GhostNet: Investigating a Cyber Espionage Network, are due to be released this weekend on the Information Warfare Monitor Web site.

While some news outlets are causing panic with their fear mongering, others are downplaying the upcoming event, and the net effect of course is FUD. But according to security experts, the bottom line is if you're not infected now, you don't have anything to fear come April Fools Day. If you're interested in knowing more about Conficker and how to search for and destroy it, take a look at the seven resources below.

The Last Watchdog has compiled a simple timeline to show the evolution of Conficker that begins with Chinese hackers selling a $37 malware kit in September 2008 designed to exploit a security hole in Windows, and ends with what infected PCs will do come April 1 2009.

Conficker C Analysis

The computer science laboratory at SRI International, sponsored by the National Science Foundation and the U.S. Army Research Office, has released a detailed analysis of Conficker C.

Ensure you've got the latest Microsoft patch

Microsoft recommends you manually download the Windows Malicious Software Removal Tool. Note: This is not a replacement for anti-virus software, rather an additional defense.

Disable Autorun

PC World suggests disabling Autorun so that your machine won't be automatically infected when you connect to infected removable media. A how-to can be found here. Note: This involves changing the registry file on Windows and should only be done by those confident in their abilities.

Search for and destroy Conficker with F-Secure

F-Secure has a free and easy-to-use tool to check for and remove worms; including the dreaded Conficker.

Use McAfee's Stinger which will update daily in preparation for April 1

McAfee has created a special build of its standalone cleaning tool Stinger which it will be updating daily to include any new Conficker variants.

No Download: Scan on the Web

Create a free account (registration required) with Panda Security's ActiveScan to perform an online scan of your machine.

Image Credit: Flickr: Jean et Melo

Enter Fortify, a software security company that has organized security issues by both vulnerability category and by language so developers can easily ascertain the types of errors that have an impact on security.

A Taxonomy of Coding Errors that Affect Security borrows terminology from biology: vulnerability categories (for instance, Cross Site Scripting and Buffer Overflow) are referred to as phyla, and collections of vulnerability categories that share the same theme are referred to as kingdoms (for instance, Input Validation and Representation).

According to the site, vulnerability phyla are classified into "seven plus one" pernicious kingdoms presented in the order of importance to software security:

1. Input Validation and Representation
2. API Abuse
3. Security Features
4. Time and State
5. Errors
6. Code Quality
7. Encapsulation
8. *. Environment

Important to note, issues 1 - 7 are associated with security defects in source code, while 8 describes security issues outside the actual code.

Languages covered include Cold Fusion, C/C++, C#/VB.NET/ASP.NET, HTML, Java/JSP, Javascript, PHP, PLSQL/TSQL, Visual Basic/VB Script/ASP, Webservices, and XML.

A Taxonomy of Coding Errors that Affect Security was developed by the Fortify Software Security Research Group and Dr. Gary McGraw, and complete descriptions with source code examples can be found here.

In tests, the reason that the TinyURLs were able to be used in this way is because the pages they masked were not at the domain level, but were rather sub-pages of a domain marked as "safe." This actually points to a weakness in the Safe Browsing feature and not really a security risk in the TinyURL service in and of itself. Because Safe Browsing only ranks sites at the domain level, infected sub-pages will always be ranked as "non-malicious" as long as the domain is categorized as "safe."

TinyURL isn't the only service being abused in this way. Other URL-shortening services mentioned in the article include bit.ly, w3t.org and is.gd. However, during their research, the firm also found bit.ly being used by the same cybercriminals. Both TinyURL and bit.ly were notified and the malicious links were removed.

For many users of Google Docs, that answer is "no." According to Google's Help Topic on SSL as well as their Google Apps Edition comparison guide, SSL is a feature only made available to users of Google Apps Premier and Education Editions. However, in some informal testing on our part, it appears that users of Google Apps for Your Domain were given that option as well, despite the fact that their Google Apps edition clearly reads "Standard." For everyone else, though, Google Docs remains an unencrypted HTTP session.

In a business or educational setting where Google Docs is being used, your I.T. admin has probably turned on SSL for you by activating the feature that forces SSL sessions for all users. If they have not, though, you can still switch on SSL for yourself, says Google, but their help documentation fails to explain how that can be done. All the documentation says is that "your users can enable HTTPS when necessary."

What they probably mean is that anyone can type in "https" when entering in the URL for a Google Apps service in the address bar of their browser. Since your average internet user doesn't think about these sorts of things, though, that's probably not the best solution in terms of security.

While we hope that any I.T. admin in a corporate setting knows well enough how to enable a basic security feature such as this, it would still make us more comfortable if these sorts of things were enabled by default. The only reason to not enable SSL is because it can slow down your connection to Google services. Still, in the event of network issues, I.T. admins could temporarily disable this feature to speed up access for their users. But Google hasn't chosen to make security the default - they've chosen speed.

Outside of Google Apps, everyday users of Google Docs don't have an option in their Google Docs settings to force the service to always use SSL. Like those with a neglectful I.T. admin, these Docs users would have to remember to type in the "https" prefix if they want to use a secure connection.

SSL Implemented Haphazardly

Manually typing in "https" is all well and good, but let's face it - most users won't ever know to do this and those of us who do know won't remember. Not only is this process laborious, it's inefficient, too. For example, those who want to take advantage of the Gmail Calendar and Docs widgets, which allow for one-click access to other Google services from within Gmail, would have to forfeit a secure connection in order to do so. The only recourse would be to not use the widgets at all, and that certainly disrupts our workflow.

However, if you've enabled SSL within your Gmail settings, connections to your other Google services will also be encrypted if you use the navigation bar at the top left of your Gmail...but only if you use the navigation bar. Even when signed into your Google account, typing in "docs.google.com," "calendar.google.com," or using the Gmail widgets will still take you to the HTTP site.

At Least They Have SSL...

What's really unfortunate about this potential security issue is the fact that Google is actually leading the way among webmail and web app providers when it comes to offering SSL to its users. Although other free webmail services from Yahoo, Microsoft, and AOL, for example, may authenticate you upon login via HTTPS, they drop down to unencrypted mode immediately after the authentication is completed.

However, it could be argued that those other services are not claiming to be a secure replacements for business use. Since Google promotes Apps as a web-based alternative to expensive desktop software, many people mistakenly assume that means Google services are, in general, "pretty much" secure for personal use, too. Apparently, that's only true to a point.

It's also worth pointing out that nothing, not even SSL, can keep a determined hacker out of your account. As ZDNet reported at the beginning of the year, even SSL can't keep blackhats from hijacking your session through the use of "sidejacking," a trick that enables hackers to take control of any Web 2.0 app that relies on saved cookie information. (There have also been other reports of Google Docs security issues, but we couldn't reproduce the problem.)

Providing SSL to everyone is the least Google could do. And to the other webmail/web app providers out there: it's time you followed suit.

There are many free public alternatives to TinyURL, some with better ancillary features (see elfurl.com for just one example). The name TinyURL is very literal and memorable though. I use SNURL more often, myself.

It's not good when so much of the web runs through a single service. For some, politics could be a consideration as well as technical considerations. The man behind TinyURL, Keven Gilbertson, uses his hugely popular website to promote US presidential candidate Ron Paul, which I personally find somewhat distasteful, and encourages people to use TinyURL to obscure affiliate links on their webpages - which strikes me as extremely distasteful. Presumably a Paul supporter would want our redirects to run wild and free too, unbeholden to a centralized service provider capable of holding us under its thumb (I joke, but really.)

If there was some sort of distributed standard or tool that could be good as well. The Online Computer Library Center (OCLC) has run Purl.org (Persistent Uniform Resource Locator) since the 1990's but user experience there is something only a librarian would put up with. A public institution solving this problem gracefully might be as realistic as it would have been for the Library of Congress to have acquired Del.icio.us (my fantasy) instead of Yahoo!

The moral of the story, though, is that it isn't supposed to work this way. There ought not be one single point of failure that can so easily break such a big part of the web.

You may remember that R/WW covered the Q3 Finjan report, which outlined threats to Web 2.0 and Ajax websites. The Q4 report extends that theme and notes that the dynamic nature of the Web complicates security going into 2007. It states:

"2006 saw the arrival of a diverse range of web-based infection techniques -- including rogue anti-spyware, ransomware, and rootkits -- that elude traditional security solutions geared to protect against email viruses and spam. Another development in 2006 was the commercialization of malicious code, as financial motivations played an increasing role in the evolution of malware. Motivated by financial gain, hackers are trading vulnerabilities in online auctions, commercializing products such as malicious website creation toolkits, and developing new distribution techniques, including spam, for the propagation of malicious code."

Finjan predicts that in 2007, Web 2.0 platforms and technologies will increasingly be used by hackers as a "legitimate" tool for distributing malicious code. Also they predict that, as Windows Vista and Internet Explorer 7.0 begin to achieve critical mass, this "will likely trigger a new wave of exploits from professional hackers who have had time to prepare in advance for this scenario."

Regarding the two specific Web 2.0 cases discussed in the report, the methods used involved spam and phishing. Firstly here is the Wikipedia case:

"This scam was detected and published by Sophos in early November 2006. Taking advantage of the fact that Wikipedia allows anyone to create and modify articles, hackers uploaded an article to the German edition of Wikipedia (de.wikipedia.org) including a link to a fix for a supposedly new version of the Blaster worm. However, the "fix" was actually a piece of malicious code. Sophos discovered the scam by intercepting spam messages directing recipients to the Wikipedia article with the malicious code.

Alerted to the problem on their site, Wikipedia immediately fixed the page with the malicious link. However, according to Sophos, the previous version of the page was still present in the archive and continued to point to malicious code. This allowed the hackers to continue to send spam pointing to the archived page on Wikipedia, and infect victims' computers. Wikipedia later confirmed that it had permanently erased the archived version of the page."

And the MySpace case:

"In another incident reported in early December 2006 by Websense, hackers compromised the MySpace social networking site and infected hundreds of user profiles with a worm. This malicious code exploited a known vulnerability to replace the legitimate links on the user profiles with links to a phishing site, where victims were asked to submit their username and password. In addition, according to Websense, the worm embedded infected video in victims' user profiles."

Finjan writes that Web 2.0 has "opened the door to new propagation methods for malicious code." They also claim that since the vast majority of these sites are considered "trusted" or legitimate by URL Filtering products, "they will not be blocked despite the fact that they contain malicious code." Finjan notes that the term 'infection by proxy' was coined to describe this attack vector using Web 2.0 sites.

Hack for Dollars

What's perhaps most concerning about this report is Finjan's contention that hackers nowadays are focusing a lot on web-based infection techniques - and that a commercial market has evolved around this. Whereas in the 'old days' the motive of hackers was to gain fame, today it is all about the money. Indeed Finjan says that commercialization of malicious code was the most significant trend in the web security arena during 2006. Here's a graph from Finjan illustrating this:

So this is something to be wary of for web apps and service providers. Along with Web 2.0, we now have Hacking 2.0 to contend with!

Finjan acknowledges that Web 2.0 and AJAX technologies enable a rich user experience for Internet users, but they warn: "the technology also flings open the door to new malware propagation methods." How so? Because hackers are targeting high-traffic web sites and either embedding malicious code in hosted Web content, or using AJAX to query what Finjan calls "the hidden web".

Also the report shows that content of websites distributing malicious code is being duplicated on storage and caching servers used by ISPs, Enterprises and leading search engines. This means that malicious code is available and can be referenced by third party web pages to exploit an end user's machine - even if the original malicious website has been taken down.

I've asked Finjan to send me the full report, but I thought in the meantime it's worth throwing the question open: have you ever experienced a web security breach on a web 2.0 or ajax service? Particularly on a "high traffic site" - which I take to mean a MySpace or a YouTube. What hacking stories do you know of in the web 2.0 space?