Confidential data in a request should be placed in a message-body as
   part of a POST request, and not placed in the URI or message headers.
   On some systems, the environment used to pass meta-variables to a
   script may be visible to other scripts or users.  In addition, many
   existing servers, proxies and clients will permanently record the URI
   where it might be visible to third parties.

9.4.  Information Security Model

   For a client connection using TLS, the security model applies between
   the client and the server, and not between the client and the script.
   It is the server's responsibility to handle the TLS session, and thus
   it is the server which is authenticated to the client, not the CGI
   script.

   This specification provides no mechanism for the script to
   authenticate the server which invoked it.  There is no enforced
   integrity on the CGI request and response messages.

9.5.  Script Interference with the Server

   The most common implementation of CGI invokes the script as a child
   process using the same user and group as the server process.  It
   should therefore be ensured that the script cannot interfere with the
   server process, its configuration, documents or log files.

   If the script is executed by calling a function linked in to the
   server software (either at compile-time or run-time) then precautions
   should be taken to protect the core memory of the server, or to
   ensure that untrusted code cannot be executed.








 
RFC 3875                    CGI Version 1.1                 October 2004


9.6.  Data Length and Buffering Considerations

   This specification places no limits on the length of the message-body
   presented to the script.  The script should not assume that
   statically allocated buffers of any size are sufficient to contain
   the entire submission at one time.  Use of a fixed length buffer
   without careful overflow checking may result in an attacker
   exploiting 'stack-smashing' or 'stack-overflow' vulnerabilities of
   the operating system.  The script may spool large submissions to disk
   or other buffering media, but a rapid succession of large submissions
   may result in denial of service conditions.  If the CONTENT_LENGTH of
   a message-body is larger than resource considerations allow, scripts
   should respond with an error status appropriate for the protocol
   version; potentially applicable status codes include 503 'Service
   Unavailable' (HTTP/1.0 and HTTP/1.1), 413 'Request Entity Too Large'
   (HTTP/1.1), and 414 'Request-URI Too Large' (HTTP/1.1).

   Similar considerations apply to the server's handling of the CGI
   response from the script.  There is no limit on the length of the
   header or message-body returned by the script; the server should not
   assume that statically allocated buffers of any size are sufficient
   to contain the entire response.

9.7.  Stateless Processing

   The stateless nature of the Web makes each script execution and
   resource retrieval independent of all others even when multiple
   requests constitute a single conceptual Web transaction.  Because of
   this, a script should not make any assumptions about the context of
   the user-agent submitting a request.  In particular, scripts should
   examine data obtained from the client and verify that they are valid,
   both in form and content, before allowing them to be used for
   sensitive purposes such as input to other applications, commands, or
   operating system services.  These uses include (but are not limited
   to) system call arguments, database writes, dynamically evaluated
   source code, and input to billing or other secure processes.  It is
   important that applications be protected from invalid input
   regardless of whether the invalidity is the result of user error,
   logic error, or malicious action.

   Authors of scripts involved in multi-request transactions should be
   particularly cautious about validating the state information;
   undesirable effects may result from the substitution of dangerous
   values for portions of the submission which might otherwise be
   presumed safe.  Subversion of this type occurs when alterations are
   made to data from a prior stage of the transaction that were not
   meant to be controlled by the client (e.g., hidden HTML form
   elements, cookies, embedded URLs, etc.).




 
RFC 3875                    CGI Version 1.1                 October 2004


9.8.  Relative Paths