Web Development Guidelines Resources for Creating a Web Site at Johns Hopkins
Web Guidelines Site Map

Web Security

Server Security

Keep OS Up to Date with Patches

Shutdown Web Server or Disconnect from Network When Building or Updating a Web Server

Always build a web server off of the network. Do not connect the web server to the Hopkins network until it is fully patched and updated. If you need to put the server on the network to download patches, shut off the web server component until the patching is done. It is best to assume that the web server will be constantly under attack from various exploits. It should only be placed on the network when the safeguards for current known vulnerabilities have been put in place.

Eliminate Unnecessary Services, Applications, Protocols, and Ports on a Web Server

The general rule of eliminating unnecessary services is critical when hardening a web server. If possible, run other applications, like database engines, on separate servers. Eliminate as many unneeded protocols and open ports as possible. In particular, many web servers also run FTP servers or SMTP servers when they are not needed.

Consider Disabling NetBios on a Web Server

If running on the Windows platform, consider disabling all NetBios activity. The Server service can be shut down and not directly affect IIS. This prevents many non-web attachments to the server such as drive mappings.

Maintain Access Logs

Always make sure that the web server records access logs and that they are stored in a secure location on the web server, apart from the web-accessible files. Web server logs should include a minimum of time, date, remote client IP address, and resource requested. In the event of a security incident, log files are an essential tool for diagnosis.

Links for Operating System Standards and Network Security Best Practice Documents:
http://jhmcis.jhmi.edu/standard.htm http://nts.jhmi.edu/es/infosec/

Web Site Security

Once the web server itself has been set up in as secure a manner as possible, it is time to consider the security of the sites which will be hosted on that web server. Web site security is more flexible than web server security; decisions made about the web server usually affect all the hosted sites, but decisions about web site security can be customized for each particular site. There are three basic ways to secure a web site. These methods can be used alone or together in any combination. The specifics of implementing these security procedures depend on the operating system and the web server software. Also, depending on the web server software, these methods can be used for entire web sites, individual directories, or sometimes even individual files.

IP Address Restrictions

This method allows only certain predefined IP addresses to access the web site. Usually this method is used to restrict the audience of the web site to particular physical areas or user communities. A common use would be a library that purchases a web-enabled database. The license for the database might specify that only users on the Homewood campus can access the resource, so the web site's IP address restrictions would be set to deny everyone except those people on the Homewood campus. Most web servers support very granular levels of IP restrictions; one page could be restricted to one IP address or an entire site could be restricted to all Hopkins IP addresses.

IP address restrictions are an easy way to restrict web sites, but are entirely dependent on being able to define the restricted audience by ranges of IP addresses. It is not always possible to do this, which leads to the next method of web site security.

Authentication

The default method of access for most web sites is anonymous, meaning that the user requesting the web page is not identified. If a web site needs to be restricted to a certain audience that is not easily classifiable by IP address, then some form of authentication should be used. Authentication is also used by web-based applications when the information presented to the user changes based on their identity. Authentication can use a single username and password for all users of the site or individual usernames and passwords for each user.

There are two different methods for authenticating users to a web site. The first method uses features built into the web server itself. When the site is set up on the server, it is flagged as requiring authentication and a list of users and passwords is provided. The specifics of this method vary greatly depending on the web server being used. Sites that use this method can sometimes be identified by the fact that they pop up a specially formatted dialog box in the browser to collect the user login information.

The second method of authentication is programmatic and requires that at least some portions of the site use a server side scripting language like PHP, JS, ASP, or Cold Fusion. This method commonly uses forms embedded within a web page to present the user login screen. Programmatic authentication is more flexible than web server-based authentication, and is more likely to be used when an interface to an external database of user information, like an LDAP server, is required.

Whatever method of authentication is used, particular care should be given to the location in which the user information is stored. Whether in a file or database, access to the usernames and passwords should be as restricted as possible.

