Welcome Guest. | Log In| Register | Membership Benefits

News

February 28, 2000

Printer ready
Printer ready
Act Now To Protect Your Data
continued...page 2 of 3

Illustration by Ken Orvidas
Related links from our sister publications:
  • InternetWeek Getting Serious About Security Starts With The Fundamentals (2/21/00)

  • TechWeb White House Presses Industry For Security (2/15/00)

  • Network Computing E-Commerce Security: Security Blanket Has a Few Tatters (1/24/00)

    • Send Us Your Feedback
    The first Web applications were built on the Common Gateway Interface architecture, which let the Web server pass parameters to and execute standalone programs on the server that could process data and return results to users via the Web server. CGI also kicked off a stampede of security vulnerabilities. Because CGI scripts are standalone programs, they're only as secure as their author made them--which may not be very secure at all.

    CGI scripts may simply reveal information about your operating system to a knowledgeable hacker, as basic as what operating-system version is used. More direct, many CGI attacks involve attempts to trick CGI programs into executing commands on a machine with untoward consequences.

    Web servers have been toughened to help limit the types of malice that can be performed on CGI's back, and this is one excellent reason to keep your Web-server software up to date. Nonetheless, because of the independent nature of CGI scripts, there's only so much the Web server can do, and the best defense is to know and understand the CGI scripts that the system uses--clearly the job of your Webmaster.

    Aside from CGI, a number of new Web application platforms have arisen, including Microsoft's application service provider, the open-source Personal Home Page, embedded Perl, server-side JavaScript, and Java servlets. Each of these Web application platforms generally requires special server software, which is often integrated into the primary Web-server software such as Apache, Netscape Enterprise, or the Microsoft Internet Information Server.

    Every piece of software that's needed to support a particular Web application platform becomes a new potential vulnerability, each with its own security flaws and holes. Security alerts have been issued for specific vulnerabilities in every one of these Web application platforms, which means an IT manager must enforce the following precautions:

  • Insist that all application developers stay on top of advisories for their particular application platform. For example, the Java servlet coder should be responsible for patches to the Java servlet server. This keeps developers thinking about security in their areas. These people are also in the best position to understand the advisories and alerts.

  • Remind application developers to stay aware of system privileges as they relate to any application server software. For instance, several recent high-profile attacks on retail merchants, resulting in public distribution of client credit-card data, took advantage of lax default-access privileges in certain SQL Server products.

  • Limit the variety of Web application platforms in use. If an application can be created by using one or two platforms rather than five, all the better. Many of these platforms overlap in capability, so stick to the minimum needed to get the job done. Inviting additional vulnerability and vigilance for a hot new development platform is ultimately counterproductive.

    If, for some Grinch-like reason, you don't want Santa coming down your chimney, there's one foolproof way to stop him: Don't build a chimney. The same design, or anti-design, principle should apply to Web applications.

    The easiest means for malice to burrow its way into your site is by invitation. In reality, companies sometimes require outsiders to access specialized services on your server. In these cases, go with a strong authentication system wherever possible, so that only authorized users have such access.

    Providing information about your server, for example, should be a measured decision. Often, ne'er-do-wells look for version information for your Web server or operating system; this information can tip them off to known flaws in given pieces of software.

    Some companies intentionally supply wrong or misleading version information about their systems, but the easiest approach is, whenever feasible, to provide none at all. Of course, this may not be realistic for a site that, for instance, produces and therefore demonstrates a particular version of server software itself.

    continued...page 3
    return to page 1

    Illustration by Ken Orvidas


    Back to This Week's Issue
    Send Us Your Feedback
    Top of the Page