"Take a look at this bug," said Victor's boss. "It'll be a good way for you to learn our code base."

Always a fan of the hands-on approach, Victor agreed. He pulled up the code and took a look, expecting to see a nicely bulletproof application. The system was a hosted service that allowed customers to store very sensitive technical data. The interview process had stressed exactly how sensitive the data was. "Security is job one," the boss said. "We spent a great deal of time and effort to make sure this was as secure as we could make it, and I need to make sure that you'll comply with secure coding practices."

What Victor saw in the code base was slightly different than what was on the label. The code was bad. Not "oh, they have inconsistent standards" bad, but "somebody copied and pasted classic ASP code into .NET and then mucked with it until it worked" bad. There had been a token attempt to make it look sort of like object-oriented code, and that token attempt simply made the code less readable and more difficult to maintain.

As Victor read through the code, he paid close attention to how it implemented security. While he hunted for the bug, he found many security flaws. Each time he found one, he stopped by to talk to his boss.

"Hey, I noticed that none of the browser fields are sanitized. Someone could perform an XSS attack on us."

"Is that the cause of the bug?"

"Well, no," Victor said, "but I thought-"

"You're not here to take a field trip through our code," the boss said. "Fix the bug."

An almost identical conversation happened when Victor spotted a query like this: String strQry = "SELECT a, b, c FROM data WHERE x = '" + pstrOne + "' AND y = '" + pstrTwo + "'".

That was bad, especially since all of the super-secret client data lived in the same database. Nothing was segmented and everyone at the company thought "VPD" was a special kind of veneral disease, which meant trivial SQL injections could easily slup other customer's data. Of course, a malicious user didn't need to work that hard.

The passwords were stored in ~/passwords.txt in plaintext key/value pairs: 5,[email protected],hunter2. Any malicious user could simply grab the plaintext file and log in as anyone they liked. But they didn't even need to work that hard.

The only screen that contained any authentication logic was the login screen. It didn't write any session information or any cookies out. It simply checked the supplied credentials against the passwords.txt file, and if they were correct, it redirected the client to the home page with a URL parameter: UserID=5. One could bypass authentication entirely by bookmarking the home page, and a malicious user could impersonate anyone else simply by changing the URL parameter.

Armed with these fatal flaws, Victor approached his boss one last time.

His boss sighed, sadly. "Victor, I really don't think you understand the security needs of this application. You're focusing on the wrong things. We're going to have to let you go."

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