Summary

This chapter noted a wide range of tools and services to implement remote web server administration and content management/authoring. All of these interfaces can easily be identified by attackers using port scanning and related weaknesses exploited, be they known software bugs , weak (default) passwords, or inappropriate access controls. Thus, it behooves web application architects to consider remote management and ensure that it is done securely. The following general guidelines for securing remote web server management were covered in this chapter:

• Authenticate all remote administrative access.

• Ensure that strong passwords are used. Be sure to reset vendor default passwords!

• Restrict remote management to one IP address or a small set of IP addresses.

• Use a communications protocol that is secured against eavesdropping (SSL or SSH, for example).

• Use a single server as a terminal for remote management of multiple servers, rather than deploying management services to each individual web server.

And, as always, carefully restrict the type of services that web servers can use to access internal networks; remember, a web server is likely to experience a serious security compromise at some point in its duty cycle, and if that web server has a dozen drives mapped on internal staging file servers, then your internal network is compromised, too. Consider using sneakernet (i.e., physically moving content to an isolated DMZ distribution server on removable media) to update web servers, keeping them physically isolated from the rest of the organization.

We also discussed common web application misconfigurations, whether perpetrated by administrators or developers (we contrasted these with errors in COTS components , which we discussed in Chapter 3). We noted that one of the most dangerous misconfigurations is leaving unnecessary web server extensions enabled, due to the long and storied history of high-impact exploits of such modules. We also demonstrated how to address common sources of web application information leakage, including HTML source code, common directory and filename conventions, Internet caches like the Way-back Machine, status pages, and so on. On the developer side of the house, we cited include files as a common source of information leakage, and presented an example of exploiting a hidden form field to defeat the default configuration of Microsoft's ASP.NET ViewState feature. Hopefully, these examples will illustrate how to seal up the most common and devastating leaks in your web applications.