Here's how to prevent attacks against your Web site.

Most Web applications are vulnerable to attack. The recent break-ins at CD Universe and Egghead.com are but a few examples of a growing problem. The most important weapons in keeping sites safe from attack are awareness and understanding. Looking at your Web application, an attacker will generally ask four questions: (1) Can I see what your visitors are seeing? (2) Can I impersonate your visitors? (3) Can I impersonate you? (4) Can I direct your computers to do my bidding?

• 1. Can I see what your Visitors are seeing?
  The obvious way to prevent eavesdropping is encrypting the connection between a site and its visitors. Almost all Web browsers and servers can send and receive data over encrypted channels, which are managed by two closely related protocols: SSL and TLS. SSL (Secure Sockets Layer) was created by Netscape, and the more recent, vendor-neutral TLS (Transport Layer Security) is based on and backward-compatible with SSL 3.0.

  Browsers usually connect to Web sites using HTTP (the HyperText Transfer Protocol), as indicated at the start of the URL in the address bar: http://www.somewhere.com. When the browser connects to a secure site, it uses HTTPS (HyperText Transfer Protocol Secure) to establish an encrypted link, and the URL looks something like this: https://www.somewhere.com.

  To establish a secure connection, the browser first asks the Web server for its digital certificate, which provides proof of its identity. When asking the Web server for its digital certificate, the browser also sends along a list of supported encryption algorithms. Once the server sends back the certificate and its choice of encryption algorithm, the browser verifies the certificate by checking the digital signature for signs of tampering, and by confirming that the URL matches the digital certificate's Common Name field. If any of these tests fail, the browser displays a warning message.

  Symmetric encryption is used for communication between browser and server. This means that the same secret session key is used for encrypting and decrypting. The browser generates the key once the server's certificate has been validated, but then needs a secure way to transmit it to the server. This is done through dual-key encryption. The browser encrypts the session key using the server's public key and then transmits this to the server. The server decrypts the session key using its private key and sends an acknowledgement to the browser.

  At this stage, an encrypted link has been established. The browser and the server both possess the same session key, and they have agreed to use the same encryption algorithm. Their subsequent traffic will use this encrypted link. The browser displays a yellow lock icon to indicate that the link has been established. The site visitor can verify the server's identity by clicking on the yellow icon to inspect the server's certificate.

  Establishing an encrypted link simply requires that the server obtain a certificate signed by a well-known authority such as VeriSign. But encryption only prevents others from seeing what a Web site is sending and receiving. It doesn't prevent others from falsifying their identities, nor does it protect a site from malicious attacks.

• 2. Can I impersonate your visitors?
  Now we've described a way for visitors to authenticate a Web site, but how does a Web site authenticate its visitors? Most Web servers support two password authentication schemes: basic and digest. Both schemes operate by issuing a challenge to the browser. When the browser receives the challenge for the first time, it displays a dialog box that asks for the username and password. In basic authentication mode, the browser transmits the username and password in plain text. In digest authentication mode, the browser transmits a message digest of the username and password. If the server sends its approval, the browser caches the log-on information for future visits.

  You implement these authentication schemes with a simple setting on the Web server. No code needs to be added to the Web application. But these schemes won't solve all problems.

  Secure your Web applications

  The first problem again involves eavesdropping. If visitors send usernames and passwords in plain text, attackers can capture them. This problem is easily solved by transmitting the user's information using SSL, as shown in the following example.

  User ID: < input type="text" name="user" >
  Password: < input type="password" name="password">
  

  If an attacker can't eavesdrop on the communications between Web site and visitor, perhaps he can do the next-best thing: impersonate a visitor. The weak link that makes this possible is the visitor himself. Most Web surfers pick passwords that are not secure. Even worse, they tend to use the same username and password for all sites requiring a log-on.

  One way to solve this problem is to enforce the use of strong passwords when visitors register for an account. The Web site's code can run a proposed password through a dictionary to prevent selecting English words, and it can force the use of numbers or mixed case. In the case of an intranet with many sites requiring authentication, a single sign-on technology such as Microsoft Passport can be used. Hard-to-guess passwords are not enough, however, if a site's servers are vulnerable to attack.

