lol, neither. It was from a site I had coded. I read an article
about session fixation and it seemed vulnerable based on what I read,
but when I tested it, it didn't seem to be and I wasn't sure why.
What made you think that?
- Sean
On Feb 16, 2009, at 8:16 PM, Ashley Sheridan wrote:
On Mon, 2009-02-16 at 13:49 -0500, Sean DeNigris wrote:
Hi all! The following code seems like it should be open to session
fixation attacks, but is not. Why?!
This is the beginning of the private page...
<?php
session_start();
if (!isset($_SESSION['user']))
{
header("Location: http://[address of login page]?
requestedpage=[token
for this page]");
exit();
}
....
If an attacker caused a known user to request the above page with ?
PHPSESSID=1234, the session_start would then register 1234 as the
current session
This is from the login page...
<?php
if($_POST['[a posted form var]'])
{
// check submitted credentials against known users
$status = authenticate(...);
// if user/pass combination is correct
if ($status == 1)
{
// initiate a session
session_start();
// register some session variables
$_SESSION['XXXXXX] = filter($_POST['XX']);
// redirect to protected page
header("Location: ...[requested page]);
exit();
}
}
When the user logged in above, the session_start would use the
session
cookie from the first session_start above and have a validated
session
with an SID known to the attacker.
However, the top snippet does not cause an SID to be recorded in a
cookie, but the bottom one does. Hence, the attack is prevented, but
why?
Thanks, cheers!
- Sean
Erm, is this a trick question or your homework?
Ash
www.ashleysheridan.co.uk
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
