|
SESSIONS
Cookies are used by default for user $Session support ( see OBJECTS ).
In order to track a web user and associate server side data
with that client, the web server sets, and the web client returns
a 32 byte session id identifier cookie. This implementation
is very secure and may be used in secure HTTPS transactions,
and made stronger with SecureSession, HTTPOnlySession and
ParanoidSession settings (see CONFIG ).
However good cookies are for this kind of persistent
state management between HTTP requests, they have long
been under fire for security risks associated with
JavaScript security exploits and privacy abuse by
large data tracking companies.
Because of these reasons, web users will sometimes turn off
their cookies, rendering normal ASP session implementations
powerless, resulting in a new $Session generated every request.
This is not good for ASP style sessions.
Cookieless Sessions
*** See WARNING Below ***
So we now have more ways to track sessions with the
SessionQuery* CONFIG settings, that allow a web developer
to embed the session id in URL query strings when use
of cookies is denied. The implementations work such that
if a user has cookies turned on, then cookies will be
used, but for those users with cookies turned off,
the session ids will be parsed into document URLs.
The first and easiest method that a web developer may use
to implement cookieless sessions are with SessionQueryParse*
directives which enable Apache::ASP to the parse the session id
into document URLs on the fly. Because this is resource
inefficient, there is also the SessionQuery* directives
that may be used with the $Server->URL($url,\%params) method to
generate custom URLs with the session id in its query string.
To see an example of these cookieless sessions in action,
check out the ./site/eg/session_query_parse.asp example.
*** WARNING ***
If you do use these methods, then be VERY CAREFUL
of linking offsite from a page that was accessed with a
session id in a query string. This is because this session
id will show up in the HTTP_REFERER logs of the linked to
site, and a malicious hacker could use this information to
compromise the security of your site's $Sessions, even if
these are run under a secure web server.
In order to shake a session id off an HTTP_REFERER for a link
taking a user offsite, you must point that link to a redirect
page that will redirect a user, like so:
<%
# "cross site scripting bug" prevention
my $sanitized_url =
$Server->HTMLEncode($Response->QueryString('OffSiteUrl'));
%>
<html>
<head>
<meta http-equiv=refresh content='0;URL=<%=$sanitized_url%>'>
</head>
<body>
Redirecting you offsite to
<a href=<%=$sanitized_url%> >here</a>...
</body>
</html>
Because the web browser visits a real page before being redirected
with the <meta> tag, the HTTP_REFERER will be set to this page.
Just be sure to not link to this page with a session id in its
query string.
Unfortunately a simple $Response->Redirect() will not work here,
because the web browser will keep the HTTP_REFERER of the
original web page if only a normal redirect is used.
|
|
