From 37e9d4b0a4e66d0cfccfac2e8782a3ecb8d0e3b1 Mon Sep 17 00:00:00 2001 From: Joshua Slive Date: Fri, 5 Oct 2001 21:26:00 +0000 Subject: [PATCH] Bring forward some 1.3 changes, mostly from Allan Liska git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@91318 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/misc/security_tips.html | 127 ++++++++++++++++++++-------- 1 file changed, 93 insertions(+), 34 deletions(-) diff --git a/docs/manual/misc/security_tips.html b/docs/manual/misc/security_tips.html index a9237f15d6..a1e32550ff 100644 --- a/docs/manual/misc/security_tips.html +++ b/docs/manual/misc/security_tips.html @@ -4,7 +4,6 @@ - Apache HTTP Server: Security Tips @@ -14,6 +13,25 @@

Security Tips for Server Configuration

+ +

Some hints and tips on security issues in setting up a web @@ -32,9 +50,9 @@ modification by non-root users. Not only must the files themselves be writeable only by root, but so must the directories, and parents of all directories. For example, if - you choose to place ServerRoot in - /usr/local/apache then it is suggested that you - create that directory as root, with commands like these:

+ you choose to place ServerRoot in + /usr/local/apache then it is suggested that you create + that directory as root, with commands like these:

@@ -75,18 +93,55 @@
     overwrite the log itself with bogus data.

     

 
-    
Server Side Includes

-
-    
Server side includes (SSI) can be configured so that users
-    can execute arbitrary programs on the server. That thought
-    alone should send a shiver down the spine of any sys-admin.

+    
Server Side Includes

+
+    
Server Side Includes (SSI) present a server administrator with
+    several potential security risks.

+
+    

+    The first risk is the increased load on the server.  All SSI-enabled
+    files have to be parsed by Apache, whether or not there are any SSI
+    directives included within the files.  While this load increase is
+    minor, in a shared server environment it can become significant.

+
+    

+    SSI files also pose the same risks that are associated with CGI
+    scripts in general.  Using the "exec cmd" element, SSI-enabled
+    files can execute any CGI script or program under the permissions
+    of the user and group Apache runs as, as configured in httpd.conf.
+    That should definitely give server administrators pause.

+
+    

+    There are ways to enhance the security of SSI files while still taking
+    advantage of the benefits they provide.

+
+    
To isolate the damage a wayward SSI file can cause, a server
+    administrator can enable suexec as described in the CGI in General
+    section.

+
+    

+    Enabling SSI for files with .html or .htm extensions can be
+    dangerous.  This is especially true in a shared, or high traffic,
+    server environment.  SSI-enabled files should have a separate
+    extension, such as the conventional .shtml.  This helps keep
+    server load at a minimum and allows for easier management of
+    risk.

+
+
+    
Another solution is to disable the ability to run scripts and
+    programs from SSI pages. To do this replace Includes
+    with IncludesNOEXEC in the Options directive.  Note that
+    users may still use <--#include virtual="..." --> to execute
+    CGI scripts if these scripts are in directories desginated by a ScriptAlias
+    directive.

 
-    
One solution is to disable that part of SSI. To do that you
-    use the IncludesNOEXEC option to the Options directive.

     

 
-    
Non Script Aliased CGI

+    
Non Script Aliased
+    CGI

 
     
Allowing users to execute CGI scripts in
     any directory should only be considered if;

@@ -105,7 +160,8 @@
     
     

 
-    
Script Alias'ed CGI

+    
Script Aliased
+    CGI

 
     
Limiting CGI to special directories gives
     the admin control over what goes into those directories. This
@@ -116,9 +172,11 @@
 
     
Most sites choose this option over the non script aliased
     CGI approach.

+
+    

     

 
-    
CGI in general

+    
CGI in General

 
     
Always remember that you must trust the writers of the CGI
     script/programs or your ability to spot potential security
@@ -133,9 +191,12 @@
     as of 1.2 and is called from special hooks in the Apache server
     code. Another popular way of doing this is with CGIWrap.

+
+    

     

 
-    
Stopping users overriding system wide settings...

+    
Protecting
+    System Settings

 
     
To run a really tight ship, you'll want to stop users from
     setting up .htaccess files which can override
@@ -152,13 +213,14 @@
        </Directory>
- Then setup for specific directories + Then setup for specific directories

This stops all overrides, Includes and accesses in all directories apart from those named.

-

Protect server files by default

+

+ Protect Server Files by Default

One aspect of Apache which is occasionally misunderstood is the feature of default access. That is, unless you take steps @@ -184,10 +246,9 @@

This will forbid default access to filesystem locations. Add - appropriate <Directory> - blocks to allow access only in those areas you wish. For - example,

+ appropriate + <Directory> blocks to allow access only in + those areas you wish. For example,

  <Directory /usr/users/*/public_html>
      Order Deny,Allow
@@ -200,12 +261,12 @@

Pay particular attention to the interactions of <Location> - and <Directory> - directives; for instance, even if <Directory - /> denies access, a <Location /> - directive might overturn it.

+ href="../mod/core.html#location"> + <Location> and + <Directory> directives; for instance, even if + <Directory /> denies access, a + <Location /> directive might overturn it.

Also be wary of playing games with the UserDir directive; @@ -221,15 +282,13 @@

Please send any other useful security tips to The Apache - Group by filling out a problem - report. If you are confident you have found a security bug - in the Apache source code itself, + problem report. If you are confident you have found a + security bug in the Apache source code itself, please let us know.

-

-

+

-- 2.50.1