Here’s how the attack appears in server logs:

The code creates a cursor of all the user tables and all the character columns in the database. It then appends a string to each of the columns, making an ungodly mess.

Mark Kruger’s post goes into a great deal of helpful detail about how this spider operates. If you do a Google search on this attack, you will quickly get a feeling for how widespread this is.

If your site is getting hammered, and you need to buy time while you fix vulnerable code, there are scripts such as this one posted in ColdFusion Developer’s Journal on August 8, 2008, which can be modified to thwart this most recent attack thus.

Be aware that this only buys time. The most effective course is to make sure your queries are protected with cfqueryparam. Ben Forta’s primer on cfqueryparam provides a very good start on protecting code from SQL injection scripts. While you’re fixing your queries, don’t forget the ORDER BY clause, another frequently overlooked vulnerability.

It can be time consuming checking all your queries if you have a large amount of ColdFusion code to wade through, not to mention nerve-racking if you are doing so while the attacks are rolling in. Fortunately there are tools such as QueryParam Scanner that will peruse your code and return a list of any unprotected queries. Unzip this application and place it in a directory in the Web root of your development server. Go to the application in a Web browser, follow its directions, and you will quickly have a report of any vulnerable queries.

• For more links on this particular attack and how to thwart it, go to http://delicious.com/rpruyne/coldfusion.

play screencast

listen to podcast

subscribe

Frequently, potential adopters of Plone at universities tell me that they have a difficult time convincing administration within their organizations that Plone — or any open-source content management system, for that matter — is worth the investment of time and effort. Or in the case of Penn State’s WebLion services, any consulting fees that may be involved.

With that in mind, I’m sharing the following example proposal for adopting Plone at the university department level. If you are striving to convince your organization to adopt Plone, feel free to make use of any part of this material for your own justification.

In this example, the department currently maintains a home-grown content management system based on proprietary tools - a situation perhaps not as widespread as complete reliance on static HTML, but nonetheless rather common. In addition, this example assumes a one-person Web shop, also a very common situation.

The Proposal

Issues with Current System

• Home grown = high maintenance. Our current content management system has served us very well through the years. However, any fixes, upgrades, enhancements, and added functionalities must be hand coded by the Web Administrator. Creating, maintaining, and adjusting Web administrative forms (used for managing Web content) can be very labor intensive. For example, it can take approximately 2 weeks to install and configure a Web-based WYSIWYG editor for use in all forms. Likewise, all public-facing pages displaying content in various ways are hand coded.
• Limited scalability and extensibility. The current CMS was built specifically with the departmental Web presence in mind and is supported by one programmer (the Web administrator). Since the CMS was developed, the department’s Web presence and related requirements have grown exponentially. This puts a strain on the existing CMS and requires an increasing amount of intervention.
• Built over top of a (proprietary) relational database.
  • This database model is not ideal for managing Web content. Ongoing alterations rely upon revising database tables along with writing, maintaining, and revising SQL queries for all additions and changes in the management and presentation of content.
  • The proprietary database server is complex to install, configure, and back up and routinely requires patches to address security vulnerabilities. It also requires two separate server boxes, one for production and one for backup.
