| |||
|
|
||
|
|||
| |
|
Home > Security News > CSI 2007: Developers need Web application security assistance |
| |
|
|
|
|
| Security News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ARLINGTON, Va. -- Security luminaries have warned about the dangers of Web 2.0 applications for nearly two years, but now it's time to help developers create safer code, industry experts said Monday during the CSI 2007 security conference.
Web application security is a major theme at the Computer Security Institute (CSI) event this year, with a full slate of presentations dedicated to the subject. Presenters repeated the warning that corporations are in too much of a hurry to offer Web-based applications that allow customers to do more business online. As a result, developers are churning the applications out with no regard for security. It's not that developers don't care about security. It's that they're under so much pressure to quickly churn out Web-based services that they don't have time to think about it, said Michael Sutton, security evangelist with SPI Dynamics, now part of Hewlett-Packard Co. (HP). He said it's time to create an atmosphere where they can write code with fewer holes. "Developers are not anti-security, but they'll only build what we tell them to build and nobody's asking them to do security," Sutton said. "That has to change." He said companies have always operated under the assumption that IT is responsible for security and not the Web developers. The problem is that once faulty applications are launched, IT can't provide the fix. The fix must occur by rewriting the code. But there are ways IT can help the developers get it right. Peer training is one example, where IT security staff can train developers to be more security-aware.
"Don't try to turn the developers into security experts because that's not going to work," Sutton said. "But you can give the folks who work in the application building and quality assurance departments the knowledge they need to find a lot of this stuff." He said the key is to make security part of every step in the development process -- planning, requirements, design, building, quality assurance and production. The best opportunity to find problems before they're baked into the final product is in the build and quality assurance phase. Loss of IT control
"When you use Web services, hackers have a much easier time getting at your legacy applications and launching attacks based on SQL injection, cross site scripting and other methods," he said. One thing many people don't realize is that in the XML world, cross site scripting attacks live on long after the initial submission to the Web site. Every time users log into the Web application the attack is launched. And, Orrin said, the attacker only has to target the Web site and not all the individual users. Since IT shops lack the resources to deal with the problem, Orrin said the best solution is for the information security community and consumers to step up pressure on those who offer Web 2.0 technology. "The big point I want you to leave here with is that we have to beat up on the vendors to make this stuff more secure" during the development process, he said. Josef Brunner, security solutions manager at Enterasys Networks, said the security problem is exacerbated by the fact that Web applications have been created in an amateur-hour setting where "everyone and their dog can create Web services and every single one of them is a disaster." Brunner expressed particular concern for how the Simple Object Access Protocol (SOAP) is used in Web services. SOAP is a way for a program running in one kind of operating system such as Windows 2000 to communicate with a program in the same or another kind of an operating system such as Linux by using the Hypertext Transfer Protocol (HTTP)and its Extensible Markup Language (XML) as the mechanisms for information exchange. SOAP is platform-independent and allows users to bypass whatever security devices are on the network, Brunner said, adding that encryption tends to be the only security mechanism for SOAP. "SOAP is very flexible and dynamic, which is always bad from a security standpoint," he said. SOAP tends to be encrypted by an inconsistent set of methods and so there's no way for security professionals to break and inspect the traffic for trouble. Making matters worse, he noted that SOAP servers are connected to critical back-end systems attackers can compromise with the right exploits. Brunner's suggestions for improving the situation include securing SOAP servers with host-based IDS to prevent buffer overflow attacks, and, above all, demanding better application security, which means training developers to do better.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
| |||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
