Home page logo
/

basics logo Security Basics mailing list archives

Re: Newbie HTTPS/SSL question
From: jamesworld () intelligencia com
Date: Mon, 15 Dec 2003 20:49:40 -0600

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
> >
> >--------------------------------------------------------------------------
> >-
> > -------------------------------------------------------------------------
> >---
>
> ---------------------------------------------------------------------------
> ---------------------------------------------------------------------------
>-


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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault