With more than 1 million dollars spent in R&D, Brandon's software company wasn't keen on paying an outside firm to develop its new product's site. The product manager, however, was adamant that the company outsource.

"The last thing we want to do is risk our huge investment," the product manager reasoned. "Not only could our developers overcomplicate things, but they could very well neglect key features such as search engine optimization and usability, either of which would be disastrous to a successful product launch."

While the developers certainly excelled at building complex Web-based applications, a simple HTML-only Web site wasn't quite their forte. The software company hired an interactive marketing firm to build a new site.

Blank Pages

After a few months, the marketing firm delivered the new site. All told, it looked pretty good: The site shared the look and feel of the company's existing Web site, but with its own unique color and layout. In addition, the copy that marketing developed was nicely presented around screenshots of the product.

Brandon decided to peek behind the scenes to see how the marketing company put the page together. When he viewed the page's source code, he was surprised to see a mere 128 bytes of HTML.

<html>
<head>
<script src="code.js"></script>
</head>
<body onLoad="assemblePage();">
</body>
</html>

Curious as to the kind of JavaScript voodoo that's required to build a full-fledged Web page out of a single method call, Brandon opened up code.js. What he discovered was a strange, custom-built templating system that relied entirely on client-side JavaScript.

The assemblePage() function ran when the page loaded used XmlHttpRequest (or AJAX) to get a file called header.html, which was then inserted into the page dynamically. Then the process continued with leftsidenav.html, rightsidenav.html, middle.html and footer.html. Actual content was loaded the same way, after inspecting the request URL.

What this all meant for users without JavaScript enabled-including many search engine spiders, such as the GoogleBot-was a big blank page. Against his better judgment, Brandon continued to dive further in the code.

Clearly proud of their JavaScript skills, the marketing firm's developers took another interesting approach to implementing the "contact us" form. Rather than submitting the HTML-based form through a POST to some form-mailer script, the "Submit" button triggered a JavaScript function called buildSqlStmt().

In horror, Brandon watched the function parse the HTML form and build a SQL INSERT statement. It would then use AJAX to send the SQL statement directly to the server. Hoping the developers had some sense to restrict database permissions, parse the statement or at the very least ensure that it didn't contain words such as "DROP," "DELETE," "UPDATE," or "ALTER," Brian looked at the server side handler: execSqlStatement.ashx. And, of course, the handler offered no protection. It blindly executed the SQL statement against the database.

Marketing Matters

Brandon brought these concerns to the product manager, who wasn't at all pleased that a developer was sticking his nose into "marketing matters." After several requests, the product manager finally agreed to schedule a conference call.

"I'm curious," Brandon said. "Does our new Web site support Google indexing?"

"Absolutely," the marketing firm's rep answered. "That search box on your site-we're actually using Google to do that, for free, all thanks to our search engine optimizations!"

As the rep spoke, the product manager glared at Brandon for asking such an asinine question. "Thanks," Brandon responded, feigning sincerity. "I was wondering because, when I visited the page with NoScript, it was just blank. I figured that if I couldn't see it, the GoogleBot couldn't either."

"Oh," the rep said, clearly disconcerted. "Well, uhh ... Hold on a sec." A minute later, the rep returned, adding: "Our developer just advised that we should probably remove the search box on the site."

"OK," Brandon replied. "Another concern I had was SQL injection. On the contact us page, if you ..."

"Wait a second," interrupted the rep. "Did you say SQL injection? You guys really don't have to worry about that. I mean, really, that's only a problem for the government and huge corporations."

"Yes, but it's not that hard to prevent ..."

The marketing rep interrupted again: "You see, Brandon, we're employing a brand-new technology called AJAX that makes your pages load lightning-fast, form submissions quicker and be more responsive. It's a win-win for everyone."

Brandon wasn't quite sure how to respond to that. The product manager saw that as the perfect opportunity to thank the marketing rep for addressing Brandon's concerns and ended the call.

Fortunately, Brandon was able to sneak in a handful of fixes and patches to the Web site so that it could be indexed and not brought down by a SQL-injection attack. As for the marketing firm, the word was that it was already working on version 2 of the site.

Google Botched was originally published in Alex's DevDisasters column in the Oct 15, 2008 issue of Redmond Developer News. RDN is a free magazine for influential readers and provides insight into Microsoft's plans, and news on the latest happenings and products in the Windows development marketplace.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!