NYCPHP Meetup

[Jake McGraw]

On Fri, Apr 25, 2008 at 9:37 AM, Daniel Convissor
<danielc at analysisandsolutions.com> wrote:
> On Fri, Apr 25, 2008 at 09:06:54AM -0400, Jake McGraw wrote:
>  >
>  > Not necessarily true, secure string interpolation is coming soon:
>  >
>  > http://google-caja.googlecode.com/svn/changes/mikesamuel/string-interpolation-29-Jan-2008/trunk/src/js/com/google/caja/interp/index.html
>
>  Yuck.  Such tactics are a cop out for doing the job right in the first
>  place.  It adds significant overhead.  It's just another set of functions
>  ot achieve security, which if not used, will leave people in the same
>  place anyway.  Let alone, that paritcular project is just for JavaScirpt.

Ah, well, I respectfully disagree.

>   Let alone, that paritcular project is just for JavaScirpt.

Though this project is specifically for JavaScript, the fundamentals
can be applied to PHP.

>  Yuck.  Such tactics are a cop out for doing the job right in the first
>  place.

There are simply too many vectors  for attack when developing a PHP
application, start thinking about a typical mash up application, where
you take in user input, store some information on your DB, contact
another web application, maybe run a UNIX command and then deliver the
whole thing. Input from the user, another web application, your own
database and any static files on your server has to be checked for all
of the following injections: SQL, HTML, JS, CSS, XML/JSON (third party
web application), CL. All of these vectors have to be checked for at
different processing times in your application, and each has a
different method for escaping nasty input.

Caja aims to take the guess work out this situation by automatically
detecting what kind (SQL query, CSS definition, etc) of string your
creating and correctly escaping or removing any suspect strings. As
far as "getting the job done right", what if the job changes? What if
a new vector of attack is introduced when some junior developer starts
using data from a third party resource in a way your system doesn't
account for?

> It adds significant overhead.

Well, we won't know that until a version for PHP is published, but, I
found the results the Caja team got for JS to be pretty encouraging.

> It's just another set of functions
>  ot achieve security, which if not used, will leave people in the same
>  place anyway.

The whole point of this endeavor is that we already have too many
security functions to account for, each with an unmaintainable
structure CleanX(StringWithMarkers, ValuesToReplaceMarkers):

CleanQuery(), CleanCommandLine(), CleanHTML(), CleanHTMLAttr(),
CleanJavascript(), CleanCSSDef(), CleanCSSAttr(), etc etc etc

Instead imagine:

Clean(String);

I don't know about you, but I prefer the latter.

- jake

Clean(String)