Locking the Door behind You: Hacker Protection for Your Web Applications

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.

You might also like...

Comments

About the author

Caleb Sima United States

Caleb Sima is founder and chief technology officer of SPI Dynamics, the expert in Web application security testing and enterprise security risk management. He is widely known within the Internet...

Interested in writing for us? Find out more.

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Some people, when confronted with a problem, think "I know, I’ll use regular expressions." Now they have two problems.” - Jamie Zawinski