With estimated worldwide cyber crime losses in 2011 over $388 billion, corporations, both large and small, are focusing considerable attention towards the security of their physical infrastructures as well as their outward facing web applications. While most physical infrastructures have been secured, there are still many critical security vulnerabilities in the majority of web applications. In this “Case Study” column I will share some takeaways based on my involvement in two recent remediation engagements as a basis for understanding the reasons behind the continued trend in vulnerable web applications. I will also touch briefly on the testing of web applications for security vulnerabilities and remediation and development techniques employed to ensure security.
What is a Web Application?
Web applications may be defined as computer programs that are accessed over a network such as the Internet or an intranet. Web applications (commonly called websites) are the human interfaces to on-line activities (i.e. on-line retail sales, webmail, social networks) accessed through web browsers such as Internet Explorer, Firefox and Chrome.
Web applications, by their very nature and implementation, present unique and difficult security issues. Web applications are traditionally built to provide value to ‘well behaved’ users. Given this expectation, web application developers focus their efforts on responding to ‘good behavior’ as well as weeding out unintentional ‘errant behavior’ (i.e. bad zip codes, empty fields). It is the ‘deliberately malicious behavior’, and the lack of development attention to the consequences of this behavior, that presents security issues.
As an example, consider an on-line retail sales web application where a user, via browser interactions, exchanges data with a web application that is hosted within the corporation’s data center. The connection between the user and the data-center hosted web application has, by necessity, bypassed all physical security. To compound potential security problems, the web application servicing the user will often have direct access to the database containing retail transaction information for all users of that on-line sales application. The only safeguard between the user and the transition database is the web application.
Web application security issues arise when the web application reacts poorly to unexpected information requests or specially crafted data from a user with a malicious intent. A ‘confused’ web application may become a security risk when that confusion allows unintended manipulation of the web application functionality itself.
A classic example of such a malicious ploy is the substitution of database commands when benign data is expected (SQL Injection) – the login password field is often a target since its corresponding value is stored in the application’s database. If input data is not filtered by the web application, the user effectively has the power to run their own ‘mini’ application via database commands, perhaps with full access to the entire database, if not the entire internal network.
The Web Applications Under Study
While I’m only citing two web applications in this study, I feel that they are representative of the massive number of web applications that are currently at risk today. If asked to label the stratum where these web applications fit, I might pick ‘Middle America’ or ‘Professional Class’. Both web applications were centric to companies with the following characteristics:
• Revenues between $5 and $10 million
• Critical dependencies on the web application in order to do business
• Processing and storing data would be considered ‘protected’ by federal and state agencies
• Tremendous financial risk (i.e. fines, flight of clients) if stored data is compromised Both web applications were followed from initial security vulnerability discovery through security remediation and redeployment.
Common Security Risks
Recent studies indicate over 70% of all web applications contain critical security flaws. Given the financial and time costs, loss of reputation and potential flight of customers that any compromised company may incur, this is an amazingly high number.
An evaluation of the web applications under study as well as conversations with the owners and developers of the web application provided the following insight as to the risk factors associated with web applications:
• Web application age – The breakneck arms race between security professionals and cyber criminals often leaves a once secure web application open to new-found attacks. One of the studied web applications was over five years old; built at a time when web application security was not a mainstream concern.
• A lack of a security focus – Not only are most business owners not aware of potential security problems, but many are being misled by their IT staff who believe good development practices are sufficient to produce secure web applications. Both business owners had little technical expertise and no awareness of the business and financial risks their web applications posed. The newest web application in the study was built in the last six months by a reputable software development company that incorrectly told the company’s owner the web application was secure.
• No security testing expertise or tools – Web applications are under tremendous pressure from security attack methods that can only be simulated by professional security testers using sophisticated manual techniques and automated vulnerability scanning tools. It came as no surprise that neither web application was testing for security vulnerabilities and very few, if any, development organizations provide the tools or expertise required to perform these tests.
In hindsight, both web applications were destined to be security nightmares – each contained at least two unanswered risk factors.
The largest problem was the naivety of the business owners. At no point did the owners know enough to be insistent on proof that the web application, at the heart of the business, was secure from attacks by malicious hackers. This common mistake may be the single largest reason our industry continues to see 70% of all web applications containing critical security flaws.
Testing The Security
It has been my experience that the majority of web applications now on the Internet have never been tested for security vulnerabilities. This observation is confirmed by the surprisingly large percentage (70%) of web applications that have been found to contain critical vulnerabilities.
By definition, all web application vulnerabilities originate in the web application software itself, including supporting software components and configuration of supporting components (i.e., database encryption). A complete web application security test must address this full range.
Security testing methodologies fall into three general areas:
• Automated vulnerability scanning – Automated security scanning tools are designed to simulate security attacks on targeted web applications. These scanners run a simulation of every known WEB application attack (updated frequently to keep pace with recently discovered security attack methods) over the entirety of the web application.
• Manual testing – Professional cyber criminals will often spend hours or days probing a web application for security flaws. A white hat equivalent (good guy) will use the same skills and persistence to identify the same flaws, except with the goal of remediating the flaws, not compromising the data.
• Code reviews – While the majority of security testing can be done from the browser-side (automated scanning and manual reviews), a security code review will discover security issues that manifest themselves only after a web application has been compromised. For example, a security code review might indentify inadequate database encryption or back doors set up by malicious developers (timing the set up of back-doors allows a developer to compromise the IT system when the web application is in production).
The study of the two web applications began at the point where both web applications were already deployed and centric to their respective businesses. Several hours of manual security testing revealed the fact that both web applications were susceptible to SQL Injection attacks (direct database access). This information alerted both companies for the need to immediately address previously unknown security problems.
Each web application was then copied to a security test staging environment where a full-automated vulnerability security scan was performed. These scans each revealed badly flawed web applications that were even more at risk than previously thought.
It is virtually impossible to create a secure web application (no critical security flaws) without including security testing as part of the software development lifecycle (SDLC). As we will see in the following section, while adherence to well-established software development practices is essential to the creation of an operational and security sound web application, reaching that goal is hard, if not impossible without corresponding functional and security testing.
Securing The Application
An analogy can be made between the intertwined disciplines of software development and SQA and their security counterparts. Industry accepted SDLC standards have advocated a need for a strong correlation between software development and SQA – with a requirement to consider both disciplines in lockstep throughout the entire life cycle of any development project.
Like the development of an operationally sound web application, the processes behind the creation of a secure web application must include software development processes that include structured security methodologies and the inclusion of security testing.
Security-oriented development practices are not only compatible with the creation of high-quality software application development, but when done correctly, the integration of the two is seamless. With training and awareness, software development professionals can incorporate security sensitive coding techniques as part of their normal practices.
To add to this, it has been my observation that the addition of security-aware development does not significantly add time or cost to an already well structured, professionally done development effort.
Web Application #1
The older of the two web application’s in the study, through manual and automated testing, was found to be vulnerable to critical security attacks by even inexperienced hackers. Because of the company-centric nature of this web application, a decision was made to secure the existing web application as quickly as possible.
The initial remediation stage of this first web application went as follows:
• Triage known critical security flaws – While security tests pointed out numerous critical security flaws, the immediate need was to identify those flaws that might be considered high-risk. These flaws were selected because of the relative ease of a successful security attack and the ‘protected’ status of the data that would be compromised.
• Repair of high-risk security flaws – Each security flaw identified in the triage stage above was remediated to thwart any security attack against that flaw.
• Conduct code reviews – At least two software developers (skilled in standard and security development techniques) reviewed the remediated software to assure the quality of the repair and verify no additional security flaws had been introduced.
• Retest web application – Automated web application security scans were rerun and compared to pre-remediation scans. This retest verified the repair of the high-risk flaws as well as the fact that no addition vulnerabilities had been introduced.
At the conclusion of the initial remediation stage, the web application was considered safe from amateur hackers, with added protection against direct access to the application database. This was a far cry better than its previous status.
In subsequent stages, the remainder of the critical security flaws were fixed using the same repair, code review and retest cycles as noted above.
Web Application #2
The second web application under study had only recently been deployed and was, therefore, less company-critical than the first. Unfortunately, the second web application was developed by a team that not only lacked security development skills, but also lacked skills that would produce operationally sound web applications.
Given the fact that a significant portion of the web application collected and stored easily compromised medical information, a quick decision was made to immediately take down the new site and replace it with a ‘placeholder’ site that, while very limited in functionality, was not subject to security attacks that would yield ‘protected’ information.
The development of the second web application followed standard SDLC methodologies with the addition of vulnerability security scans at every major release point. These scans not only ensured the security of the application but also raised the security awareness and skill levels of the development team. While not a substitute for security development training, periodic reminders of code-based security flaws educated developers in the art of correct security oriented development.
Conclusion While the sample size in this study was far too small to draw any statistically valid conclusions, it did reinforce studies indicating a 70% security failure rate of all web applications.
Also of interest was the fact that the owners of two very successful companies were oblivious of the serious security risks their web applications represented. While there do not seem to be any studies of the percentage of companies that are security ‘clueless’, this anecdotal evidence indicates this percent might be very high.
Finally, it is sobering to think of the huge number of companies that are dependent on otherwise very competent development teams, who with security training and testing, could be producing secure web applications as opposed to the very vulnerable products that exist today.
Read More in SecurityWeek’s Application Security Section
