Joshua Chamas <[EMAIL PROTECTED]> writes:
> It reoccured to me just now (back from a sessions methods discussion a long
> time ago) that these query string cookies might show up in the referer logs
> of other sites if you have offsite links on your session id pages. I tried a
> workaround just n
Hi Joshua,
>I read the article, and found it kind of funny that the author
>thought that client side JavaScript was a better solution than
>Cookies... which do you think get turned off more by end users ?
Personally, javascript scares me more then anything else... its flakey
and you never kn
sorry - you peaked my interest so I have to jump the gun a little.
are you basing it on unique host names which are resolved by
some type of dns delegation?
if so, only problem is with SSL pages. the host name has to
match the one in the certificate otherwise the browser will
give a warning. in
> "Serge" == Serge Sozonoff <[EMAIL PROTECTED]> writes:
Serge> Hello,
>> It will work fine, but the problem still remains that the
>> incoming page URL has the session-id in it, so that when you go
>> offsite, the referer header sent by the client has the client's
>> session id in it still
Hello,
>It will work fine, but the problem still remains that the
>incoming page URL has the session-id in it, so that when you go
>offsite, the referer header sent by the client has the client's
>session id in it still, and the unethical webmaster could easily
>then access the users sessions
Serge Sozonoff wrote:
>
> Hello,
>
> >It will work fine, but the problem still remains that the
> >incoming page URL has the session-id in it, so that when you go
> >offsite, the referer header sent by the client has the client's
> >session id in it still, and the unethical webmaster could easil
Remi Fasol wrote:
>
> > On Tue, 7 Dec 1999, Joshua Chamas wrote:
> > > > > I am going to give ASP developers a session
> > option, it should be
> > > > > possible to make secure.
>
> Stas Bekman wrote:
> > But if you intercept the redirection, why not to
> > strip/modify the
> > HTTP_REFER heade
> how about a call to something like
>
> evil perl session pirates
>
> that calls something which strips the referer and
> redirects.
It won't work because the referer (sic) is set by the client, not by the
server. HTTP and HTML provide no way to tell the client to change the
referer. Using Ref
> On Tue, 7 Dec 1999, Joshua Chamas wrote:
> > > > I am going to give ASP developers a session
> option, it should be
> > > > possible to make secure.
Stas Bekman wrote:
> But if you intercept the redirection, why not to
> strip/modify the
> HTTP_REFER header at the server side?
how about a cal
On Tue, 7 Dec 1999, Joshua Chamas wrote:
> Bill Desjardins wrote:
> >
> > > I don't need these non-cookie secure sessions myself, but if
> > > I am going to give ASP developers a session option, it should be
> > > possible to make secure.
> >
> > Here is how I solved the problem with redirectin
Bill Desjardins wrote:
>
> > I don't need these non-cookie secure sessions myself, but if
> > I am going to give ASP developers a session option, it should be
> > possible to make secure.
>
> Here is how I solved the problem with redirecting offsite when I am using
> the URI for session tracking
> Does this really work ? I tried this locally, and it didn't.
> The HTTP_REFERER was still sent as from the original page
> even though there was an intervening redirect script.
> This referer had the original session-id in it.
>
> So a page like: page.asp?session-id=aasdfdasfdsafadsfadsf
>
Jeffrey Baker wrote:
>
> Secure sessions are hard work. You need to sit down and evaluate whether or not you
>actually need *secure* sessions. If you decide that enough is at stake to really
>tighten the screws, then read on.
>
> The problem of the session ID in HTTP_REFERER is easy to tackl
Secure sessions are hard work. You need to sit down and evaluate whether or not you
actually need *secure* sessions. If you decide that enough is at stake to really
tighten the screws, then read on.
The problem of the session ID in HTTP_REFERER is easy to tackle. You just need to
rewrite ev
Matt Sergeant wrote:
>
> I don't think there's a real option for making it secure. However I think
> the prefix (or postfix) method used in the Eagle book is a good one. Simply
> change the config to:
>
> PerlTransHandler Apache::ASP
>
> and in the handler go:
>
> sub handler {
> my $url_sessi
On Tue, 07 Dec 1999, Joshua Chamas wrote:
> What options are there anyone, for real cookieless sessions,
> without this security risk ??? We can't use IP authentication
> because of proxies/NAT, maybe an SSL cert, but not everyone has
> this, the UserAgent is not stratified enough to mean much,
Serge Sozonoff wrote:
>
> Hi Joshua,
>
> I was wondering if you could give us a little update on the status of
> Sessions w/o cookies for Apache::ASP?
>
> Have you started coding it already or is it at the bottom
> of a big list of things to do?
>
> Many Thanks,
>
> Serge
>
I have been work
17 matches
Mail list logo
