Re: Newbie HTTPS/SSL question

[jamesworld () intelligencia com]

That session -id should expire in a very short time after the connection 
drops or a absolute timeout value is reached.

So perhaps within that timeout period, if you "could" associate a new 
connection with the existing session, you might be able to do 
it.   Alas.... we run into the random access of what you can get using a 
buffer overrun.  I theorize, that if I could sniff your traffic and decode 
the SSL (:-) or know the IP of a particular user, one could cause a buffer 
overflow and hijack the session......of course we might also be talking 
about a line that was cut out of the movie Swordfish  :-)

If you are in charge of the server, check the docs on the webserver 
software and check the values of the timeouts.  try internal testing.

My guess, is that you won't find much.

The error page is dynamically created at point of serving.  it dumps the 
session, cookie, and other asunderies that web sessions give (referrer, 
connection ID, operating system etc)


Anyone else out there see any thing I'm missing?

HTH,

-James

At 06:20 12/15/2003, Darragh O'Brien wrote:
> Hi,
>
> Thanks for the pointers James. The reason I ask is because I came
> across a web site which functions as follows:
>
> When we go to the site a session-id is immediately assigned and
> becomes part of URLs accessed over HTTP. When it comes to
> purchasing something, credit card details etc. are passed over
> HTTPS. Great. However, should a user make an error in filling in,
> say their e-mail address, an error page is generated containing the
> entire form (credit card details included). The problem is that the
> URL of the error page is entirely determined by the session-id passed
> about initially over HTTP. So at the very least a web admin could log
> URLs, grab session-ids and probe for the error page. This is a problem,
> right?
>
> I thought that by tying the error page to a particular HTTPS session
> they might solve this problem. It looks like that's not possible.
>
> Cheers,
> Darragh
>
> On Thursday 11 December 2003 19:14, jamesworld () intelligencia com wrote:
> > Darragh,
> >
> > You allude to the answer to your question in your question:  session
> > Do a google search on http session state and get an understanding of that,
> > then look at https session states.
> > Take a look at:
> > http://jan.netcomp.monash.edu.au/ecommerce/session.html
> >
> > for a real brief, clean look at what happens under the hood.
> >
> > Short answer:  no  :-)
> >
> > Session keys are supposed to be unique.  If not, you'd have a huge replay
> > attack problem.
> >
> > great question.  it shows that you are actually thinking about the inner
> > workings.  Keep up the questions, both internal and to the list.
> >
> > -James
> >
> > At 07:21 12/11/2003, Darragh O'Brien wrote:
> > >Hi,
> > >
> > >Is it possible to tie a web page to a particular HTTPS session
> > >so that when requested it is always sent back encrypted with
> > >the server key associated with that session? That way, guessing
> > >the URL of a dynamically created page would not be enough
> > >since we don't have the client key to decrypt it?
> > >
> > >Or am I talking nonsense!?
> > >
> > >Thanks,
> > >Darragh
> > >
> > >--------------------------------------------------------------------------
> > >-
> > > -------------------------------------------------------------------------
> > >---
> >
> > ---------------------------------------------------------------------------
> > ---------------------------------------------------------------------------
> >-


---------------------------------------------------------------------------
----------------------------------------------------------------------------