Apache-SecSess

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

3.  Known Security Issues with HTTP Cookies
-------------------------------------------

Issue 1: The Caching Problem

Even if no passive or active adversary is sitting between the client
and server, an unauthorized user might still see the wrong data because
any web-caching device along the way might cough up a request such
as http://www.acme.com/creditcards.txt without ever referring it to
the server, if a previous authorized user made the same request.  This
is a no-no for the web-cache to do, but it happens anyway.

Solution: There is no real solution, and RFC2964 is correct to discourage
plaintext cookie-based authentication even over secure networks (like on an 
intranet).  On the other hand, this really is a bug (what if web-caches 
ignored POST arguments).


Issue 2:  Wildcard Cookies Don't Always Go Where Intended

demo/httpdconf/httpd.sec2.conf  view on Meta::CPAN

    # in case of a tie during content negotiation.
    #
    # Just list the languages in decreasing order of preference. We have
    # more or less alphabetized them here. You probably want to change this.
    #
    <IfModule mod_negotiation.c>
        LanguagePriority en da nl et fr de el it ja kr no pl pt pt-br ru ltz ca es sv tw
    </IfModule>

    #
    # AddType allows you to tweak mime.types without actually editing it, or to
    # make certain files to be certain types.
    #
    # For example, the PHP 3.x module (not part of the Apache distribution - see
    # http://www.php.net) will typically use:
    #
    #AddType application/x-httpd-php3 .php3
    #AddType application/x-httpd-php3-source .phps
    #
    # And for PHP 4.x, use:
    #

demo/httpdconf/httpd.sec2.conf  view on Meta::CPAN

#    </Directory>

    #
    # Enable/disable the handling of HTTP/1.1 "Via:" headers.
    # ("Full" adds the server version; "Block" removes all outgoing Via: headers)
    # Set to one of: Off | On | Full | Block
    #
#    ProxyVia On

    #
    # To enable the cache as well, edit and uncomment the following lines:
    # (no cacheing without CacheRoot)
    #
#    CacheRoot "/usr/local/apache/proxy"
#    CacheSize 5
#    CacheGcInterval 4
#    CacheMaxExpire 24
#    CacheLastModifiedFactor 0.1
#    CacheDefaultExpire 1
#    NoCache a_domain.com another_domain.edu joes.garage_sale.com

rfc/rfc2109.txt  view on Meta::CPAN

                                                 Netscape Communications
                                                           February 1997


                    HTTP State Management Mechanism

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

1.  ABSTRACT

   This document specifies a way to create a stateful session with HTTP
   requests and responses.  It describes two new headers, Cookie and
   Set-Cookie, which carry state information between participating
   origin servers and user agents.  The method described here differs
   from Netscape's Cookie proposal, but it can interoperate with

rfc/rfc2964.txt  view on Meta::CPAN

   merely presented a cookie which had been previously associated with
   the user.

   Similarly, HTTP State Management SHOULD NOT be used to authenticate
   user requests if unauthorized requests might have undesirable side-
   effects for the user, unless the user is aware of the potential for
   such side-effects and explicitly consents to such use.  For example,
   a service which allowed a user to order merchandise with a single
   "click", based entirely on the user's stored "cookies", could
   inconvenience the user by requiring her to dispute charges to her
   credit card, and/or return the unwanted merchandise, in the event
   that the cookies were exposed to third parties.

   Some uses of HTTP State Management to identify users may be
   relatively harmless, for example, if the only information which can
   be thus exposed belongs to the service, and the service will suffer
   little harm from the exposure of such information.

3.  User Interface Considerations for HTTP State Management

   HTTP State Management has been very controversial because of its

rfc/rfc2965.txt  view on Meta::CPAN

Category: Standards Track                             Epinions.com, Inc.
                                                            October 2000


                    HTTP State Management Mechanism

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

IESG Note

   The IESG notes that this mechanism makes use of the .local top-level

utils/mkcerts  view on Meta::CPAN

#
# cmd line args
#
$usage = "usage: $0 [-d] [-e] [-n]";
getopts('den') || die $usage;

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # 

#
# you must edit all the config info below
#

# # # # # # # # # # # # # # Begin Configuration # # # # # # # # # # # # # # #

# security
$rsabits = 2048;  # number of RSA modulus bits
$digest = 'sha1'; # or 'md5'
$cadays  = 4*365; # days of validity for root CA
$days	 = 2*365; # days of validity for signed certs