I am not sure if this particular long term solution to cross-site scripting (XSS) has been discussed yet, but I thought it is worth a mention since I thought of it.  Yes, I have an ego that wants to be polished daily. 🙂

The idea is to introduce 'safety' attributes to HTML and XHTML that allows web developers to disable dangerous DHTML features like scripting within elements that contains content from users.  For example:

comment entered by visitors

Fine-grained safety settings will allow some scripting features to continue working while disabling others.

This is a personal security alert against a dangerous yet increasingly popular practice which I call Voluntary XSS.  Voluntary XSS involves a website voluntarily embedding script fragments hosted by another, typically very popular, website.  Here is an example:

Voluntary XSS is dangerous because the practice builds a hub-and-spoke (or star) vulnerability network which exposes all the spoke websites to  weaknesses in the hub website.  Since active contents of 'bar.js' from the hub website in the example above is typically injected into every page served by spoke websites, penetration at the hub website allows hackers to change contents of all pages served by spoke websites instantly by replacing the content of 'bar.js' with their own script.

As to how wide spread the use of Voluntary XSS is, Google uses Voluntary XSS to display ads at Google AdSense sites and Technorati uses Voluntary XSS for blog claiming blogs.  I haven't checked Amazon and Yahoo yet, but I intend to soon.

Since this is a personal security alert, allow me to be more blunt than formal security alerts: This is serious shit folks.  By inserting those HTML fragments into your webpages, you are betting that websites hosting those HTML fragments are and will remain impenetrable.  Voluntary XSS makes those key websites very attractive to hackers and I seriously doubt any website can withstand constant onslaughts by smart hackers.

My other posts on this topic:

Cross-Site Scripting Network

APWG Threat Advisory Alert on Visual Spoofing

In my post on Anti-Phishing Working Group meeting, I said law enforcement agencies need to switch from hunter mode to butcher mode without explaining how.  While I don't know shit about how real cybercrime units operate beyond cop shows on TV, this is what I envisioned:

Operations

Instead of assigning regional cases to individual agents, create a factory line for processing cybercrimes.  The line is divided into phases and each phase has work queues.  Each phase has a director and each factory line has a controller.  The line controller works with phase directors to ensure production rate remains high by controlling the number of agents assigned to each phase and routing exceptional cases to a separate unit that specialize in cases that require special handling.

Tools

There are wide array of new technologies that law enforcement agencies can use to 'process' higher number of cybercrime cases.  For example, call-center operation technologies will enable each agents to have all the information readily available when and where they need it.  Social software technologies like wiki can be used by agent to communicate in context of individual cases across phases if each case becomes a wiki.  Workflow technologies combined with appropriate UI technologies will allow case to flow efficiently and intelligently between phases.

By hunters and butchers, I meant the contast between hunters chasing deers and butchers working in factory lines where cows enter at one end and steaks exit at the other.  Obviously job satisfaction is a critical issue but I think there are ways to keep the agents reasonably happy in a factory setting.

I was out all day yesterday to attend the Anti-Phishing Working Group meeting at Wells Fargo World HQ in San Francisco.  About one hundred people from wide assortment of backgrounds were there, some from law enforcement agencies like the Secret Service and FBI, lawyers, prosecutors, financial services, e-tailers, solutions vendors, and security experts.  APWG did an impressive job of pulling them altogether to focus on the phishing epidemic which continues to grow.

While everyone wanted to pool resources to combat phishing, I sensed a common desire to protect details about ongoing APWG activities from the public for various reasons.  Since I am not sure what APWG's policy is about blogging, I will limit this post to my thoughts and observations.

Toolbars

Warm receptions received by Account Guard feature of eBay Toolbar and Dan Boneh's SpoofGuard means more toolbars in the near future.  I predict we'll see about ten security-related toolbars released before this year is over.  Since highly integrated client-side software like browser toolbars are one of my specialties, all this is good news for me but I couldn't help worrying about the oncoming glut of toolbars, sidebars, and deskbars causing confusion among users.

Microsoft

Microsoft needs to do more to combat phishing.  Actually, they need to do 'less' by disabling or limiting use of hyperlinks and javascript in Outlook and Hotmail.  Since phishing is causing real financial damages to companies and individuals, Microsoft created an arguably very large liability exposure by introducing DHTML e-mail in Outlook.

My opinion is that hyperlinks in e-mail contents should require the user to approve each navigation after viewing a dialog that clearly indicate the link destination.  This constraint can be eased depending on the age of the hyperlinks because destination phishing websites are more likely to be takendown or abandoned over time.  I also think javascript should be disabled completely in e-mail contents to protect against new breed of javascript obfuscated webpages.

Hunters vs. Butchers

Law enforcement agencies are IMHO still in the hunter mode, meaning hackers they find and prosecute are more or less trophies for assuring the public.  Seen as services, they are open to denial of service attacks by organized hackers arming script-kiddies to overload or slowdown cybercops.  They need to think about ways to shift-gear from hunter to butchers mode now, if not just against phishers, then for homeland security.

Takedown.com

Most difficult part of fighting against phishing is taking down phishing websites.  Differences and confusino in law and legal jurisdictions, cross-language communication issues, availability, authority verification problems, and other issues make taking down a fraud site a skill or an art of social networking, ingenuity, and patience which most companies do not have.

Solutions suggested so far like contacts and standards are useless IMHO.  A more effective solution is to encourage entrepreneurs to startup federated or franchised businesses to offer takedown services around globe and around the clock with the local touch.  Having middlemen like them solves most of the issues mentioned above.

Spoofback

Considering the difficulty with takedown, another options is to 'spoof back' by posting phony information to the phishing websites in order to spoil the goods by diluting it with bad info.  Instead of receiving 3,000 good responses, phishers will receive 300,000 responses most of which will be bad.  Another variation is to post user info leading to honeypots in order to phish the phishers.  I am not sure about the legal issues, but hackback risk is no worse than the takedown IMHO.

APWG Future Threat Models SIG

I have volunteered to participate in the Future Threat Models SIG at APWG because I am both highly creative and insanely paranoid which means I can see blindspots where none exists.  :-)  I probably won't be posting about the activities there but I will post my thoughts and publicize imminent threats like the XSS Network threat I posted about before.

News.com reports on the need to secure XML and Web Services.

Many years ago, David Megginson talked about new kinds of security vulnerabilities created by XML, primarily through it's careless use of external resources such as DTDs and entities, at an XML conference.  At the same conference, first BoF meeting on SOAP was held.  Since then discussions over security surfaced occasionally among XML geeks but no one else really noticed until now.

The rise in the number of articles like this one is, IMHO, driven by security companies extending their reach into XML and web services market and not by increasing hacker activities against XML and web services.  Vulnerabilities are real, thanks to careless adoption of XML and web service technologies by mainstreamers and the general lack of awareness by XML developers, but hackers are not likely to come knocking at those vulnerabilities.

Why?  Because, if vulnerabilities in HTML-driven websites and web applications are antelopes and zebras, vulnerabilities in XML and web services are like monkeys and gophers.  Why would lions climb trees or dig into gopher holes when there are millions of more attractive preys?

Of course, some hackers will come knocking but developers can easily move higher up the tree by using hardened manageable XML processors and web service engines which will emerge out of the glut of feature-happy, vulnerability laden XML and web service tools accumulated over the past 7 years.  Education and awareness is what the market needs most of all, not expensive boxes or software peddled by security companies.

I will add XML and web services vulnerabilities to my stable of post topics as well as discussing the real dangers of web services arising out of increasing ad-hoc dependencies among web service providers.