SQL injection and cross-site scripting remain among the most targeted Web application vulnerabilities; however, security experts say new technologies like HTML 5 come with their own set of dangerous vulnerabilities.
There's 15 years' worth of insecure Web code we need to clean up.
founder and CTO, WhiteHat Security
According to a report by Richardson, Texas-based secure cloud hosting firm, FireHost Inc., SQL injection (SQLi) attacks rose 69% between the first two quarters of 2012. SQL injection occurs when an attacker enters malicious code into a Web form input box to gain access to resources or make changes to data.
"SQL injection is by far the biggest [issue], for instances and data lost," said Jeremiah Grossman, founder and chief technical officer at WhiteHat Security, based in Santa Clara, Calif.
In the WhiteHat Security Website Statistics Report for summer 2012, SQL injection had an 11% likelihood of appearing in a website at least once. This number put SQL injection in 8th place for vulnerability prevalence.
Claiming the top spot for prevalence was cross-site scripting (XSS), with a 55% likelihood of at least one security vulnerability on a website. XSS occurs when an attacker inserts malicious coding into a link that appears to be from a trustworthy source. By clicking the link, the user unleashes the embedded programming, which is submitted as part of the client's Web request and can execute on the user's computer, often allowing the attacker to steal information.
Security experts said other vulnerabilities, although less prevalent and less dangerous than the top issues, still pose a threat. Joe Basirico, vice president of application security services at Wilmington, Mass.-based Security Innovation, Inc., said authorization issues -- when users can access information above their authorization level -- are a growing concern. Grossman pointed to business logic flaws, when two security steps clash and end up creating a vulnerability, as a problem.
HTML 5 a growing target
The newest version of standard programming language of webpages, HTML 5 seeks to make Web applications and documents equal on every type of browser. But the emerging technology poses new dangers.
Ed Moyle, senior security strategist at Town and Country, Mo.-based Savvis Inc., said the emphasis HTML 5 has on the client side continues to make attacking from the user perspective easy for cybercriminals. New technology like HTML 5 is dangerous because threats are harder to find and harder for developers to fix, he said.
"When you shake things up and start to introduce technologies like cloud, HTML 5 ... you introduce new complexities," Moyle said.
Moyle added that in terms of cases of attacks, HTML 5 is lagging because cybercriminals are sticking to the older, more widely deployed programming languages, such as Java.
Newness may be the issue with lack of protection for HTML 5, but that is not a reason for SQL injection and XSS attacks, which have been around for more than a decade. Security experts said security is not a top priority when creating a Web application. Instead, the emphasis is on speed, functionality and overall experience, said Diana Kelley, founder of consulting and research firm SecurityCurve in Amherst, N.H.
"We hear a lot about [security]. It gets a lot of press and ink," Kelley said. But, she added, security falls apart in practice when application creators realize they have to spend more time and money on the product before it can be released.
Moyle said that when an enterprise IT security team addresses security for Web apps, the money and focus is often at the network level. The company will spend money on applications, but not specifically on the security of those applications.
Lack of security-aware programmers
Some experts have found a general lack of security people in the industry.
"There's no one around to do the job," Grossman said. He added that many SQL injection and XSS attacks are targeting legacy code because old code has weaknesses left out of newer versions.
"There's 15 years' worth of insecure Web code we need to clean up," Grossman said. Still, he said that while flaws in new code can be avoided, these steps are sometimes skipped in the creation of an application.
Grossman and other security analysts named parameterized SQL statements as one of the best ways to mitigate SQL injection attacks. With parameterized statements, Grossman said only specific entries would be accepted in a Web form input box, based on the restrictions put in place by developers. In an example, he said a good statement would be, "My name is Jeremiah" while "My name is Jeremiah;" would be rejected. Because punctuation is not accepted, this prevents attackers from entering code into an input box.
For XSS, Grossman named context-aware output encoding as a good defense. Input validation is another step that can be used in securing Web applications against both XSS and SQLi.
When creating a Web application, Grossman said it is important to have security in every step of the process. He identified three roles that need to be filled to address security throughout the life of a Web application. Builders begin the process by creating secure code, breakers then come in to test and find security threats, and defenders are operationally focused, watching for attacks once a Web application has been launched.
Experts agreed that security specifics need to come from company executives. Taking time to write code properly, check it, and write extra code for security measures like input validation, will only happen if it is mandated by executives, said SecurityCurve's Kelley. Software developers are hired to do a job, she said, and if those who employ them emphasize expediency and the experience of using a Web application, then the final product will reflect that. Instead, Kelley said executives should give clear instructions on what security measures they want implemented.
When security is considered throughout the Web application creation process, it can ultimately save time and money, although it initially does not seem that way at the time, Kelley said. There have been instances at the end of the development process, when an auditor has said that the Web application does not meet certain requirements. The auditor stops production, making the development team go back and fix problems. Under these circumstances, Kelley said production could be delayed up to a week, where if the proper security steps had been taken initially, it would have only been a day or two.
Ultimately, Kelley said executives need to decide what is important to the final product. If security is important, then an enterprise needs to take every step to protect its Web application.