On Tue, 17 Jun 2003, Ian Grigg wrote:
> does anyone know how the easy way to secure a PHP website against
> session_fixation?
I noticed that the PHP documentation includes a new section on session
insecurity and a link to the paper on session fixation.
http://www.php.net/manual/en/ref.session.ph
Ben Laurie wrote:
>
> James A. Donald wrote:
> > I do not see how this flaw can be avoided unless one
> > consciously takes special measures that the development
> > environment is not designed or intended to support.
>
> The obvious answer is you always switch to a new session after login.
> No
[EMAIL PROTECTED] wrote:
When the user logs in, the server stores the client's IP address in a
session variable (so it's stored at the server end - the client just gets a
session id). Authentication of subesequent pages is assumed only if the
client's IP address matches the IP address stored in th
--
James A. Donald:
> > Which is fine provided your code, rather than the framework
> > code provided the cookie, and provided you generated the
> > cookie in response to a valid login, as Ben Laurie does..
> > The framework, however, generally provides insecure
> > cookies.
Ng Pheng Siong
On Mon, Jun 16, 2003 at 10:47:04AM +0100, [EMAIL PROTECTED] wrote:
> session id). Authentication of subesequent pages is assumed only if the
> client's IP address matches the IP address stored in the session variable
> corresponding to the client's session.
> Is this secure? If not, why not?
It's
I've come up with a (very simple) defence against session hijacking and so
on. It's probably flawed (I admit I'm not an expert on these things), so if
someone could please tell me why it won't work, I'd be very grateful.
When the user logs in, the server stores the client's IP address in a
sessio
I think he means higher level frameworks, web programming libraries,
toolkits, and web page builder stuff; not hooks into SSL sessions.
Not to say that a hook into an SSL session is not a good place to get
an application sessions identifier from -- it would be, presuming that
you can't trick a brow
On Sun, Jun 15, 2003 at 11:34:55AM -0700, James A. Donald wrote:
> Which is fine provided your code, rather than the framework
> code provided the cookie, and provided you generated the cookie
> in response to a valid login, as Ben Laurie does.. The
> framework, however, generally provides insec
> The framework, however, generally provides insecure cookies.
No I'm confused. First you said it doesn't make things like the
session-ID available, and I posted a URL to show otherwise. Now you're
saying it's available but insecure?
/r$
--
Rich Salz Chief Security Archi
--
On 14 Jun 2003 at 19:07, Rich Salz wrote:
> When I've done login and state management, it's all
> maintained on the server side. It's completely independant
> of SSL sessions -- that's transport, has no place in
> application -- just like it's completely independant of
> HTTP/1.1 sessio
> To avoid it, one has to roll one's own state management, for
> example by providing one's own cryptographically strong login
> label in the Urls in the web page one generates in response to
> a login, the label acting as primary key to a table of
> currently active logins.
When I've done login a
--
On 14 Jun 2003 at 21:42, Ben Laurie wrote:
> The obvious answer is you always switch to a new session
> after login. Nothing cleverer is required, surely?
I had dreamed up some rathe complicated solutions.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQ
Ben dude wrote:
> The obvious answer is you always switch to a new session after login.
> Nothing cleverer is required, surely?
Well particularly the issue is your login URL should not accept an
existing session identifier supplied by the browser (what the author
of the session fixing paper calls
James A. Donald wrote:
> --
> James A. Donald wrote:
>
>>>This flaw is massive, and the biggest villain is the server
>>>side code created for Apache.
>
>
> Ben Laurie
>
>>This isn't the case. I analysed several sites I work on for
>>attacks of the type described when this paper first cam
--
Rich Salz:
> > The following environment variables are exported into SSI
> > files and CGI scripts:
> > SSL_SESSION_ID The hex-encoded SSL session id
On 14 Jun 2003 at 18:24, Daniel Carosone wrote:
> The problem is that this is not especially useful in
> practice, if your client is I
--
James A. Donald wrote:
> > This flaw is massive, and the biggest villain is the server
> > side code created for Apache.
Ben Laurie
> This isn't the case. I analysed several sites I work on for
> attacks of the type described when this paper first came out.
> None of them were vulnerable.
James A. Donald wrote:
> --
> On 12 Jun 2003 at 16:25, Steve Schear wrote:
> http://www.acros.si/papers/session_fixation.pdf
>
> Wow.
>
> This flaw is massive, and the biggest villain is the server
> side code created for Apache.
>
> When you login to your bank, your e-gold account, your
On Fri, Jun 13, 2003 at 09:58:32PM -0400, Rich Salz wrote:
> The following environment variables are exported into SSI files
> and CGI scripts:
> SSL_SESSION_ID The hex-encoded SSL session id
The problem is that this is not especially useful in practice, if
your client is IE. Essentially, you
> To make the system entirely secure against this attack, we need
> to be able to enforce a one to one mapping between login
> sessions and https sessions. The existing tools for writing
> server side code do not provide us with any direct means of
> enforcing such a relationship.
I'm not paying
--
On 12 Jun 2003 at 16:25, Steve Schear wrote:
> > > http://www.acros.si/papers/session_fixation.pdf
"James A. Donald"
> > Wow.
> >
> > This flaw is massive, and the biggest villain is the server
> > side code created for Apache.
On 13 Jun 2003 at 11:16, tom st denis wrote:
> You really la
--- "James A. Donald" <[EMAIL PROTECTED]> wrote:
> --
> On 12 Jun 2003 at 16:25, Steve Schear wrote:
> http://www.acros.si/papers/session_fixation.pdf
>
> Wow.
>
> This flaw is massive, and the biggest villain is the server
> side code created for Apache.
You really lack some fundamental u
--
On 12 Jun 2003 at 16:25, Steve Schear wrote:
http://www.acros.si/papers/session_fixation.pdf
Wow.
This flaw is massive, and the biggest villain is the server
side code created for Apache.
When you login to your bank, your e-gold account, your
stockbroker, or your domain registrar, someo
http://www.acros.si/papers/session_fixation.pdf
"A Jobless Recovery is like a Breadless Sandwich."
-- Steve Schear
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
23 matches
Mail list logo