• Built with proprietary middleware (programming software used to display Web content). With each new version, the price of this software continues increases.
• Lacks workflow and versioning. The current CMS lacks this functionality except for an e-mail notification system that pings the Web Administrator with some details when content is added or changed. It would take six months to a year to build full workflow and versioning into the databases and applications of the current system. Without workflow, content errors and problematic HTML code have the potential to go live on the Web site, to be caught and corrected after the fact. (Diligence of the Web administrator currently prevents this.) Versioning, which allows one to revert back to previous versions of Web content when necessary, also is not a feature of the current CMS.
• Lacks other higher-end administrative functionalities. The current administrative forms lack many features that would ease workload on both the Webmaster and content providers. (e.g. full Web-based image handling and full-feature placement of, and linking to, files (pdfs, excel sheets, etc.) is not present. This means that the Web Administrator frequently must step in and manage this content for befuddled content providers. As an example, editing, uploading, and placing images and their captions can take about 10 hours each week.
• All programming support falls to Web Administrator, who in turn has no programming support. This programming is far too mission critical and sophisticated to give to temporary, part-time, or inexperienced workers. Furthermore, because no one else uses this particular CMS, there is no programming/support community addressing its framework.
• Continuity regarding staffing can become an issue. Future Web administrators or Web programmers coming to the department would have to learn how the current CMS works as they go along, using in-house documentation.

Bottom Line - Current CMS

• The department has outgrown it.
• It grows increasingly labor intensive.
• It generates unnecessary expenses.
• It does not offer the functionality that an enterprise-level CMS would provide and from which the department could greatly benefit.
• It does not benefit from a larger support community.

Advantages of Plone

• Open Source. Because Plone is open-source, it is available at a relatively low cost, is infinitely customizable, and is supported by a global community with a considerable amount of cohesiveness and expertise. More about the open-source model…
• Enterprise-level. Plone provides a robust collection of tools and features out of the box. In addition, Plone is completely customizable, and its functionality can be extended by a wide array of add-on products.

Some of what Plone offers:

• Built-in database and Web server using the Zope framework. The Zope object-oriented database is ideal for Web content management:
  • Extremely flexible, not requiring constant database-level intervention when making site changes.
  • Integral with Zope framework, requires no installation or maintenance of separate engine.
  • Extremely secure, robust, and portable.
  • Does not require writing and revising database queries.
  • No hand-coding and constant revision of administrative forms. These are an integral part of the Zope/Plone environment and frankly are better than anything a lone Webmaster could build in any realistic time frame.
• Platform-neutrality, running on Windows, Apple OS, or Linux.
• Ability to work with other databases as needed.
• Workflow and versioning, RSS feeds, Site mapping, News and calendar management, and many other enterprise-level content-management tools.
• Administrative forms that are extremely user friendly (and browser friendly). These forms are integrated in such a way that even content providers with a low level of comfort with the Web can manage content, images, and other files quite easily. Plone’s ease of content management can take many hours of low-level, routine work off content providers and the Web Administrator. Example: Basic photo handling alone can take up 10 - 15 hours a week of Web Admin time. This is largely automated in Plone. Example: Helping certain content providers upload and link to files such as pdfs can take up another 10 -15 hours each week. Handling such files is *much* more simple in Plone.
• Web Standards compliance. Plone also has undergone accessibility and usability testing, generates user- and search engine-friendly URLs (not the long, unreadable, varible-passing URLs frequently generated bu dynamic sites). It is also relatively easy to customize Plone to meet organizational usability and accessibility requirements. Plone’s visual editor also strips out problematic and noncompliant code copied from MSWord and other sources.
• Add-on products. Everything from blogging, to digital asset management tools, to courseware packages can extend Plone’s functionality.
• Enormous amount of support and documentation. This is one of Plone’s greatest strengths. While Plone can involve a significant learning curve, the Plone community is vast and provides support through its extensive documentation; its online forums and chat rooms; its smaller, localized groups such as WebLion and users groups; and training opportunitiesof stellar quality.

Some additional advantages:

• No more hand coding a CMS from the ground up. Although developers always have the option to build customized Plone products, programming is minimal compared to what is required when building and maintaining a home-grown CMS.
• No costs involving proprietary middleware. Switching to this open-source product can save at minimum $5,000 to $6,000 over the next few years.
• Professional development opportunities for current Web staff. The Plone community provides many opportunities for collaboration on training, products, and documentation.
• More continuity regarding staffing. There are many, many Web professionals at within this institution and elsewhere who can step into a Zope/Plone environment at any time and be up to speed very quickly with department-specific customizations.

Summary

Adopting Plone will result in dramatically increased efficiency while saving money both in the short and long run. In addition, this powerful CMS and the related open-source community opens up numerous opportunities for the departmental Web presence and its users.

Related Links

• What is Plone?
• Plone.org
• WebLion at Penn State
• Plone Receives Kudos from CMS Watch

If your Web site has content copied and pasted from one page to another, it is very likely that Google is filtering out some or all of the involved Web pages from search results. The reason: The Google search engine does its best to optimize user experience by returning unique content. Because no one wants search results listing page after page of the same stuff.

Higher Education and other organizational Web sites tend to needlessly replicate content. This happens perhaps most frequently when information is repurposed as marketing material. The same content ends up appearing at its original source as well as at one or two marketing pages. Unfortunately, if this marketing material resides above the core content in the site hierarchy - and it usually does - it can end up replacing the core content in Google rankings.

The result is that your users, who once were able to sail directly to the information they need in its entirety and in the best context, now have to wade through marketing fodder to find it.

This can be made worse, believe it or not, if the marketing page helpfully adds a “for more information” link back to the core content. The reason: this is exactly what content spammers do. Their raison d’etre is to dump content in multiple locations with links from one content dump to the next. Fortunately Google has gotten quite good at recognizing this pattern.

What can you do to prevent replicated information from killing search placement of your critical material? There’s always the option of adding a robots.txt file to the directory containing the page you do not wish to have indexed. But to my mind, this is a skewed solution. More than 50 percent of users arrive at their destination via Web searches. So why go to the trouble to develop a Web page and then purposely block it from searches?

Better, if at all possible, is to keep redundant content to a minimum on your site. And this means redundant page titles, meta-information, and the like too - this repetition also can cause filtering. If you are still running a “text only” version of your site, LOSE IT. Switch to using Web Standards instead. Write fresh content when developing marketing pieces and similar information, keep it brief, and link to core content rather than redistributing it.

The added benefit is that you are no longer confusing your users with seemingly duplicate pages. Or, for that matter, thudding them over the heads with repetitive verbiage.

More Information:

• Google’s Webmaster Guidelines
• Google’s Guidelines on Duplicate Content
• Duplicate Content Penalty: How to Lose Google Ranking Fast
• The Perils of Duplicate Content, SearchEngineWatch.com
• Duplicate Content Issues and Search Engines
• Understanding SEO issues related to Duplicate Content
• The Illustrated Guide to Duplicate Content in the Search Engines
• Duplicate Content Issues: Yahoo and Google

If so, you will be rewarded with a wide scattershot of commentary, much of which is neither accurate nor usable.

In fact, implementing this ilk of “user feedback” can be detrimental to your site’s health.

Think about it. If you were overseeing the construction a classroom building, would you conduct focus groups and surveys to determine what materials should be used, where the doors and stairways should go, how strong the load-bearing walls should be?

No? You would rely on qualified architects?

Then why on earth would you open the door for individuals who have no understanding of how the Web works to step in and have a direct hand in your site design?

When this type of free-form user feedback enters the site design process, it sets certain machinery into motion that is difficult to manage or to stop:

• You now have a deluge of recommendations, few if any of which have come from individuals knowledgeable of the Web. You must now wade through these, looking for what is sensible and usable. And figure out what to do with the rest.
• The more disruptively opinionated of your users - and all Web sites have these - now have the expectation that they can step in and change the course of your Web site by popping off a few comments.

There is a better way. To get truly useful feedback, you must conduct usability studies.

Conducting a usability study does not have to be a difficult or complex. You do not need to set up a bank of video cameras, purchase expensive software, or wade through stacks of data. You also don’t need to employ a great raft of subjects. Remember, all users of your site have much in common, so, even if your resources are limited to conducting only three or four studies during a design or evaluation process, you will be far better off than investing time in the scattershot approach.

What precisely is a usability study? Follow these references to learn more:

• Jared Spool’s User Interface Engineering Site
• Don’t Make Me Think: A Common Sense Approach to Web Usability
• Shoot the Focus Group

Here are the S-5 slides for my presentation on this topic at the 2007 HighEdWebDev conference in Rochester, New York, on October 16.

• Scott Irvin on Configuring Ubuntu as a VMware Host

And this way to some excellent tutorial videos on using Audacity, by Jason Van Orden. These videos provided all the information I needed to get started with Audacity. While GarageBand is my preferred tool for podcasting and informal music recording, Audacity is a respectable open-source alternative.

• Part I: Introduction
• Part II: The Usability Study
• Part III: Some Observations