For additional security, IP address restrictions can be combined with authentication.

Secure Sockets Layer (SSL)

SSL is a protocol used for encrypting the data traveling between a web server and a web browser. Because data traveling over the web can potentially be seen by anyone sharing the networks on which it travels, it is sometimes necessary to encrypt this data so it cannot be deciphered if captured. SSL requires components to be installed on the web server and support in the web browser. SSL enabled web sites can be distinguished by the beginning of the Uniform Resource Locator (URL), which starts with https:// instead of http://.

When to Encrypt Data

The decision on whether to use SSL is not based on the audience of the web site, but on the nature of the information being served. Good candidates for SSL-enabled web sites are ones that transmit or store:

• Social Security Numbers
• Patient Information
• Student Information
• Financial Information
• Personnel Records
• Secure User Names and Passwords for Authenticated Web Sites

Obtain a Digital Certificate to Establish SSL on a Web Server

To install SSL on a web server, a digital certificate must be obtained. Certificates can be issued from many different places, but to avoid confusing warning messages and to ensure maximum trust, Hopkins entities usually purchase SSL certificates from either Verisign (www.verisign.com) or Thawte (www.thawte.com). These two external vendors are "Trusted Root Certification Authorities" which means that most browsers will automatically trust a certificate that has been issued from them. There are many other Root Certification Authorities, but these are the two with the most recognition and use at Hopkins.

Defining a Common Name on the Digital Certificate

When obtaining and installing a certificate, the most important decision to be made is the base URL for the site as it will be accessed by browsers. This is called the Common Name on the certificate and it must match exactly or a warning will be issued when the site is accessed.

For instance, if SSL were going to be applied to this web page: http://nts.jhmi.edu/es/websearching.cfm, the SSL certificate would have to be purchased with a common name of "nts.jhmi.edu". This web page can also be accessed by http://nts.jhu.edu/es/websearching.cfm (because this alias DNS name exists), but if the certificate were purchased with a common name of "nts.jhmi.edu", then attempting to access https://nts.jhu.edu/es/websearching.cfm would cause a warning to be generated by the browser that the name on the certificate does not match the name the user typed in.

A Digital Certificate is Needed for Each Web Site

SSL certificates are applied to an entire web site, as represented by a unique base URL/FQDN (Fully Qualified Domain Name). Once the certificate has been applied to a web site, the server can be configured to require that certain parts of the site or pages use SSL. The existence of an SSL certificate does not mean that every page on that site must use SSL. If a web server hosts multiple sites, each using a different base URL/FQDN then multiple certificates must be purchased for each base URL/FQDN. Special attention should be paid to vendor instructions if SSL certificates are being purchased for clustered web servers, as this complicates the entire certificate issuance process.

Certificate Expiration

SSL Certificates also expire. Typically certificates are issued for one or two years. The issuing authority should send renewal notices before the expiration. The certificates must be continually renewed to avoid browser warning messages. For this reason it is important to keep contact information for the certificate up to date with the issuing authority.

In the past, the two major browsers offered export versions (40-bit encryption) and US versions (128-bit encryption). Currently, the 128-bit browser versions are standard since the export restrictions have been loosened. Most web servers can be configured to require not only that SSL be used, but that the SSL be 128-bit. If there is some confidence that this will not cause problems for the users of the web site, 128-bit SSL should be required. 40-bit encryption is exponentially easier to crack than 128-bit. The major Root Certification Authorities have also recently begun offering "enhanced" versions of their certificates which use Server Gated Cryptography (SGC) to enable 128-bit encryption even if the browser is 40-bit. SGC certificates are typically more expensive and may only work with certain web servers, but they may offer enhanced security in certain situations.

SSL can be used in combination with IP address restrictions or authentication or both. If a web site uses authentication and the usernames and passwords being used for that authentication are sensitive, then at least the login portion of that web site should use SSL to protect the usernames and passwords.