|
NAMEhttp_servlet_cookieauth —
HTTP secure cookie authentication servlet
LIBRARYPDEL Library (libpdel, -lpdel)SYNOPSIS#include <sys/types.h>
#include <stdio.h>
#include <netinet/in.h>
#include <openssl/ssl.h>
#include <pdel/http/http_defs.h>
#include
<pdel/http/http_server.h>
#include
<pdel/http/servlet/cookieauth.h>
struct http_servlet *
int
int
char *
DESCRIPTIONhttp_servlet_cookieauth_create () creates a new servlet
that enforces client authentication using public key cryptography and HTTP
cookies. Any requests that fail to present a valid cookie are redirected to a
login page. The servlet should be registered with a lower order than the other
servlets that it protects, so that it executes first.
redirect and append are used when redirecting a request, and are the same as the arguments to http_servlet_redirect_create(3). authreqd is invoked for every request and is a pointer to a function of this type: typedef int http_servlet_cookieauth_reqd_t(void *arg, struct http_request *req); The arg is the same value supplied to
privkey is a pointer to a PEM-encoded RSA private key. If the HTTP server supports SSL, the server private key may be used for convenience (though this slightly weakens overall security). id points to arbitrary binary data having
length idlen that uniquely identifies the
authenticated resource. Only cookies generated with the same identity and
signed with the same RSA private key will satisfy this servlet (see
The cookiename specifies the name to use for the cookie; multiple cookies with different names may be used simultaneously. When the servlet is destroyed, if destroy is
not
username is an arbirary string that may be
retrieved in a subsequent request by
max_linger, if non-zero, specifies a maximum time in seconds between requests before the cookie becomes invalid. This means each request will cause a new cookie to be generated. If an otherwise valid cookie is received but it was generated more than max_linger seconds ago, it is rejected. expire specifies an absolute time at which the cookie should expire. Cookies presented beyond their expiration time (which should only be sent if the client is broken, malicious, or not synchronized) will be rejected. session_only specifies that the client should be instructed to discard the cookie when the client's session terminates. Implementation of this feature is client-dependent. path and domain may be
The secure flag indicates to the client that this cookie should only be sent over an HTTPS (i.e., encrypted) connection. Implementation of this feature is client-dependent.
Note that it is not necessary to create a servlet in order to use
the SECURITY NOTESBecause public key cryptography is used, as long as the RSA private key is kept secret then there is no known way for an attacker to create a new cookie that appears valid to this servlet. However, if an attacker somehow acquires an existing cookie before its expiration time, it can be presented by the hacker and will fool this servlet into believing that the attacker had previously authenticated.Also, while the information in the cookie includes a secure digital signature that is used to validate the cookie, the cookie itself is not encrypted. In particular, the username will travel across the HTTP connection (and be stored on the browser's computer) unprotected. For these reasons, this servlet should only be used with SSL web servers. Creation of the identity must be done carefully to avoid security holes. The important point is to avoid using the same identity and private key to secure two things that should be considered different from an authentication point of view. Therefore, any information which makes the identity unique to the particular resource being protected is good. A common pitfall is creating an identity by concatenating strings without inserting a separator character that does not appear in the strings. E.g., the concatenation of “abc” and “def” is the same as the concatenation of “ab” and “cdef.” However, “abc:def” is different from “ab:cdef”. Hashing the identity components together is a good way to limit idlen and therefore the size of the cookie. However, if hashing is done a secure hash function such as MD5 or SHA-1 should be used. RETURN VALUEShttp_servlet_cookieauth_create (),
http_servlet_cookieauth_login (),
http_servlet_cookieauth_logout (), and
http_servlet_cookieauth_user () return
NULL or -1 and set errno to an
appropriate value to indicate failure.
The errno value
SEE ALSOhttp_request(3), http_response(3), http_server(3), http_servlet(3), http_servlet_basicauth(3), http_servlet_redirect(3), libpdel(3), md5(3), sha(3), typed_mem(3)Persistent Client State HTTP Cookies, http://www.netscape.com/newsref/std/cookie_spec.html. D. Kristol and L. Montulli, HTTP State Management Mechanism, RFC 2109. HISTORYThe PDEL library was developed at Packet Design, LLC.http://www.packetdesign.com/
AUTHORSArchie Cobbs ⟨archie@freebsd.org⟩BUGSThe client must support HTTP cookies for any of this to work.Only the original Netscape cookie spec is supported; RFC 2109 support should be added.
Visit the GSP FreeBSD Man Page Interface. |