Re: [PHP] Why is this secure?
On Mon, 2009-02-16 at 20:23 -0500, Sean DeNigris wrote:
> 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...
> >> >> 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...
> >> >> 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['XX] = 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
> >
>
>
Lol, just seemed test-like, and I couldn't spot anything glaringly
obvious.
Ash
www.ashleysheridan.co.uk
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Why is this secure?
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...
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...
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
Re: [PHP] Why is this secure?
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...
> 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...
> 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['XX] = 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
[PHP] Why is this secure?
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...
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...
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
