Introduction
Your Web applications can be the most important and most vulnerable
entry point into your organization, and, as such, ensuring adequate
hacker protection in your Web applications can be critical. A Web
application not only includes the code that creates your Web site, but
also the architectural components necessary to make a Web site
available and useful to the public – both of which can make a Web site
vulnerable to attacks like SQL injection or cross site scripting (XSS).
When considering hacker protection for your Web applications, you must
account for all the components that work together to create a Web site,
not just the visible face presented to the world at large.
In the past, the majority of security breaches occurred at the
network layer of corporate systems, so most corporations focus hacker
protection measures at the network layer. Today, however, hackers are
using vulnerabilities like SQL injection and XSS to manipulate 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
Web sites by exploiting common Web application vulnerabilities like SQL
injection. While corporations rush to develop their security policies
and implement even a basic security foundation with hacker protection
at the network layer, the professional hacker continues to find new
ways to attack.
Since the Web’s inception, there have been numerous applications
written, and most people trust that these applications are built with
hacker protection in mind. Unfortunately, software companies do not
produce bug-free applications. Application code is both large and
complex, and human error is part of the development process. As long as
you have good developers creating the right applications, you assume
they are strong and secure, without vulnerabilities like those used for
SQL injection attacks. But it is important to remember that all
applications are written with functionality and technical requirements
in mind, not security or hacker protection.
The evidence is significant: an estimated two-thirds of all security
breaches today are due to vulnerabilities within the Web application
layer, the most common of which are SQL injection and XSS
vulnerabilities. For far too many development professionals, Web
application security only consists of producing applications that are
functional and stable, not building hacker protection into the code or
checking for SQL injection vulnerabilities. As long as the site remains
accessible, then everything is functioning within accepted operating
parameters. When marketing, sales, and the customer base are satisfied,
hacker protection tends to be of little or of no concern. That
application may be functioning properly, but it is not necessarily
functioning securely. Ignorance can be bliss, but knowledge can come
with a painfully high price in terms of negative publicity, lost
revenue and lost customer confidence.
Coping with the potential impact of hackers and enacting adequate
hacker protection requires a new understanding of how they operate. A
common misconception is that hackers are content with defacing your Web
site. This is true for a small percentage of hackers who gain
self-esteem, publicity or a sense of control from publicly humiliating
a company. For many hackers, it is simply a matter of the challenge.
The old adage "because it’s there" can apply to hacker motivation as
well. Hackers are methodical and understand the significance of Web
application vulnerabilities like SQL injection and XSS.
Most hackers are using these "out of the box" security holes, of which
SQL injection and cross site scripting are just a couple, to gain
escalated privileges or execute commands on a company’s server. In
these cases, hacker protection can be as easy as checking the
software’s configurations. Simple misconfigurations of off-the-shelf
Web applications and in-house produced applications leave gaping
security vulnerabilities in an unsuspecting company’s Web site.
So how does a hacker discover Web applications that have not enacted
adequate hacker protection? Very easily. A 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. He or she 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. The hacker goes
through a testing process for each of the application scripts or
dynamic functions of the application, looking for development errors
like SQL injection and XSS vulnerabilities that will enable a person to
gain further access into the application. If the Web application has
been developed with hacker protection in mind, these vulnerabilities
will not be available to exploit.
When the hacker has identified every bit of information that
can be gathered by passive (undetectable) means, he or she selects and
deploys attacks. These attacks center on the information gained from
the passive information gathering process. After all of these
procedures, the hacker begins the pillaging by attacking each Web
application identified as having inadequate hacker protection 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
implications of an attack. For companies that have failed to invest in
hacker protection, 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.
Following are detailed examples of both SQL injection and cross
site scripting, which are common Web application hacking methods that
can allow intruders to compromise the confidentiality, integrity and
even functionality and availability of a company’s network data when no
measures are taken towards hacker protection in the application layer.