RE: FN-FORUM: PHP PostData security

date posted 29th May 2007 03:08

Mike A wrote:
> However, passing a
> disconnected client tier to a processing page (business tier) which =20
> ignores all but known, sanitised, postdata variables prevents attack, =

> even for the novice coder who does not know all the different =20
> intricacies of inbound data checking.

Someone else wrote:
>> Bouncing the data through the $_SESSION array does zilch, nothing,=20
>> nada, zip to protect from these.

My take on this is that Mike is advocating an implementation of n-tier
architecture, where the "presentation" tier (responsible for filtering =
input
from the client, as well as generating the HTML output) takes the form =
of a
standalone script, which filters input from the client, then passes it =
to a
second "business logic" script via session variables.

This is a reasonable technique - the business tier script never accesses
client input directly, only filtered input present in session variables.
Although the examples given didn't particular make it clear, the
"presentation tier" page would cleanse data before placing into session
variables - enforcing data types, filtering for dangerous chars =
according to
the intended purpose, etc.

So long as the cleansing page does its job, this delegation of
responsibility reduces code complexity and the web application attack
surface: untrusted inputs are confined to pages in the "presentation" =
tier.=20

There are some downside to this particular "tiers" implementation, =
however.
Chiefly, there is no way to enforce the rule that other tiers do not =
access
data from the client directly. As they are still regular script pages, =
they
can still freely access GET/POST inputs, cookie values and other request
input. It is only "policy" that ensures the business/data tier scripts
access cleansed session data only.

It is also worth bearing in mind that separate scripts is only one of =
many
approaches that provide similar levels of separation between tiers. =
Other
approaches I've seen have included an ASP application where the =
presentation
tier scripts "Server.Execute" separate business logic scripts, which in =
turn
execute data access scripts, and another that passed data between tiers =
as
XML (each tier was effectively a server-side "web service").

The point is that n-tier architecture can be (and generally is) =
implemented
without requiring a location redirect, but this is still a valid =
approach. I
personally wouldn't describe it as a security risk to have data posted =
back
to the same page, however, so long as effective input/output filtering =
is
implemented in some way, preferably via a dedicated presentation/input =
tier.

Cheers, Ben

--
Ben Johnson, Neogic Web Solutions
// design . development . managed hosting

w | http://www.neogic.com
t | +44 (0)1242 808 262
e | [EMAIL REMOVED]