NYCPHP Meetup

[Adam Maccabee Trachtenberg]

On Tue, 10 Feb 2004, Hans Zaunere wrote:

> Since we're doing PEAR::DB this month, maybe next month is set for
> ADOdb?  Maybe even a face off at the next meeting? :)

Always being someone to volunteer another, David might be a good
referee for that match because he covers both PEAR DB and ADOdb in his
new book.

I'm sure that he'd have already jumped in here, but he's out in
California speaking at the O'Reilly Emerging Technology Conference. :)

-adam

-- 
adam at trachtenberg.com
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!

>From hans not junk at nyphp.com  Tue Feb 10 16:54:48 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 58D86A85F0
	for <talk at lists.nyphp.org>; Tue, 10 Feb 2004 16:54:48 -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] NEW PHundamentals Question
Date: Tue, 10 Feb 2004 13:54:46 -0800
Message-ID: <41EE526EC2D3C74286415780D3BA9F87772717 at ehost011-1.exch011.intermedia.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [nycphp-talk] NEW PHundamentals Question
Thread-Index: AcPvfFC2Ait7wecrSRi/wWYuf9FpCwAnvuMg
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, 10 Feb 2004 21:54:48 -0000


> Almost every website has an HTML form for visitors to complete. But
how=20
> do you know that the person who completed the form did so through your

> website? The question for this month's PHundamentals article is: What=20

You can't.

> method(s) do you use to assure that no one has 'spoofed', i.e.,=20
> 'forged', a form submission?"

There are none.

----
Well ok, maybe that's a bit harsh.

I think it's important to look at this from a strictly protocol
perspective.  If I'm a fast typer, or have written a program to help me,
I can talk to any web server without them having a clue whether I'm a
"real" user or not.  This may seem obvious, but it warrants another
look.

To pick apart the original question:  "how do you know that the person
who completed the form did so through your website?"  Let's even assume
the site uses tokens to identify and track forms.

1) A malicious user browses around (using a regular browser) to the form
he's looking to attack.

2) Upon arrival at the form, the site gladly generates a one time token
and sends it to the browser.

3) Instead of submitting the form, however, the attacker loads up his
own program, which can send custom HTTP requests.  The attacker has his
one time code, yet can inject any data through a form submission... and
the server never knows that the form submission is actually happening
"through the site" - which I read as "through a browser."

So, there's a second part: "What method(s) do you use to assure that no
one has 'spoofed', i.e., 'forged', a form submission?"

Since preventing spoofing and forgery is impossible (even with SSL) it
really becomes a matter of data integrity.  Assuming important and
highly sensitive information (since if it wasn't an important site, why
would you care about form submittals anyway?), these items can help
prevent problems:

-- know what you send out.  Keep track of forms you've put out on the
wire, and develop a policy for accepting form submittals (for instance
time outs, multiple forms per user id, multiple submissions, not
accepting forms you don't expect, etc).  This can be implemented using
tokens.

-- know what you want back.  This is really the crucial part.  Just
because a <select> field contains certain values, don't think you can't
get something *totally* different (and I mean totally, as PHP code, SQL,
binary, etc).
   -- know the fields you need to have back to accept the form as valid
   -- restrict exactly what the values you'd accept as input
   -- and always/always minimize taking data from forms (or any external
source) and using it directly in database queries, or other inner and
intimate parts of your application

Lastly, with talk of forging HTTP requests and so forth, I've found one
defense against this, albeit certainly not 100% - in fact, this is more
in the "stupid tricks department."  They are Javascript and VB Script.
Why?  If anyone has ever "played" around with client-side intensive
pages, it quickly becomes clear that forging and sending requests are
often not good enough.  Since the page is so dynamic, a runtime
environment becomes needed (to parse and execute the JS, for example),
which can then in turn change what the resulting request will be.
Obviously, this can be circumvented, and is not means to protect your
site necessary, but something I've founded interestingly ironic.

H