A Security 'Patch' For Web Development Frameworks

WASHINGTON, D.C. -- OWASP AppSec DC 2010 -- A panel of application security experts here yesterday concurred that secure Web development is broken and debated ways to fix the frameworks so developers can write more secure applications.

"What if some frameworks had security features built into them that wouldn't make security an afterthought?" says Rafal Los, Web application security evangelist for the HP Software and Solutions business at HP. "What if we fixed the frameworks so it was harder to write insecure code, and that you had to [actually] purposely write code insecurely to make it insecure?"

Developers don't purposely write their Web apps insecurely -- they are just victims of the tools they must use, according to the panel, which was headed by Josh Abraham, security consultant with Rapid7. And with more developers using prebuilt development frameworks, such as JSF, Struts, Spring, and DWR, that weren't designed with security in mind, it's no wonder so many Web apps are riddled with security holes, according to the premise of the panel.

It's not that there are no efforts to help developers write more secure code: Aside from developer training efforts, there's OWASP's Enterprise Security API (ESAPI), an open-source Web app security control library aimed at making secure code simpler to write.

But ESAPI hasn't been as widely adopted thus far as its creators had hoped, and training doesn't scale, according to the panel. Chris Eng, senior director of research at Veracode, says his firm rarely sees organizations using it. "ESAPI has been around a long time, but very rarely do we run into [companies] using it. Why? It has fairly good protections. If it's baking these [protections] into the framework, why hasn't it caught on?"

Eng said he's in favor of improving the development frameworks. He posed the possibility of a framework being built to prevent developers from writing insecure code at all: "It is possible to fix things in the framework, but what if you could make it impossible for developers to write something insecure -- without them ever having to know about security?" Eng said.

Rapid7's Abraham agreed that the ideal would be for the frameworks to make it easier to build in security and harder to write insecure code.

But it's not so simple to retrofit legacy code, the panelists said. "Back-porting is a losing battle," Abraham said.

It makes more sense to build security from the ground up in new generations of frameworks, the panelists agreed.

As for more extreme approaches, such as holding developers legally accountable for writing insecure code, HP's Los said litigation isn't the answer.

Another option would be to somehow make developers accountable for their coding within the organization. "In my ideal world, developers would have to have secure code as one of their MBOs [Management By Objectives measurements]," Veracode's Eng said.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.