“This one’s going to be a little different,” Tom said.

Rich agreed, although for the wrong reasons. He thought it was going to be different because this was their first really big contract. Rich worked for Tom at a “new media” company young enough to have that “new company” smell. They had just landed a contract with Initrode to add some major features to their website.

“It’s more different than you think,” Tom said. “They’re happy with their hosting company. They trust that vendor’s security more than ours, apparently. You’ll have to work with them.”

“That shouldn’t be a problem,” Rich said.

And it shouldn’t have been a problem. But the hosting company wasn’t just a web host- they were also the company that until recently done 100% of the work with Initrode’s website, and they weren’t particularly happy about the lost business.

Rich didn’t realize what this meant until he tried to get the first batch of changes deployed. Everything ground to a halt. “I’m sure Initrode already explained,” his contact said, “that security is our strong point. We’re a very secure system. So before we can deploy your code, we need to audit it. That’ll take 4–6 weeks.”

Rich agreed, because what else could he do? This lead to an anrgy message from Tom: “The client is very angry. According to the host, your code wasn’t secure enough to be deployed. What’s going on.” Once Rich explained the reasons, Tom understood. Unfortunately, the most help he could give was to say, “It is what it is. Do your best.”

The second time Rich tried to get code deployed, they put files in the wrong directories and then blamed Rich’s instructions. “~/ and ./ are confusingly similar. The instructions should always use absolute paths.” Rich would have been happy to use absolute paths, except for the fact that the hosting company refused to tell him the path structure of the server. After all, an external vendor could abuse that knowledge and security was all important.

The third time Rich tried to deploy code, the host kicked it back. “That’s a JavaScript file, and we don’t allow scripts on our server.”

“What? The screens you’ve already built heavily use JavaScript .”

The voice on the phone sniffed and countered, “I mean from untrusted vendors. It’s far too risky from a security standpoint.”

Frustrated, Rich wasted some time browsing the existing site, assembled by the hosting company. One page allowed image uploads, and it didn’t take long for Rich to notice that it allowed him to upload any kind of file. For laughs, he used it to upload the Forbidden JavaScript. Not only did the server happily accept the upload, it equally cheerfully served the script up.

As an extra test, Rich uploaded a PERL script that was nothing more than a simple command to move the JavaScript file from the image uploads directory to the section of the site he wanted it to live in. When he requested the URL, the server did what he suspected it was going to- it executed the script.

At this point, Rich could have easily completed the project without ever talking to the hosting company again, simply by writing some simple PERL deployment scripts. Instead, he decided to be responsible and told Tom. Tom called Initrode, Initrode called the hosting company, Rich got dragged into a conference call. The screaming could barely be heard over the sound of contracts breaking. When the din finally died down, three things happened:

Initrode moved their site over to his employer, bringing with them a big checkbook and the promise of steady work. Tom, for his role in getting them to move, got a big bonus and a parking spot right next to the CEO’s. Well, not next to, but still- close to the building. He could see the CEO’s car from where he parked, if he brought binoculars.

The old hosting company wasn’t too happy with this situation, and they threatened legal action against Rich’s company for “hacking” their server. Rich’s employer knew exactly what they had to do: they fired Rich.