Stefan Esser wrote:
beeing able to detect if a session was already started has nothing todo
with session fixation attacks.
It does have *something* to do with session fixation attacks. In that
if you are given a session ID that doesn't exist it's most likely an
expired session ID (make a new on
Sascha Schumann wrote:
They are not helpful for various reasons. e.g. if you need
to ask whether a session was started, your architecture is
broken (a central place needs to manage sessions; that single
place must know whether a session has been started).
Generally speaking I agree
Chris Shiflett wrote:
It would raise the bar, but that's about it.
But isn't that what increasing application security is all about?
Wouldn't that be an example(albeit an arguably small one) of defense in
depth?
An attacker visits your site (to initiate the session), determines the
assigned se
These changes in and of themselves will offer zero increased protection
against session fixation/hijacking. But they do prove useful when used
together for building a custom session handler trying to prevent session
fixation/hijacking.
Here's how the new functionality might be applied after di
I recently wrote a new custom session handler in PHP5. In the process
I've made a couple of changes within ext/session/ that I would like to
see in the official PHP distribution.
Please consider the following patches for inclusion into PHP.
One change adds a PHP function session_is_started() to
I am by no means an expert with OOP, so if this is a blatantly retarded
question please excuse my ignorance.
Given this code:
class B
{
function bar()
{
// blah
}
}
$instance = B::foo();
?>
output is "A::foo".
Is this correct? I would expect (want maybe :) ) to see output as