• 3. Can I impersonate you?
  Once visitors have logged on to your Web site, you want their credentials to remain valid until they log off. But how is this done? There is no permanent connection between the browser and the server; a separate connection is established for each page requested. How does the Web server verify a user's credentials after he has logged on?

  Answer: The browser caches the username and password for the lifetime of the browser window. Each time the browser reconnects to the server, it transmits the cached username and password. The server then verifies this information with a user database and grants or denies access based on whether a match was found.

  As previously mentioned, your browser attempts to confirm the server's identity by comparing the URL with the Common Name of the server's digital certificate. This is a reasonable precaution, but it won't catch all server impersonation attacks.

  The Domain Name Service (DNS), which translates readable names like www.yourbank.com to IP addresses, is a vulnerable link in your security chain. If an attacker accesses a DNS server and changes the records to point to one of his machines, this machine could then redirect all HTTPS requests from www.yourbank.com to www.attacker.com/{long_ incomprehensible _string}. On redirection, a visitor's browser displays the end of the address by default. If the string is long enough to push www.attacker.com out of view, most visitors will not notice.

  If an attacker got a digital certificate from VeriSign for www.attacker.com, then the visitor's browser will have a legitimate connection to www.attacker.com. Unless the visitor clicks on the yellow lock icon to inspect the certificate, he won't know he's at the attacker's site. If the attacker makes his site look just like the log-on screen to www.yourbank.com, he'll be able to capture usernames and passwords for customers' bank accounts!

• 4. Can I get your computers to do my bidding?
  Some attacks exploit vulnerabilities in a Web server's software to execute their own code. One category of attack that has gained notoriety is the buffer overrun, which works by writing too much data into a buffer. The following snippet of C++ code is vulnerable to a buffer overrun attack, because it does no bounds checking:

  void ByYourCommand( char* pszData ) { char szBuffer[ 255]; strcpy( szBuffer, pszData ); ...}

  What happens if the strcpy() function overflows the stack-based buffer? The stack grows down from the top of memory, and the buffer grows up from the bottom of memory. If an attacker writes too much data into the buffer, he will overwrite the function call record. This is a data structure that contains register values saved by the function prolog code, along with the return address of the function. If he overwrites the return address of the function, he can execute any code he wants on your computer.

  The attacker wants to execute code that he puts on your computer. How can he inject this code into your computer? By writing it into the data buffers! The string passed to this sample function could easily contain some executable instructions that bootstrap the download of common Trojan horses such as Back- Orifice. There are many documented cases of these types of attacks on Web applications.

  Attackers know that vulnerable functions such as the one shown here are usually called by code that responds to user input. The attacker sends impossibly long input strings to the server and watches how it behaves. If he overflows a buffer, the thread processing his request most likely will crash. He knows that the thread has crashed if he gets an HTTP timeout, or if he sees a 500-series HTTP internal error.

  How can you prevent your Web application from being exploited? First, add the latest security patches to the underlying system software. If this can't be done in a timely manner, hire a system administrator to do the job. Better yet, write code that automates the process. Next, find all existing code that is written using languages that allow direct memory access--C, C++, and Delphi--and audit the code for buffer overruns.

  Auditing code can give you some confidence that an application is not susceptible to buffer overrun attacks. But you can avoid the problem entirely by not writing in languages that allow direct access to memory. Instead, use scripting languages such as JavaScript and Perl or an interpreted language such as Java. The forthcoming .NET languages--C# and Visual Basic.NET--are also safe. If code is written using safe languages, Web site operators can devote their energy to more interesting tasks than guarding against buffer overruns.

  Don't blindly believe in the promises of technology; no technology is perfect. Take the time to investigate how it works and discover its weaknesses. In the end, managing your risk exposure intelligently is up to you.
  

  Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
  ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.