Re: Invision Power Board v2.1.4 - session hijacking
Matt,
On 17-mrt-2006, at 10:26, matt@xxxxxxxxxxxxxxxxx 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