Keeping out Web attackers

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.

Talkback 0 comments

Latest Videos

Sponsored content

Power Centre - Content from our premier sponsors

Blogs

Tags

Back to top

Featured