NYCPHP Meetup

[Chris Shiflett]

--- Jeff Siegel <jsiegel1 at optonline.net> wrote:
> Unless the LIRR shuts down...I'll be there so we can talk about this.

Unfortunately, things aren't going to work out for me to allow me to
attend tonight. I was hoping to be able to make it, but that's not going
to happen.

I'm sure we'll be in touch via email.

Chris

=====
Chris Shiflett - http://shiflett.org/

PHP Security Handbook
     Coming mid-2004
HTTP Developer's Handbook
     http://httphandbook.org/

>From hans not junk at nyphp.com  Tue Jan 27 15:38:27 2004
Return-Path: <hans not junk at nyphp.com>
Received: from ehost011-1.exch011.intermedia.net (unknown [64.78.21.3])
	by virtu.nyphp.org (Postfix) with ESMTP id 3AD9CA8771
	for <talk at lists.nyphp.org>; Tue, 27 Jan 2004 15:38:27 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [nycphp-talk] sessions and application security
Date: Tue, 27 Jan 2004 12:38:25 -0800
Message-ID: <41EE526EC2D3C74286415780D3BA9F8752B210 at ehost011-1.exch011.intermedia.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [nycphp-talk] sessions and application security
Thread-Index: AcPk9VjLrexWDqFjS8SK2KbL7l7GwQAHmDCQ
From: "Hans Zaunere" <hans not junk at nyphp.com>
To: "NYPHP Talk" <talk at lists.nyphp.org>
X-BeenThere: talk at lists.nyphp.org
X-Mailman-Version: 2.1.2
Precedence: list
Reply-To: NYPHP Talk <talk at lists.nyphp.org>
List-Id: NYPHP Talk  <talk.lists.nyphp.org>
List-Unsubscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=unsubscribe>
List-Archive: <http://lists.nyphp.org/pipermail/talk>
List-Post: <mailto:talk at lists.nyphp.org>
List-Help: <mailto:talk-request at lists.nyphp.org?subject=help>
List-Subscribe: <http://lists.nyphp.org/mailman/listinfo/talk>,
	<mailto:talk-request at lists.nyphp.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jan 2004 20:38:27 -0000


> All,
> I'm back for more information.  I need to port a financial=20
> application. =20
> So it's important to make the session management as strong as=20
> possible.
> One of the guys on the team advocates designing the application so it=20
> doesn't use sessions, basically passing a token in the URL that tells=20
> the server who the person is and where they are in the=20
> application.  I'm leaning toward database session management.
> Who's right?  or are we both right/wrong?

I'm a token passer myself.  Burn an extra few CPU cycles and keep
sensitive information on the endpoints, rather than in transit.

> The application when it's deployed will have two or three web servers=20
> handling the traffic, with a separate Oracle server.  We will have=20
> multiple servers for two reasons, first handling the load,=20
> and second to provide some failover.  So whatever mechanism we
implement=20

Don't forget that if one box goes down, the others get *all* the load...
always balance across more boxes than you need to (there's some fancy
forumla for this, too).

> will need to scale.  We definitely don't want to make it easy for
people to hijack=20
> the session.  And I'd like to make it so it takes Sterling more than
90=20
> seconds to get the keys to the kingdom.  The application will=20
> be running with SSL.
>=20
> I don't have control over the client environment, so I can't=20
> force users to use a particular browser, or browser settings.  Can
detect=20
> what they do have though (obviously).

I think this is really the key.  Backend security considerations can
only be so good - the heart of it lies in the browser.  For anyone who
uses online banking (Citibank for instance) a great deal of their
security is client side.  JavaScript, browser detection, timeouts, etc.

Security really breaks down into two parts: transit and endpoints.  SSL
generally should suffice for transit, and a strong backend architecture
and system admins can handle the server endpoint.  That leaves the
browser, which from what I've seen and heard, is where the real problems
are.

> One thought is to use both a token in the url and database sessions,=20
> where the token in the url is a checksum of the database session, and=20
> possibly vice versa. That way I can check both.  If I have a=20
> checksum in both, then I can compare the checksum.  Hmm.

Good ideas, but even so, if someone can get that key on the browser,
he's in.  Again, it's the browser - but perhaps rotating session keys
can help - which could at least detect if a hijack was *attempted* and
then shutdown the session.

> Thoughts, suggestions, or even better what is the "best" way=20
> to do this?

Don't use a web browser :)

H