The Security of Server-Side Includes
The Security of Server-Side Includes
The Security of Server-Side Includes
Great danger to security is posed by "server-side includes" (SSI). These are code statements in HTML documents, often written with PHP, that give instructions to the Web server. Some of these instructions can tell the Web server to execute system commands and CGI scripts. Because programmers are usually unaware of the security risks, and therefore do not write their code accordingly, Web Masters should keep a sharp eye on them.
Server-side includes are snippets of code that not only simplify Web site maintenance but can also make Web site pages interactive. This and their simplicity to implement make them attractive to Web programmers, but the risks of using them must be understood and avoided.
Using server-side includes to display environment variables and file statistics ("#echo var=") poses no security risk; likewise, using the "#include" function, provided that the directory containing the included file is not Web-accessible.
Security problems can arise when using server-side includes to execute programs on the Web server, specifically when using the "#exec" function. A hacker may then be able to run commands to access and steal data, corrupt or even delete files.
It is safest to disable the "#exec" directive on the Web server, or at least limit its use to only trusted users. Needless to say, it should be used only where absolutely necessary.
If having to run a program with server-side includes is unavoidable, it is safer to use the "virtual=" parameter with the "#include" directive than to use the "#exec" directive. The "virtual=" parameter specifies the target relative to the Web server root directory rather than to the directory of the current file. Thus, program files can be kept out of the way of the Web-accessible files. As an example:
would call a menu program from the (protected) cgi-bin directory, regardless of the location of the file containing the "#include" code.
NCSA and Apache are two Web servers where server-side includes that can execute arbitrary commands can be disabled by the Web Master.
On an Apache server the line:
Options IncludesNOEXEC
in the 'httpd.conf' file disables the "#exec" directive completely.
The equivalent on an NCSA server is:
Options IncludesNoExec
in the 'srm.conf' file.
On a WN server, which puts security before all else, the "#exec" directive is disabled by default, but can be specifically enabled.
On a CERN server server-side includes are not supported, but can be implemented by means of a Perl program called 'fakessi.pl', which emulates server-side includes functionality.
In situations where there is no Web server root directory access, the "#exec" directive can be disabled or enabled in specified directories by means of appropriate statements in an '.htaccess' file located in each directory. The '.htaccess' file is the directory-level equivalent of the root-level configuration file. If the Web site is hosted by an external hosting company or Internet Service Provider, access to the Web server root directory is very unlikely, and '.htaccess' files can be used.
An '.htaccess' file is merely a plain-text file created with a text editor, like NotePad. It declares the same statements as the root directory configuration files already cited. As with the root directory configuration file, the statements in '.htaccess' files apply also to sub-directories.
As has been emphasized elsewhere in these Web site security articles, the minimum necessary functionality is safest. Server-side includes should be activated only in directories where they are needed. On some Web servers parsing is disabled automatically for certain directories, notably in users' home directories. Because the statements in '.htaccess' files apply to sub-directories, server-side includes should be activated only in directories containing HTML files that need to be parsed for SSI. Confidential data should be kept in other directories not located in any sub-directories of those activated for SSI statements.
The same principle of minimality applies to file permissions. Setting file permissions as 0644 (for Unix) HTML files will be parsed by the Web server in directories with access set to "read and write" for the Owner ("User") -- this is also the identity of the Web server, so that it can execute commands -- "read only" for the Group and "read only" for all others.
Programs that are called from server-side includes code should be located only in directories with file permissions set to "read, write and execute" for the Owner ("User"), "read and execute" for the Group and "read and execute" for all others. (On the Unix platform these permissions are set as 0755.) Such directories are usually called "bin" or "cgi-bin".
If the use of the "#exec" directive to run CGI scripts is inevitable, the scripts should be coded to detect and ignore SSI commands from data input fields in forms and such like. A typical abuse by a hacker of a form that sends an e-mail from a mail server is to send thousands of spam e-mails, thus swamping the mail server. Furthermore, even an innocent yet clumsy Web site visitor can bring down a Web site by inadvertently entering damaging characters into form fields.
It is prudent to take the following precautions when using server-side includes that call scripts or programs on a Web site:
- Programming code should be written as if an attack is expected.
- Data input forms should be checked regularly for inappropriate user input.
- The most recent date+time stamp of user-edited files should be checked regularly.
- Universally defined CGI environment variables (REMOTE_USER, REMOTE_ADDR, REMOTE_HOST, REMOTE_IDENT, etc.) should be used to control access to programs and scripts.
Web Masters should be aware that, because there is no universal standard for the use of server-side includes, Web servers differ in their treatment of SSI. Notwithstanding, SSI security issues that should be discussed by Web Masters, Network Administrators and overall System Administrators include:
- Should server-side includes be enabled or disabled on the server?
- If they are enabled, where? Root directory or sub-directories?
- If sub-directories, which?
- Should scripts and executable programs be callable by server-side includes?
- If so, how should they be controlled?
- Should such scripts and executable programs be located in user directories or in a dedicated shared directory?
- Should the "#exec" directive be enabled or disabled?
- Could the "#include" directive with the "virtual=" parameter be an alternative?
- If the "#exec" directive is enabled, where? Root directory or sub-directories?
- Measures to protect the Web server against SSI vulnerabilities.
- Formal procedures for monitoring the system.
- The response expected of users and administrators to suspected Web server security breaches.
Finally, an assessment should be made of the organization's expertise and capacity to administer server-side includes with the care and skill required to tip the balance towards their benefits rather than towards their security risks.
Issues with the US Social Security Number System Uninstall/Remove Personal Security Sentinel - the Best Way to Remove Personal Security Sentinel virus Quickly! Personal Security Sentinel Removal - How To Uninstall/Remove Personal Security Sentinel Easily From Your PC Personal Security Sentinel Virus Removal-Uninstall Personal Security Sentinel Virus Reasons to Screen the Tenants for Security Reasons Car Alarm Systems: One of The Popular Security Products Getting the Best Security from Your Motion Sensor Device How to Find the Best Deal on a Security Surveillance System The best solution for your security concern Fencing - Why is it Important and How to Choose Their Best Makers of Security Fencing? How to Start Searching for on A Reliable Maker of Security Fencing? Special security arrangements for Vaikuntha Ekadashi A Security Yard Sign - An Impressive Deterrent For A Low Cost