Re: Session Fixation Vulnerability in Web Based Apps

2003-06-17 Thread Ian Grigg
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 cleverer is required, surely?

Having read all these discussions and having looked
in my own PHP code and the PHP documentation, I have
to agree with James D.  This cleverness challenges!

I knew how to start and maintain a session, I think.

(That was no easy task.  The PHP documentation is
a mess, and over the last several versions different
ways started and stopped working...  I'm sure the
obvious answer is to use a better tool, but I'm a bit
stuck with a huge dose of reality at the moment, being
one of the million or so PHP developers, and can't junk
the man-years of habit just this month :-)

I just spent an hour or so skimming the doco for PHP,
and apparently, there is an ability to set another
session id with a call called session_id(), oddly
enough :-)

Which only leaves the problems of a) inventing a new
session id, b) rewriting the code so that it carefully
implements the unclever notion of setting this at the
new login, c) deleting this at logout, and finally d)
praying that this works as expected.

On the face of it, PHP doesn't appear to have much
support for this.  It will require each developer to
(re-)implement their own solution.  I'd love to be
wrong in this:  does anyone know how the easy way to
secure a PHP website against session_fixation?  Or is
it another case of you gotta write it all yourself
again?

Rich Salz wrote:
 From
 http://www.modssl.org/docs/2.8/ssl_reference.html#ToC25
 
 The following environment variables are exported into SSI files
 and CGI scripts:
 SSL_SESSION_ID The hex-encoded SSL session id
 
 Care to try again?

Please.  How does one get access to that in PHP?  That
would be a wonderful answer to a) above.  Which would
only leave me with b) thru d)   :-(

PS:  Steve, thanks for the aviso!  Very interesting
attack!

-- 
iang

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Session Fixation Vulnerability in Web Based Apps

2003-06-16 Thread Matthew Byng-Maddick
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 a question of whether it's secure or not, in any kind of environment
with distributed proxies, it just plain won't work.

A more useful fix is to not allow arbitrary sessionids to be created, and
generate the state on login, and destroy it on logout. There may be a
condition I've missed with this, but I'm not sure.

MBM

-- 
Matthew Byng-Maddick [EMAIL PROTECTED]   http://colondot.net/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Session Fixation Vulnerability in Web Based Apps

2003-06-15 Thread James A. Donald
--
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 management.  A logout page isn't the same as 
 Connection: close :)

 The only thing in the cookie is an opaque identifer.  It's 
 purely random bytes (for which OPenSSL's RANDbytes() is 
 useful),

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. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 hOTy2gXIGpC8U37+/qzVoX8ytaUtHZWZGueU4kX5
 4GiXuHCpc1B85Pv2WN8p5d7FESFJMHlg5qC2hqlGr


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Session Fixation Vulnerability in Web Based Apps

2003-06-15 Thread Rich Salz
 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 Architect
DataPower Technology   http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Session Fixation Vulnerability in Web Based Apps

2003-06-15 Thread Ng Pheng Siong
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 cookies. 

Dynamic programming environments like Lisp, Smalltalk and Python allow
the application programmer to replace parts of a framework with other code
easily.

Lisp does it better than Python. Dunno about Java, PHP, whatnot.

Build your applications with a superior programming system.


-- 
Ng Pheng Siong [EMAIL PROTECTED] 


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Session Fixation Vulnerability in Web Based Apps

2003-06-15 Thread Adam Back
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 browser into adopting someone else's SSL session.

I wouldn't know one way or the other if these higher level frameworks
fall victim to the session adoption problem as I haven't used them;
but it seems plausible that there might exist some that do.  If this
were the case it would be quite bad as there would presumably be many
users of them who had relied on the security of the high-level
framework.  But I would be suprised if most or many of them did for
similar reasons to the reason people are expressing doubt that many
hand coded login pages would be affected: it seems like generally a
mistake natural login and session managing web programming idioms
would not lend themselves to.

Adam

On Sun, Jun 15, 2003 at 05:52:17PM -0400, Rich Salz wrote:
  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?

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Session Fixation Vulnerability in Web Based Apps

2003-06-14 Thread Ben Laurie
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 
 stockbroker, or your domain registrar, someone else can share 
 your login.
 
 It is a security design error in the development environments 
 for active server pages (all of them) .  Every such development 
 environment will have to be changed, and every login script 
 written for existing environments needs to have some kind of 
 workaround cobbled into it.
 
 The ideal solution is to change the development environment so 
 that your session identifier is linked to the shared symmetric 
 key used in any https conversation during that session, which 
 requires tight coupling of https and development environments 
 for active server pages.
 
 In the long term, https must be amended to have a concept of 
 login and session, and make that sessionID available to the 
 server side coding environments. 

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.

I suggest you read and think more carefully.

I will agree that an incautious implementor could get bitten by these
attacks, though.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/

There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Session Fixation Vulnerability in Web Based Apps

2003-06-14 Thread James A. Donald
--
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 the development environments that I am familiar with, the
code environment assumes one is using a session cookie.  If you
are using a session cookie automatically generated by the
environment for state management, if you are using the state
management supplied by the development environment, this flaw
will bite you.

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.

How did you do your state management, and why did you do it the
way that you did?

For the environments that I am familiar with, if one did a
server side coding for a login in the way the environment was
designed to be used, that login code would be flawed.

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. 

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 kTr+tGmv2Tc7wtpF2vCQqPhk5dxOUN1yhHOu2VtM
 4uKcnZA607mHi4kFhb+yzpP4NHwUS/DukGoP89sdV


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Session Fixation Vulnerability in Web Based Apps

2003-06-14 Thread James A. Donald
--
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+pr3YYQdkG
 ocf99Mr7YN0oLlYWkZsE57yUHWMocE0Z+gK2yQOU
 4RiX1d4bEHzLkunxq2FfwXmWFdySguhagGnZR4U7X


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Session Fixation Vulnerability in Web Based Apps

2003-06-13 Thread tom st denis

--- 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 understanding.

https uses a secure private link to create a private http session.  It
has NOTHING todo with authentication nor identity.

For example, when you first login to say yahoo [for email] you're on
https.  Even before yahoo knows who you are.  Think of a verbal
handshake in the get smart cone of silence..

The fact that people randomly give away *their* secrets doesn't mean
the system is flawed.  It means the people are ignorant.

Tom

__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Session Fixation Vulnerability in Web Based Apps

2003-06-12 Thread Steve Schear
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]