[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <40A4310D-5375-4587-AE6C-21BA1634E842@xs4all.nl>
Date: Mon, 20 Mar 2006 22:23:51 +0100
From: Hans Wolters <hans.wolters@...all.nl>
To: bugtraq@...urityfocus.com
Subject: Re: Invision Power Board v2.1.4 - session hijacking
Matt,
On 17-mrt-2006, at 10:26, matt@...isionpower.com wrote:
p.s. ^^^ that email address does not work, and earlier reply got
bounced.
> My problem with this report is this:
>
> 1) You've not even read the IPB code. You've stated elsewhere that
> "using sessions in the URL may appear in JS pop-up windows". IPB
> does NOT do this. IPB removes the session ID for all links,
> including JS code when cookies are enabled.
This is not always possible. Whenever transparent sessions are used
(a php setting) it will, in some cases, add the id's after you
printed the last character. We've seen that on a project we are
working on now. You state that javascript
can be removed, if so then that is fine but we all know that new code
might be a risk. Regenerating the session on every page would reduce
the time a session id is valid.
As for the IPB code, I already stated that I am not willing to buy a
version just to check it. The forum got
offered to us. It is not on one of the machines I can access.
However, the behaviour showed what was done.
>
> 2) You're missing the point. As stated elsewhere, IPB uses a
> similar session tracking method to both PHP's own session handler
> and other proprietry methods.
I am not missing the point. As I already explained to 'exon' it will
be safer if you regenerate the session
id once people login, switch to a new page, etc... If you do not do
that then the danger exists as long as
the session is alive.
> 3) Security isn't derived from one not being able to authenticate
> as the user by knowing their session ID, user IP and user agent -
> it's by making it extremely difficult to gather this information in
> the first place.
This wasn't hard.
> Lets look at this objectively. How are you going to know what
> another users session ID is unless they post a link to a site
> they're active on in a blog entry? Lets say they post a link to a
> board on their blog entry. First, their session will expire after
> 30 minutes of no activity - so a potential hacker has a 30 minute
> window to find out their IP address and user agent.
A blog would be more difficult. However, when I can direct them to a
site where I can access the logfiles then
I do have both the user agent and the session id once it is connected
to the url (it will show up in the referer).
> I'm not stupid enough to say that can't be done; but I am realistic
> to know that no one is going to go to that trouble when they could
> invest that time in attacking the server in other ways.
That is a choice.
> Finally, I've been using this session code for over 5 years in
> various products and I know not of a single case where one has had
> their session hijacked using any methods you've stated.
>
> Yes, in an office environment, if one "forgets" to log out and
> close the browser window, anyone else who has access to that
> machine will be logged in as that user - but that is not IPBs
> responsibility any more than it is a car manufacturers
> responsibility to ensure that a car cannot be stolen when the alarm
> is disengaged and the keys in the ignition.
A car manufacturer will provide tools to prevent getting it stolen
(alarm, keys to lock the car, etc....)
Again, it is your choice. I am just stating what is possible on
certain php installations with IPB.
Regards,
Hans
Powered by blists - more mailing lists