Are your web applications vulnerable?
{LANG_NAVORIGIN} Web Security
By: Caleb Sima, 10/28/2004
Application Security Is the Trend of the Future
It began with desktop security when the only means of compromising your data was by inserting a
contaminated floppy disk into your PC. That was the age of Anti-Virus. It evolved with the Internet as
more corporations developed internal and external networks. That was the age of Network Security. Now
as corporations leverage the power of the World Wide Web, information security has reached its third
age, the age of Application Security.
“One of the biggest vulnerabilities of a corporation’s network is the widespread access to its
applications. To date, Internet security solutions have not been designed to handle perhaps the most
crucial part of the transaction — that is, the application and its core data. To address the new
requirements, we believe firms will need to implement vulnerability assessment programs and
application security software. We believe that application security is a critical element in network
security.” &n
bsp; — Bear Stearns, Internet Security, June 2001
Introduction
Web Applications can take many forms — an informational website, an e-commerce website, an extranet,
an intranet, an exchange, a search engine, a transaction engine, an e-business. All of these
applications are linked to computer systems that contain weaknesses that can pose risks to a company.
Weaknesses exist in system architecture, system configuration, application design, implementation
configuration, and operations. The risks include the possibility of incorrect calculations, damaged
hardware and software, data accessed by unauthorized users, data theft or loss, misuse of the system,
and disrupted business operations.
As the digital enterprise embraces the benefits of e-business, the use of Web based technology will
continue to grow. Corporations today use the Web as a way to manage their customer relationships,
enhance their supply chain operations, expand into new markets, and deploy new products and services
to customers and employees. However, successfully implementing the powerful benefits of Web based
technologies cannot be achieved without a consistent approach to Web Application Security.
Everyone gets hacked, from large consumer e-commerce sites and portals such as Yahoo! to government
agencies such as NASA and the CIA. In the past, the majority of security breaches occurred at the
network layer of corporate systems. Today, however, hackers are manipulating Web applications
inside the corporate firewall, enabling them to access and sabotage corporate and customer
data. Given even a tiny hole in a company’s web-application code, an experienced intruder armed with
only a Web browser and a little determination can break into most commercial websites.
The problem is much greater than industry watchdogs realize.
Many U.S. businesses do not even monitor online activities at the Web application level. This lack of
security permits even attempted attacks to go unnoticed. It puts the company in a reactive security
posture, where nothing gets fixed until after the situation occurs. Reactive security could mean
sacrificing sensitive data as a catalyst for policy change.
Why Isn’t the Web Environment Secure?
As an ever-increasing number of businesses move to take advantage of the Internet, they discover that
the Web is not just a new market or distribution channel, but also a new operating environment. In
this new environment, conventional security measures are outdated and frequently ineffective.
A new level of security breach has begun to occur through continuously open Internet ports (port 80
for general Web traffic and port 443 for encrypted traffic). Because these ports are open to all
incoming Internet traffic from the outside, they are gateways through which hackers access secure
files and proprietary corporate and customer data. While rogue hackers make the news, there exists a
much more likely threat in the form of online theft, terrorism, and espionage.
In addition to the vulnerabilities inherent in the new Internet operating environment, negligence also
accounts for a portion of the risk to a company’s data. According to the SANS Institute, there are
seven management errors that lead to computer security vulnerabilities:
7 – Pretending the problem will go away.
6 – Authorizing reactive, short-term fixes so problems re-emerge rapidly.
5 – Failing to realize how much money their information and organizational reputations are
worth.
4 – Relying primarily on a firewall and IDS.
3 – Failing to deal with the operational aspects of security: make a few fixes and then not
allow the follow through necessary to ensure the problems stay fixed.
2 – Failing to understand the relationship of information security to the business problem –
they understand physical security but do not see the consequences of poor information
security.
1 – Assigning untrained people to maintain security and not providing the training or the time
to make it possible to do the job.
Today the hackers are one step ahead of the enterprise.
While corporations rush to develop their security policies and implement even a basic security
foundation, the professional hacker continues to find new ways to attack. Most hackers are using “out
of the box” security holes to gain escalated privileges, or execute commands on a company’s server.
Simple misconfigurations of off-the-shelf Web applications leave gaping security vulnerabilities in an
unsuspecting company’s Web site.
It’s not a question of IF your site will be attacked, but WHEN.
Attacks on web-connected servers are becoming more common. Every day there is news of another major
corporation whose security has been breached. Attackers stole credit card numbers from Western Union’s
site, and a computer hacker broke into a Walt Disney Company computer, stealing sensitive guest
information. There’s also the problem of brand deterioration, as Ford experienced when its pristine
Web site was defaced. In each of these highly publicized incidents, attackers used security holes in
web-based computer applications to access and steal proprietary data and sensitive information or to
make changes to a corporate system.
Passwords Are Not Enough
Passwords are only as secure as the people using them. If you rely only on passwords to protect access
to your data, then you are relying entirely on the people creating and using those passwords.
Historically, the easiest way to penetrate a company’s defenses is with inside knowledge. Here’s a
seemingly unbelievable yet real-world example: if a hacker knows that “Bob” works for your company and
if “Bob” has a family Web site where information such as the names and ages of his children can be
found, odds are that a hacker may be able to determine Bob’s password and be inside your company’s
defenses very quickly. Even if the integrity of your passwords remains intact, a hidden back-up file,
an upload file, a form, or even an application running on your Web server might allow hackers to
identify or bypass your password security.
SSL and Data Encryption Are Not Enough.
The SSL protocol and data encryption may protect your information during transmission, but when this
information is used by your systems it must be in a readable form. If the applications that process
data on your site store information for their own purposes, odds are that they do not store it in an
encrypted format. It is surprisingly easy to retrieve data from many Web-based applications. If your
site is vulnerable, then so is your data.
Firewalls Are Not Enough
When medieval architects designed castles, they spent more time on the gates and the moat than on any
other single feature. They knew that any defensive system is only as strong as its weakest point. To
be useful to the people with legitimate business inside, walls must have openings to the outside.
Those openings provide potential vulnerabilities. The challenge is to make sure that you lower your
drawbridge only to friendly forces. One of the hardest attacks to recognize and defend against is one
that uses your own programs and systems against you. This Trojan-horse type of attack manipulates the
features of your own software to force it to divulge information. Firewalls do not prevent this from
happening.
Standard Scanning Programs Are Not Enough
Most scanners run a series of routine checks against your network searching only for known
vulnerabilities on standard servers and applications. Most of these products evaluate your security
based on a static list of potential vulnerabilities. All they can tell you is that access to your data
may be possible. They do not ensure the security of your entire Web presence by checking Web site
content (HTML pages, scripts, proprietary applications, cookies, and other Web servers). As a result,
they do not tell you what data a hacker might be able to access or what damage he could inflict on
your site and your company by going in through the Web application.
A Chain Is Only as Strong as Its Weakest Link
Even if you have the best internal controls, what about other links in your Internet supply chain:
ISPs, ASPs, tool vendors, and development partners? Can you rely on them to take the same care with
your data and information that you do? One small third-party example is software licensing agreements.
Users deploying any software product are generally required to sign a document stating that any damage
that a third-party software product may cause is not the responsibility of the product vendor. In
essence, third parties are telling you up front, “Security is your problem.”
It’s In the Code
Programmers typically don’t develop Web applications with security in mind. What’s more, most
companies continue to outsource the majority of their Web site or Web application development using
third-party development resources. Whether these development groups are individuals or consultants,
the fact is that most programmers are focused on the “feature and function” side of the development
plan and assume that security is embedded into the coding practices. However, these third-party
development resources typically do not have even core security expertise. They also have certain
objectives, such as rapid development schedules, that do not lend themselves to the security scrutiny
required to implement a “safe solution.”
Manipulating a Web Application Is Simple
It is often relatively easy for a hacker to find and change hidden fields that indicate a product
price. Using a similar technique, a hacker can change the parameters of a CGI script to search for a
password file instead of a product price. If some components of a Web application (such as search
functionality) are not integrated and configured correctly, the site could be subject to
buffer-overflow attacks that could grant a hacker access to administrative pages. Today’s Web
application coding practices largely ignore some of the most basic security measures required to keep
a company and its data safe from unauthorized access.
A firewall, an intruder detection system (IDS), cryptography, and access control are just not enough.
The following illustration shows the progression of the professional hacker through the hacker’s value
chain. If the hacker appears to be a “normal user,” he can pass all the regular security checks and
end up engaged at the application layer. (A visitor to your company’s public Web site appears like a
“normal user.”) Once he has reached the application layer, he begins his attack.
How Do You Protect Your Site?
Nowhere is the dynamic nature of the Web more apparent than in the area of security. The market is
constantly introducing new software and new standards to the Web. Each of these innovations introduces
a potential weakness that hackers can exploit to compromise your network’s integrity. In the rush to
bring new software products to market, few companies even test their products from a security
perspective, yet users rely on these products to do business every day.
The cost of poor application security can be far greater than most organizations can imagine. Not only
are you risking your brand and precious customer data, but common denial of service attacks alone can
prevent a company from doing business at all.
Even with the best conventional security systems available today, your company is very likely to be
vulnerable to Web-based application hacking.
What Does Your Company Need to Do?
Developers and security professionals must be able to detect holes in both standard and proprietary
applications. They can then evaluate the severity of the security holes and propose prioritized
solutions, enabling your organization to protect existing applications and implement new software
quickly. A typical process involves evaluating all applications on Web-connected devices, examining
each line of application logic for existing and potential security vulnerabilities.
Unfortunately, most security products cannot adequately examine the applications residing on your Web
server, yet these applications often provide back-end access to confidential data. This means you must
take a proactive approach to protecting your critical Web applications.
To prevent an application attack, you must first understand how a hacker thinks. We describe the
anatomy of a Web application attack on the following pages.
The Anatomy of a Web Application Attack
Act 1: The Scan
The hacker starts by running a port scan to detect the open HTTP and HTTPS ports for each server and
retrieving the default page from each open port.
Act 2: Information Gathering
The hacker then identifies the type of server running on each port, and each page is parsed to find
normal links (HTML anchors). This enables the hacker to determine the structure of the site and the
logic of the application. Then the attacker analyzes the found pages and checks for comments and other
possibly useful bits of data that could refer to files and directories that are not intended for
public use.
Act 3: Testing
The hacker goes through a testing process for each of the application scripts or dynamic functions of
the application, looking for development errors to enable him to gain further access into the
application.
Act 4: Planning the Attack
When the hacker has identified every bit of information that can be gathered by passive (undetectable)
means, he selects and deploys attacks. These attacks center on the information gained from the passive
information gathering process.
Act 5: Launching the Attack
After all of these procedures, the hacker engages in open warfare by attacking each Web application
that he identified as vulnerable during the initial review of your site.
The results of the attack could be lost data, content manipulation, or even theft and loss of
customers. The average corporation does not have the mechanisms to detect such attacks and can spend
significant resources just trying to diagnose the implication of an attack.
The potential for loss is significant. A hacker could easily copy sensitive corporate information,
such as proprietary customer databases or records, and disseminate that information to competitors, or
even to the general public, without your knowledge.
Attack Techniques
There are a variety of techniques that a hacker can use to exploit your Web application. For example:
- Parameter manipulation can be something as simple as an invalid value passed to the Web
application to coax the application into revealing some internal data about itself, or it can be
something as complex as passing a hidden SQL statement that could access useful data from your
database.
- Forcing a parameter is an attempt to exploit the programming rather than the application, by
attempting to determine debugging and testing flags. When these flags are present, they might be used
to enable special, normally hidden modes within the application.
- Cookie Tampering involves manipulating the contents of cookies passed between the user and the Web
application. This tampering can result in an application permitting access to an otherwise
unauthorized user or the application may mishandle the contents of the cookie and return restricted
data.
- Common File Query involves looking for files that have been inadvertently left accessible by
developers, administrators, or default application configurations. The result could be the exposure of
sensitive information that otherwise should have been removed from the application.
These are just a few examples of the types of attacks that the professional hacker may
attempt.
Common Application Attack Methodologies
Attacks primarily fall into two types: static and dynamic. Static attacks are commonly known attack
methods, while dynamic attacks are harder to detect and protect against because they are launched from
deep within the application logic. A more complete list of attacks and the details of their operation
is provided below along with suggested remediation techniques.
These attacks are known by the hacker community at-large and are the result of poor application coding
practices, sub-par administration processes, or application misconfigurations.
Static Vulnerability Attacks
Static vulnerability attacks include the following:
- Known Exploits
- Directory Enumeration
- Web Server Testing
Known Exploits
Hackers are continuously posting the latest discovered Web application attacks on a variety of forums
and “underground” Web sites that cater to the black-hat hacker community. The number of postings is in
the thousands, with many more being discovered and posted on a daily basis. A hacker can use any of
the known exploits to attack your Web application. For example, a hacker can use such exploits as:
- RDS Exploit
- Code Red Worm Exploit
- Nimda Virus
Remediation: Apply all general application patches if available. If not available a secure code
audit and review is required to detect the specific application code level vulnerability.
Directory Enumeration
In this attack the hacker attempts to map your entire web-site hierarchy and directory structure by
looking for common directory names that are hidden from public view but still left accessible. These
directories can contain administrative pages or sensitive information that can help the attacker
further his access into the application.
Remediation: Ensure that your Web root of the Web server is kept clean by removing hidden
directories and that the server only contains content that needs to be viewed by the public. If hidden
directories are needed insure that they are protected by proper authentication mechanisms.
Web Server Testing
Many Web servers have vulnerabilities that allow attackers to submit malformed requests to the server.
These can result in unauthorized access to the system.
Remediation: If the server is known to have a patch, make sure you have installed the latest
updates.
Dynamic Vulnerability Attacks
This is where the majority of available security products stop being effective because they don’t
include these types of security checks. They only detect known vulnerabilities when they are in a
certain location or within a fixed path (for example, the /cgi-bin directory).
A dynamic vulnerability attack will uncover vulnerabilities even if they are deep within your Web
structure. For example, standard fixed vulnerability products search for vulnerabilities within a
fixed path (such as /cgi-bin/formmail.pl). But what if formmail.pl were, instead, located in
/scripts/mail/formmail.pl? A hacker will find formmail.pl no matter where it is located in your Web
structure. The attacker will know that it is an exploitable script even though it is not in its
default location. The solution is to review the directory tree to ensure that vulnerable files are not
exposed through your Web application.
Dynamic vulnerability attacks include the following:
- Link Traversal
- Path Truncation
- Session Hijacking
- Hidden Web Paths
- Java Applet reverse engineering
- Backup Checking
- Extension Checking
- Parameter Passing
- Common File Checks
- Cross Site Scripting
- SQL Injection
Link Traversal
A hacker will “crawl” your Web application to define the structure and logic flow of the application.
This is an information-gathering attack and is usually the initial step in a series of attacks. This
enables a hacker to identify URLs that may no longer be in production but are still referenced in
commented-out sections of your Web application.
Remediation: Analyze your link structure and ensure that any unnecessary links are removed from
public access.
Path Truncation
In this information-gathering attack, the hacker will request only the directories found in a site and
not the specific files. If a Web server does not have a default page located within a directory or
specified in the Web server configuration, the contents of the directory are returned to the attacker.
This enables the attacker to gain a significant amount of useful information about the application and
its structure.
For example, if a link exists on your site to /customers/id/993/details.html, the hacker will begin
truncating the path looking for vulnerabilities during each truncation as follows:
First truncation: /customers/id/993/
Second truncation: /customers/id/
Third truncation: /customers/
This frequently uncovers vulnerabilities that neither the development staff nor the network
administrators ever knew existed.
Remediation: Ensure that there is a default file located within each directory and disable
directory listings in the Web server configuration files.
Session Hijacking
The hacker is able to “hijack” another user’s session by intercepting or predicting any cookies sent
by the site. This enables the hacker to impersonate an authenticated user and review any and all
information that the authenticated user would review.
Remediation: This is typically a design issue within the application caused by the application
generating predictable session IDs or cookies. Review application code and prohibit predictable
session IDs and cookies.
Hidden Web Paths
The hacker finds hidden paths or references in the source code or comments within a Web application.
This information could provide access to restricted areas of your Web application. For example:
Remediation: Always keep HTML comments on a BETA server and remove them before migrating the
application into production. Ensure that the HTML source code is free of any references or comments
that relate to the design features of the Web application code.
Java Applet Reverse Engineering
A common use for a Java Applet is client side logon. The vulnerability exists because a Java Applet
can easily be decompiled. This enables the hacker to find paths or links and to use that information
to try to obtain unauthorized information from your Web site.
Remediation: A Java Applet should not be used as the sole means of authentication or access
control. Also, obfuscation should be used to make it difficult for an attacker to decompile the
Applet.
Backup and Extension Checking
The hacker works from a list of commonly used backup folder names and file extensions. If any of these
folders exist on the site, the hacker will search for a mirror of the original site within that
folder. If a mirrored site is found, the hacker will parse through the site, looking for valid
information that could lead to a security breach.
For example, directories such as /backup and /oldsite could contain old revisions of your company’s
site. Though these sites are no longer used, they could contain pages or scripts that may lead to
information that could compromise your site.
Remediation: Delete all backup files from production servers and disable any mechanisms that
automatically create backup files on a production server. If backups are required on the production
server, move the files out of the Web tree to prevent access by unauthorized users.
Parameter Passing
Many vulnerabilities exist because application developers and site designers fail to consider how
hostile users might input data into various Web page form fields. The hacker evaluates the parameters
used by scripts and inputs invalid or user-specified values.
For example, using a script in the following format…
/contact.asp?email=bleh@bleh.com&subject=Send+me+stuff,
…the hacker will attempt many variations, such as the following:
/contact.asp?email='&subject=
/contact.asp?email=|ls&subject=
/contact.asp?email=/../../../etc/passwd&subject=/../../../etc/passwd
This technique can also be used to check for buffer overflows in the application.
Remediation: Validate all input from the user on server side. Do not rely on client Java Script
validation.
Common File Checks
Many sites have common file names or common directory names within all their site directories. For
instance, many administrators use WS-FTP to upload updated files to their Web sites. However, WS-FTP
leaves a file called WS_FTP.LOG in the directory to which the files were uploaded.
These common files provide information that attackers can use to compromise a site. A hacker searches
through every directory for these common files and uses this information to attack your site.
Remediation: Remove these files from the production server Web tree.
Cross Site Scripting
A hacker forces a Web server to serve JavaScript that was not originated by the Web site authors. This
malicious JavaScript can be used to steal a user’s cookies and even compromise a user’s
computer.
Remediation: Deny any HTML input to your Web application.
SQL Injection
SQL injection is a technique for exploiting Web applications by using client-supplied data in SQL
queries without first stripping illegal characters. The hacker inputs SQL commands into Web page forms
or parameters. The attacker may be able to run any SQL commands on your database that may lead to
compromise of the database server. Despite being remarkably simple to protect against, there is an
astonishing number of production systems connected to the Internet that are vulnerable to this type of
attack.
Remediation: Parse and filter all input.
Conclusion
In the end, it’s what you know.
The remedy for all corporate security issues cannot be described in just one paper. This document is
meant to be a starting point to a better understanding of the critical issues that exist when your
corporation engages the power of the Internet. Keeping current on all aspects of security is a must if
you intend to stay ahead of the professional hacker and fully protect your critical data
assets.
The sooner your company is able to detect, assess, and remediate your Web application security
vulnerabilities the less likely your organization will become a victim of online fraud. A proactive
approach will enable your organization to rest assured that its intellectual property is not at risk.
In a nutshell, you must know what the enemy knows.
The Business Case for Application Security
Whether a security breach is made public or confined internally, the fact that a hacker has accessed
your sensitive data should be a huge concern to your company, your shareholders and, most importantly,
your customers. SPI Dynamics has found that the majority of companies that are vigilant and proactive
in their approach to application security are better protected. In the long run, these companies enjoy
a higher return on investment for their e-business ventures.
About SPI Labs
SPI Labs is the dedicated application security research and testing team of SPI Dynamics. Composed of
some of the industry’s top security experts, SPI Labs is focused specifically on researching security
vulnerabilities at the Web application layer. The SPI Labs mission is to provide objective research to
the security community and all organizations concerned with their security practices.
SPI Dynamics uses direct research from SPI Labs to provide daily updates to WebInspect, the leading
Web application security assessment software. SPI Labs engineers comply with the standards proposed by
the Internet Engineering Task Force (IETF) for responsible security vulnerability disclosure. SPI Labs
policies and procedures for disclosure are outlined on the SPI Dynamics Website at:
http://www.spidynamics.com/spilabs.html.
About SPI Dynamics
SPI Dynamics, the expert in Web application security assessment, provides software and services to
help enterprises protect against the loss of confidential data through the Web application layer. The
company’s flagship product line, WebInspect, assesses the security of an organization’s applications
and Web services, the most vulnerable yet least secure IT infrastructure component. Since its
inception, SPI Dynamics has focused exclusively on Web application security. SPI Labs, the internal
research group of SPI Dynamics, is recognized as the industry’s foremost authority in this
area.
Software developers, quality assurance professionals, corporate security auditors and security
practitioners use WebInspect products throughout the application lifecycle to identify security
vulnerabilities that would otherwise go undetected by traditional measures. The security assurance
provided by WebInspect helps Fortune 500 companies and organizations in regulated industries —
including financial services, health care and government — protect their sensitive data and comply
with legal mandates and regulations regarding privacy and information security.
SPI Dynamics is privately held with headquarters in Atlanta, Georgia.
About the WebInspect Product Line
The WebInspect product line ensures the security of your entire network with intuitive, intelligent,
and accurate processes that dynamically scan standard and proprietary Web applications to identify
known and unidentified application vulnerabilities. WebInspect products provide a new level of
protection for your critical business information. With WebInspect products, you find and correct
vulnerabilities at their source, before attackers can exploit them.
Whether you are an application developer, security auditor, QA professional or security consultant,
WebInspect provides the tools you need to ensure the security of your Web applications through a
powerful combination of unique Adaptive-Agent™ technology and SPI Dynamics’ industry-leading and
continuously updated vulnerability database, SecureBase™. Through Adaptive-Agent technology, you can
quickly and accurately assess the security of your Web content, regardless of your environment.
WebInspect enables users to perform security assessments for any Web application, including these
industry-leading application platforms:
- IBM WebSphere
- Macromedia ColdFusion
- Lotus Domino
- Oracle Application Server
- Macromedia JRun
- BEA Weblogic
- Jakarta Tomcat
About the Author
Caleb Sima is founder and chief technology officer of SPI Dynamics. He is widely known within the
Internet security community for his expertise in penetration testing and his ability to identify
emerging security threats. He began his security career at the S1 Corporation in 1996. Mr. Sima then
joined Internet Security Systems as a member of the X-Force, where he focused on the research and
development of security advisories for ISS. Some of his engineered exploits have gained media
attention in publications such as the
New York Times and the
Washington Post. He has
also been featured in
U.S. News and World Report and
Security World magazine.
Contact Information
SPI Dynamics
115 Perimeter Center Place
Suite 270
Atlanta, GA 30346
Telephone: (678) 781-4800
Fax: (678) 781-4850
Email:
info@spidynamics.com
Web:
www.spidynamics.com
Copyrighted by SPI Dynamics
E-Mail Link
Your IP address will be sent with this e-mail
