lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