On 11/8/05 9:32 PM, Richard Lynch wrote:
Call me crazy, but the session_id is already going in/out through
Cookie headers.
So, really, it's not THAT much less secure for it to go in POST, and
only nominally less secure to go in GET, is it?...
Okay, you're crazy. ;-) j/k [Hey, Richard!]
Yeah, it's going out through the Cookie headers, so a POST (in this case
would be no less secure than sending it through the Cookie). A sniffer
is a sniffer is a sniffer, as they say--or something like that.
I was thinking more of a GET request to the other domain, which would
require passing the session id through the querystring. Like you said,
it's probably nominally less secure, but there's more chance for exposure.
With Cookie and POST, the attacker would basically need to sniff for the
person's session id in order to hijack it, but when you pass the session
id through the querystring, users are prone to bookmark the page, send
the link to friends, post the link to a Web site, etc., all the while
exposing their session, and, in essence, forcing every user to use their
session. This actually performs two kinds of attacks: session fixation
and session hijacking. It's fixation because the user is forcing
everyone to use the same session ID (even though they don't know they're
doing this) and it can lead to session hijacking by people who know
what's going on.
There are ways to prevent this, such as always requiring authentication
(by logging in) before performing a sensitive action and always
generating a new session ID when a user logs in, but I think it's just
as important to mitigate these types of attacks by reducing the exposure
of the session ID as much as possible.
Now, even on the other domain (domain B), it becomes difficult to know
for sure that the user using the session is the proper user (from domain
A). Sure, you can check the IP and an assortment of the headers the
browser sends to get an idea about whether the user is the same one from
the session on domain A, but I think it just makes sense to force the
user to authenticate themselves again (assuming that we're talking about
authenticated users). This ensures that the user using that session is
the proper user, but, at this point, we can just create another session
for domain B and not even worry about sharing the session.
I guess some kind of cross-site scripting hack might read HTML but not
Cookies, though, really, you'd think most XSS hacks would focus on
cookies at least as much as HTML source...
There is some argument in favor of not sending/getting the session_id
back and forth AS MUCH just to give it a more fleeting existence on
the wire for snoopers, but the difference between COOKIE/POST/GET data
integrity/security from snooping seems negligible to this naive user.
Maybe this is just a knee-jerk reaction to all the mis-information
about POST being "more secure" than GET that floats all over the 'net.
:-)
Indeed, neither are secure, but GET increases the risk of exposure.
[Hi Ben!]
--
Ben Ramsey
http://benramsey.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
