O'Reilly logo

Securing Ajax Applications by Christopher Wells

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 4. Protecting the Server

So, you want to run a web server in your basement to create the next big thing, and you're looking for some cheap security advice on how to get started? Well, my first and best suggestion is don't do it. I'm just saying if NASA—you know, rocket scientists—can't keep hackers out of its web servers, what makes you think you can? Go find some ISP that has the services you are looking for, and pay the ISP to do it. The job of administering a web server on your own can consume every waking moment, and unless you don't ever want to leave the house, it is well worth the money to let the pros handle the frontend work.

Are you really still reading? Picture this: you find that perfect somebody. You plan a romantic evening and go out to a movie and have a nice dinner. Just when things start to get interesting your phone trumpets out the cavalry charge ring tone informing you of 15 unauthorized login attempts on the web server. After apologizing to those around you for disrupting their dinner, your date raises an eyebrow and decides to skip dessert.

Still there, eh? I'm sorry. I know, it must sound glamorous to have your very own web server, but unless you have spent time thinking like a hacker, odds are whatever you put on the Internet will be vulnerable to attack.

Ajax applications require a web server to work. After all, what good is the XMLHttpRequest object without a web server to talk to on the backend. So, Ajax Security starts with the web server. If your web server is not secure, neither is your application. You need to know what role the web server plays in security. Securing a web server is a non-trivial task that requires an understanding of the web server's relationship with the network. By being aware of what security measures are on the web server, you can balance the security necessary within your applications. In this chapter, I will look at how to ensure the network is secure, and then go through the steps for making a secure and dynamite web server. I will also address what to do in the event of an attack.

Network Security

See that funny-looking telephone-like cable coming out of your DSL/cable modem? That's the Internet. Before we can set up a web server, we must first prepare the network. You don't want to plug the web server into the Internet with a giant Hack Me sign on it, do you? We must take some precautions first.

What we really need to do is separate us from them, right? Us being—you know—us, and them being—well—the bad guys. We need a wall—make that a firewall—to keep them out.

Firewalls

A firewall is a device sitting between a private network and a public network. Part of what helps make a private network private is, in fact, the firewall. The firewall's job is to control traffic between computer networks with different zones of trust—for example, an internal, trusted zone, such as a private network, and an external, nontrusted zone, such as the Internet.

Trust boundaries

Different trust zones meet in what is known as trust boundaries. It is like a seam in the network and, as mentioned earlier, seams require added security attention. We need to make sure that all the gaps are filled and that the firewall allows the right kind of traffic. We do this with firewall rules. Firewall rules establish a security policy governing what traffic is allowed to flow through the firewall and in what direction.

The ultimate goal is to provide a controlled interface between the different trust zones and enforce common security policy on the traffic that flows between them based on the following security principles:

Principle of least privilege

A user should be allowed to do only what she is required to do.

Separation of duties

Define roles for users and assign different levels of access control. Control how the application is developed, tested, and deployed and who has access to application data.

Firewalls are good at making quick decisions about whether one machine should be allowed to talk to another. The easiest way for the firewall to do this is to base its decisions on source address and destination address.

Security concerns

Hey, what's this rule for? Far too often firewalls are found with rules that nobody remembers adding. This happens because administrators fear something will break if they remove them. When firewall rules are introduced, there should be a well-defined procedure for keeping track of each rule and its purpose.

Another problem is that to see whether a firewall is actually doing what it is supposed to be doing you need to beat on it with a penetration-testing tool and monitor it with intrusion detection software. In other words, you have to hack it to see if it breaks.

Port 80

That's just web traffic, right? Port 80 is sometimes called the firewall bypass port. This is because many times any traffic will be allowed in and out of the firewall on port 80. Firewall administrators open port 80 for web traffic, and developers take advantage of the open port by running things such as web services through it—so much for firewall security.

SSL

SSL must be terminated before the firewall so that the firewall can inspect the data and make decisions about the content being sent or received. Otherwise, the data is encrypted with SSL. If the firewall or some proxy in front or behind the firewall terminates SSL, the user won't see a lock in her browser and may become confused or concerned that she cannot do secure online banking, for example.

SSL proxies

There is a crafty solution to the SSL problem: an SSL proxy server. A proxy server can set up its own outbound SSL connection to the server the user wants to contact. The proxy server then negotiates a separate SSL connection with the user's browser. The user's browser doesn't know what is on the other side of the proxy, so it cannot get to the other side without the proxy's help.

The proxy then impersonates the destination web server by—on the fly—generating and signing a certificate for that web destination. The only way that this works is if the user's browser trusts the proxy as a certificate authority. Meaning that if the user's browser has a Certificate Authority (CA) certificate from the company in its trusted store of certificates, then the browser will accept the proxy's generated certificate as legit.

Once this sort of proxy is set up, it is possible to thoroughly inspect all content flowing through without any worry about encryption getting in the way. Although this does now make it possible to inspect the contents of the web transaction, and an organization such as the Electronic Frontier Foundation (http://www.eff.org) might complain about the loss of the user's privacy.

Network tiers and the DMZ

Multiple firewalls can be used to build tiers within trust boundaries. By building a tier with a firewall all the rules controlling access to that tier can be managed on each end. This allows for a flexible yet restrictive network configuration.

Where we see this type of configuration most is in the setup of a traditional demilitarized zone (DMZ) style firewall configuration. Figure 4-1 shows a typical tiered network.

A tiered network architecture

Figure 4-1. A tiered network architecture

If an attack happens within the DMZ it is isolated to this segment of the network, thereby limiting the damage an attacker can do. The secondary firewall protects the internal network in the event a DMZ machine is compromised.

Separation of duties

Boy, that's a beefy machine you got there. It's going to make a fine web server. However, you might be thinking it's big enough to do everything (Web, FTP, news, mail, and so on), and it might be. But, the problem is that if the machine is compromised, everything is compromised. You don't want that; that would be bad.

Thus it is a good practice to isolate these services and spread out functionality by creating a separate hardened machine for each major Internet service:

  • Firewalls

  • Proxies and gateway servers

  • Web servers

  • Application servers

  • Database servers

  • Logging servers

  • Email servers

  • FTP servers

Running these services separately limits the impact of an attack and reduces the surface area with which the attacker has to work. Yep, that's right. Now you have an excuse to buy more machines! Remember, you are the one who wanted to get into the web site hosting business, right?

At the very least, there should be a point on your network before the web server that you can use as a point of inspection and detection. You may not need a full DMZ type setup, but if you are going to play on the Internet, I advise that you at least have a well-configured router and a firewall. Now that the network is prepared we can go back to building that web server.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required