Looking for something else?
The "next big thing" for users is frequently the next big thing for attackers as well. So as Ajax-style applications continue to gain momentum, the security world is adding Ajax to its tools arsenal.
Today Cenzic Inc., a Santa Clara, Calif.-based provider of automated application security assessment and policy compliance testing tools, announced Ajax testing capability. Cenzic's Hailstorm, an automated penetration testing tool, and the company's ClickToSecure managed remote assessment services now both offer full support for testing Web applications built using Ajax software development technology.
Ajax support in Cenzic Hailstorm and ClickToSecure is available now. Hailstorm customers are getting the capability as a patch release.
And last week, the Denim Group Ltd., a consulting company in San Antonio, announced the public release of Sprajax, an open source Web application security scanner developed to scan Ajax Web applications for security vulnerabilities.
While industry experts say Ajax in and of itself is not insecure, Ajax-style Web applications present new security challenges. According to Cenzic, because Ajax enables more interactive Web pages that are interoperable with Web services, Ajax increases the amount of XML, text or HTML network traffic and therefore exposes applications to Web services vulnerabilities. Ajax applications may expose back-end applications that were not previously vulnerable or allow unauthenticated users to quickly elevate their privileges if there is no server-side protection.
Khera said Ajax-style applications face the same types of vulnerabilities as traditional Web applications, but the issues are magnified "because you have both client-side and server-side scripting. You have a lot more scripts than before with Ajax because there is a 'middleman' [Ajax engine] in between. You have a lot of scripts working on the back end, so those scripts are more vulnerable now."
He said there are also more session management vulnerabilities introduced. In addition, he said, "The way Ajax is coded, there are a lot of URLs hidden, but hackers know how to get to them. Developers have a false sense of security."
Khera said authentication and authorization are also problems because of the way the client interacts with the back-end server. "Most developers don't think they need to do double validation," he said.
Ajax coolness overshadowing security
Dan Cornell, principal at Denim Group, said the security issues for Ajax-enabled Web application are "just as huge" as for normal Web applications, but developers are so focused on the "coolness" factor that not a lot of attention is being paid to security yet.
"The whole point of building with this technology is so you can store an increased amount of data and processing on the client side; it's why you get good responsiveness," Cornell said. "The security danger is that because all that data is manipulated and handled on the client side, you have to re-verify all of that when it reaches the server side. You can't trust it will execute as you want it to. You need to understand the security implications."
To do so, developers needs to change their thought process to properly integrate security concerns, Cornell said. "The important thing is that security be considered, first of all. The only way to do that is to do risk analysis or threat modeling on the application." A tool like Sprajax, he said, catches security problems later in the game, when they are more expensive to fix.
Cornell said when writing any code developers need to assess the following: "Who might want to subvert this application? What are the things they might do to break it?" Then developers need to assess the risks and decide what is or isn't acceptable.
The Sprajax tool is available now for download as an alpha release. It support sites written using Microsoft Atlas framework for Ajax and requires SQL Server 2005. Cornell, who is the author of the tool but is hoping others will get involved, said the next steps will be adding support for the Google Web Toolkit and removing the requirement for SQL Server.
Charles Kolodgy, a research director for security products at IDC in Framingham, Mass., said his only concern with an open-source tool for finding vulnerabilities is that the hackers will also have access to it, referencing what happened with the Satan tool. "Originally, Satan was a scanning tool for system administrators and it became the hackers' scan of choice in the '90s," he said.
This article originally appeared on SearchAppSecurity.com.