These web application vulnerabilities have familiar names like SQL Injection and Cross-Site Scripting. When securing our networks, we are conditioned to immediately think of firewalls, SSL, Intrusion Detection, and Anti-Virus. While these solutions improve certain aspects of security, their impact on protecting the web site is marginal. Contrary to popular belief, deploying a firewall will not prevent a hacker from penetrating a gaping hole in your web site. To improve the security of the web, we must dispel this and other largely held misconceptions.
1) “A web site that uses SSL is secure”.
2) “A firewall protects the web site, so it’s safe from hackers”.
3) “The vulnerability scanner reported no security issues within the web site, so it’s secure”.
4) “Web application security is a developer problem”.
5) “Security assessments are performed on the web site every year, so it’s secure”.
Secure Socket Layer (SSL)
SSL does NOT make a web site secure. The tiny SSL lock symbol located at the bottom of a web browser indicates that the information sent to and from a web site is encrypted. Nothing more. SSL has no ability to protect the information stored on the web site once it arrives. Many web sites using strong 128-bit SSL have been hacked just the same as those who do not. WhiteHat has found that the use of SSL has nearly no impact on the difficulty of breaking into a web site and pillaging its confidential information.
It’s important to understand what the lock symbol represents in the security landscape. Secure Socket Layer (SSL) is an encryption protocol that enables a web site to prove to a user that they are who they claim to be; and not an imposter eavesdropping on the conversation. SSL also ensures that if someone intercepts the conversation between the user and the web site, the exchange cannot be read. SSL has absolutely nothing to do with how secure a web site is or the manner in which a user’s private information is safeguarded. When private data is stored on the web site, the risk is at the server, not in between.
"Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench." – Gene Spafford
Firewalls
Firewalls allow web traffic to pass through to a web site, but lack the ability to protect the site itself from malicious activity. A web application is software that turns a web site into an e-commerce bank, store, auction, credit union, message board, etc. These web applications remain vulnerable to attack regardless of any firewall in place.
In the traditional network security mindset, the idea has been to “Let the good guys in and keep the bad guys out.” This is done through the use of firewall ACL’s (“Access Control Lists”). Securely configured ACL’s will deny everything from passing into a network except an allowed set of activity such as web traffic and email. Perform a port scan against any web site and you will see port 80 open (for http traffic) and often port 443 (for SSL traffic). Generally speaking all other traffic is blocked by the firewall. No one from the Internet really needs to share your printer do they?
After an ACL has allowed a visitor beyond the firewall and through to the web site, all security protections provided become meaningless. The firewall has protected the printer, escorted email where it belongs and let the whole world into the web site. The firewall’s job is done. There is a new web security problem. How do you let the whole world in and make sure they play nice?
Vulnerability Scanners
Starting in the early 90’s with SATAN, system administrators and security professionals have utilized vulnerability scanners to point out “well-known” network security flaws. After resolving all the reported security issues, the site should be secure enough to be placed on the Internet. However, vulnerability scanners neglect the security of the custom web applications running on the web server, which usually remain full of holes.
Vulnerability scanners operate by transmitting specially crafted network traffic to target servers and collecting responses. The responses are analyzed and compared to thousands of “well-known” security vulnerability signatures (aka: “checks”). When a match is made between a check and a response, a security issue is reported. Up-to-date vulnerability scanners now achieve over 99% vulnerability coverage on the average network, but sparsely target the web application layer.
Vulnerability scanners miss the web application layer because there are no “well-known” security issues present in custom written web code. Statistically speaking, there are issues within just about every web site, but no one exactly where until they look. A small percentage of organizations use the same software to run their web sites. They opt for custom code. Therefore no existing weaknesses could be preprogrammed into the scanner ahead of time. It is important to understand while the average web application in use today is woefully insecure, a vulnerability security scanner is incapable of identifying flaws other than those within its signature database. An off-the-shelf vulnerability scanner will likely give a web site a thumbs-up. Five minutes later a WhiteHat Security analysis would find a way to directly query the backend database and obtain all your customers credit card numbers.
Developers
Sure, developers are part of the problem, but they’re certainly not the entire problem. Many factors beyond their control contribute to software security.
For example, source code can originate from a variety of locations besides the in-house development team. A company might have code developed by an offshore firm to intermingle with existing code. A patch from a commercial vendor may be applied to dependent system libraries. Developers may even use example or open source code from the web. It’s never clear that the entire code base for a software project is unique or their combined interaction is safe and secure. Additionally, as the rush to meet deadlines increases, developers are often forced to take shortcuts.
But, let’s say for argument sake two developers independently create two completely secure software modules. They are secure in and of themselves, but their combined interaction with each other may not be. Now multiply this interactivity with tens of thousands, hundreds of thousands or even millions of lines of code all intermingling. The possibility of a security loophole in business logic becomes likely.
Realistically, software has bugs. In computing we witness this fact everyday. Security vulnerabilities are nothing more than a type of bug. Training staff to develop secure code makes a marked improvement in code quality. But remember, training developers to write secure code, does not mean the code they write will be secure. There is no way to prove software is secure and bug free. Everyone makes mistakes and sometimes buried undiscovered for years.
Security Assessments
The high rate of change in normal web site code rapidly decays the accuracy of last week’s security report, never mind last years. While its responsible, and often required, to have yearly security assessments performed on a web site. Although the common web application life cycle requires more frequent security review. As each new revision of a web application is developed and pushed, the potential for new security issues increases.
In WhiteHat’s experience with e-commerce web sites, holidays are an especially significant time of web site updates. For example, Valentines or Christmas specials are backed with new web code facilitating business. New features are hurried in before and after the deadline hits, regardless of any security consideration left outstanding. If the business does not publish functioning code, there is a financial loss. This is why security personnel must be involved at all stages of development.
Summary
Whether a web site is in the process of being developed of currently serving customers, there are many security considerations that need to be made. Here are some recommendations to help improve web application security:
Business Managers: We recommend web application security reviews be performed periodically as web site’s are updated. Every new line of code is potentially a new security issue.
Security Professionals: Use web application vulnerability scanners in combination with a manual testing process. The pairing ensures completeness throughout a large site and allows the operator to focus their attention on finding the logical issues where they are most effective.
Software Developers: Never trust client-side input. This is the #1 cause of security vulnerabilities. Hundreds of millions of visitors you don’t know have access to your software. Don’t use what you don’t expect to receive.
Resources:
Web Application Security Consortium (WASC)
A source of up-to-date web application security information
The Center for Internet Security
A best practices resource for platform security guidelines and utilities.
Improving Web Application Security: Threats and Countermeasures
Emily
Invite as author
Untitled