view release on metacpan or  search on metacpan

README  view on Meta::CPAN

protocol designed to defend against attacks which exploit known cookie 
vulnerabilities.


2.  Summary of Features
-----------------------

   * Secure sharing of multi-level credentials within and across DNS domains.
   * Support for different representations of credentials with the ability to 
     chain and interoperate between them.
   * Built-in defense against on-line guessing attacks.
   * Built-in session timeout, both idle and hard-limit.
   * Built-in SU-type function for admins to switch user ID's.
   * Encapsulated database interface.


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

Suppose in a heterogeneous environment with many .acme.com hosts, an
authentication system is setup to share cookies between bruce.acme.com
and wendel.acme.com.  Upon successful login, bruce issues an .acme.com
cookie to a user who can then request resources from wendel.  Even
if you don't admit either passive or active adversaries on the network, the 
user's identity might still be compromised.  If hopkins.acme.com is
compromised and the user visits *any* other compromised site, say
www.fantasyland.org, a trojan .html document with a malicious image
tag <img src="http://hopkins.acme.com">, will send the identity cookies 
directly to hopkins who is waiting for them.  (This is the old 3rd-party
cookie bugaboo exploited by *click.com.)

Solution: Regardless of the mechanism used for representing user 
credentials (cookies, URL's, etc), there will be some set of hosts
included in the system (whether spanned by wildcard matches or server
side redirects).  No untrusted host should be in that set.  This is 
just classic host security.


Issue 3:  Secure Wildcard Cookies Don't Always Have Intended Protection

The underlying weakness in issue (2) is perhaps more relevant for so-called 
secure cookies (with secure flag is set).  Even where host security can be 
assumed across a large heterogeneous environment, there might be one
host which only supports 40-bit SSL, say hopkins.acme.org again.  Supposed 
bruce and wendel were properly configured for only 128-bit cipher suites 
and issued only secure cookies for the .acme.com domain.  Then a malicious 
image tag <img src="https://hopkins.acme.com"> will force a connection
to hopkins.  If 40-bit encryption is negotiated (see next issue), the user's
credentials are reduced from 128-bits to 40-bits.
   Unlike issue (2), we cannot pass this off as a matter of host security, 
because hopkins is not compromised.  A passive adversary who obtains
a 40-bit encrypted copy of the credentials.  He can then do an offline crack 
in order to assume the users identity.  Naively, bruce and wendel might
think an implausible work factor of 2^128 would be necessary.

Solution: A cookie-based authentication module must be configurable
to treat a wildcard .acme.com domain as essentially weak.  Cookies
used for strong authentication must be either confined to a single
host, or to a more restrictive wildcard like '.secure.acme.com'.  The 
demo software shows examples of both.


Issue 4: SSLv2 Rollback Vulnerability

An active adversary can force an SSL client and server to negotiate the
*weakest* cipher suite which they share in common [SSL].  Recall that the 
SSL cipher negotiation was intended to negotiate the *strongest* cipher 
suite.  Thus under the stronger threat model of an active adversary, we are 
far more likely to find a target such as hopkins to exploit in issue (3).  
For a variety of reasons (sometimes legal and political), the larger the 
DNS domain (in number or geography) the greater the likelihood of there 
being one host which supports SSLv2 and 40-bits, or a newer SSL/TLS but 
only 40-bits.

Solution: Same as issue (3).


Issue 5:  Persistent Cookies are Often Stored in Filesystem

If a cookie is ever set with a future expiration date, browsers will copy 
it, in the clear, to the filesystem for use upon next invocation of the 
browser.  Such filesystems often shared across networks and so are
available to a wide variety of users.

Solution:  The fundamental session cookies in secure system should be
ephemeral.  This does not preclude the use of persistent cookies as an
initial user identity token if the threat model is appropriate (perhaps
on a single-user laptop).


5.  Security Architecture
-------------------------

5.1  The Authentication Processes
---------------------------------

There are three notions of 'authentication' in Apache::SecSess.

    User Authentication: This serves to identify the user and to provide
        a suitable proof of that identity.  This is typically a login form,
        which interrupts the user, but it might transparently use other 
        credentials which are already available electronically like an X.509
        client certificate or a persistent cookie.