Personally I find that the PHP session ID are really unsecure, for my
website I have created my own sessions based on ip address. The problem is
that if the user used multi-proxy he has to reload the login every time it
change... The cookie is encrypted with a key contain in a part of the url
session id with a private server key... perhaps is it a way ...
Good luck
G.
-----Message d'origine-----
De : Achim Hoffmann [mailto:kirke11@securenet.de]
Envoyé : lundi 18 juillet 2005 16:41
À : webappsec@securityfocus.com
Objet : Re: Maia Mailgaurd http://www.renaissoft.com/maia/
On Mon, 18 Jul 2005, Chuck wrote:
!! Responses below....
!!
!! On 7/16/05, Christopher Canova <ccanova@reachone.com> wrote:
!!
!! > We are currently in a discussion about
!! > using the PHP Session ID in the URL and whether to strictly enforce
!! > cookies to avoid session hijacking. The fear is that we could possibly
!! > be passing along the referral information to a spammer willing to
!! > exploit such a vuln. Some of the discussion is related closely to this
!! > mailing list, so I wanted to see what everyone thought about it.
!!
!! > What are the risks to enforcing session handling using cookies? Will it
!! > break functionality for many people? Are the risks of including the SID
!! > in the URL worse than cookies?
!!
!! In short, you are better off putting the session id in a cookie than
!! putting it in the URL. You are right that referrer headers are one
!! way that a URL session id can leak. It may also be logged in proxies
!! or firewalls.
In short, it is much simpler to steal session ids from cookies than from
URL, exceptions see below. For stealing cookies, we just need XSS somewhere
on the same server (or if designed bad, on the same domain) and a simple
document.cookie
Getting the session id from the current URL is also simple, but if it is
just in a link (href= action= attribute) then things get more complicated,
AFAIK not possible without parsing the whole DOM tree.
Cookies are unsecure, unfortunately.
And more worse, most application don't take care for example by using FQDN
and proper path= attribute and secure flag.
!! There is also the problem that users do not expect sensitive
!! information in the URL. They may send the URL to someone in an IM or
!! email or even post it on a mailing list or blog, not realizing that it
!! will give whoever follows the URL access to their account (at least
!! until the session ID expires).
Agreed.
But it's the responsibility of the application to ensure a correct and
secure session management (one of the initial questions).
!!
!! Finally, I don't like the idea of displaying the session ID on the
!! screen. It makes the user vulnerable to shoulder surfing and again,
!! they may send someone or post a screenshot of the application not
!! realizing that the session ID is there in the URL.
I agree that a session id in the URL is very sensitive data, but only as
long as the session is active (which is the resposibility of the
application).
{-: Achim
