S 4.94 Protection of the web server files
Initiation responsibility: IT Security Officer, Head of IT
Implementation responsibility: Administrator
The files and directories on a web server must be protected against unauthorised changes, but also against unauthorised read access depending on the security requirements. If content is created dynamically on the web server, this applies additionally and particularly to the programs (scripts or server extensions) used for this purpose.
General aspects
In general, there are two different aspects that must be differentiated: protection against unauthorised access by local users and protection against unauthorised access by outsiders using the web.
Protection against unauthorised changes
On many web servers, only the log files change constantly and all other files are static files. This applies especially to system programs and the websites. Websites are usually updated regularly, but they should not be edited on the web server itself.
The read and write privileges of the web files stored as local files should only allow access to authorised users. For this reason, a user and role concept should be created in the planning phase of the website (see also S 2.176 Selection of a suitable Internet service provider).
To ensure that no files can be changed on the web server without being noticed, checksums can be calculated for all of the static files and directories, see also S 4.93 Regular integrity checking. The checksums should be checked regularly in this case.
To completely prevent web files from being changed by unauthorised persons, static data can be stored on a write-protected storage medium (e.g. a CD-ROM or a hard disk with write protection enabled).
If the website does not only consist of static HTML files and certain content is generated dynamically, the programs used for this purpose (for example CGI scripts or Java Server Pages) must be programmed with particular care in order to prevent unauthorised access to the server or even the compromising of the server due to insecure programs.
Such programs must be protected against unauthorised access on the server. Only the user or user groups who absolutely need access to these programs or scripts (e.g. developers or administrators) should be granted write privileges. Normally, it should not be possible for the user under whose user ID the web server process is running to change these programs. In particular, normal users should not have read access to scripts since these may contain sensitive information such as authentication data for database access. The same applies to any configuration files existing on the server.
Protection against unauthorised access using the internet
Access to the files or directories of a web server using the web may be controlled using various methods.
The access control methods supported and how these are implemented depend on the server product used. The methods described in the following are widely used and are supported by most web servers and clients.
Client authentication using IP addresses
On many servers, access to web files can be restricted to freely selectable IP addresses, subnetworks, or domains. Authentication using numerical IP addresses does not offer the same level of protection as cryptographic methods, since this type of authentication can be rendered ineffective by an attack based on IP spoofing. In IP spoofing, an attacker forges IP packets to give the impression that they are coming from a trustworthy IT system (see T 5.48 IP spoofing). A firewall can be used, though, to prevent outsiders from pretending that they are internal users. If access is not restricted to numerical IP addresses or subnetworks but to certain computer names or domain names instead, the threat posed by DNS spoofing (see T 5.78 DNS spoofing) also must be taken into consideration.
If the web browser accesses the web server using a proxy server, it must be noted that the only information the web server receives is the IP address of the proxy. However, a proxy can only be considered trustworthy when all IT systems and users concealed behind it are also trustworthy.
If access to the web files is restricted to defined IP addresses, subnetworks, or domains, it may make sense to provide them with additional protection by using a password.
Password protection
Another method of controlling access that is available on practically all web servers is the use of user names and passwords for protection. When a user accesses a correspondingly protected directory in his browser for the first time, the user must enter a user name and password authorising the user to access the corresponding resource. Password protection (user authentication) can be implemented in a variety of ways using the HTTP protocol. The methods differ in terms of the complexity of their implementation and the security offered by each method.
Based on the security requirements, a suitable method for user authentication must be selected. If the security requirements are higher, SSL or TLS should be used to encrypt data transmissions and, if necessary, to authenticate the users using client certificates. More detailed information is described in S 4.176 Selection of an authentication method for websites and information on SSL and TLS can be found in S 5.66 Use of TLS/SSL.
File encryption
Another method used to protect web files is to store the files in encrypted form on the web server so that only those users possessing the correct cryptographic key will be able to read the data. This method also offers protection against unauthorised local access, but requires a corresponding, possibly highly complex key management system.
Review questions:
- Are files and directories on a web server protected against being read or written by unauthorised persons?
- Integrity checking of files and directories using checksums: Are the checksums of the files and directories checked regularly?
- Generation of dynamic content: Have the programs for generating the content been programmed and stored to the server securely so that unauthorised accesses to the server using the programs are not possible?
- Are normal users not granted any access to scripts and configuration files?
- For client authentication using computers or domain names: Have safeguards against DNS spoofing and pharming been taken?
- Client authentication using IP addresses: Are connections from proxy servers only considered trustworthy if all IT systems behind the proxy are trustworthy?
- Protection of the web files using passwords: Is an appropriate user authentication method selected depending on the security requirements?