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.
Nothing
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 not
--
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 session
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
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 insecure
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
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
--
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.
In
--
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
--- 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
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]
11 matches
Mail list logo
