Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63105
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <011901cd95ce$bfea0900$3fbe1b00$@org>
References: <CALwr1Gn4OmHP=Qa7NKzpbkq+w8FEjUMZ3v678bbZVOGM23G35g@mail.gmail.com>
	<alpine.DEB.2.02.1209180809010.28929@whisky.home.derickrethans.nl>
	<CALwr1GnjwyE=yipK6UNkOm9m31LDDbpbcdgmr_nf0cUo+zOedw@mail.gmail.com>
	<CALwr1G=DOKmjudFFEAFY+6hmUh3q+qNe1ntWY1FLXP5GChLZdA@mail.gmail.com>
	<CAMUwpuSfd1U6aA_7o6d2jGm-i0PsLAf1MqKF8zvtcfzGFMGEXQ@mail.gmail.com>
	<CALwr1GkLMrenFjv49kE1a-i4vN3sVr2Rr1wRUgBWGg3=V34How@mail.gmail.com>
	<011201cd95c7$33d43c30$9b7cb490$@org>
	<CAAyV7nEqVq9QUeamrBr0VskscyMdfm8AzRSUPbTE8TV0b_rzYw@mail.gmail.com>
	<011901cd95ce$bfea0900$3fbe1b00$@org>
Date: Tue, 18 Sep 2012 15:12:21 -0400
Message-ID: <CAAyV7nHWyeUbxTJGgFW8scsO3jqF_seFf7yD8enWQ2_c0RY5yA@mail.gmail.com>
To: "Bryan C. Geraghty" <bryan@ravensight.org>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=e89a8f2346877028ab04c9feabf7
Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class
From: ircmaxell@gmail.com (Anthony Ferrara)

--e89a8f2346877028ab04c9feabf7
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Bryan,

On Tue, Sep 18, 2012 at 2:52 PM, Bryan C. Geraghty <bryan@ravensight.org>wr=
ote:

> Antony,****
>
> ** **
>
> I=92ll concede that the term =93escaping=94 is improperly used in many pl=
aces;
> even in the OWASP documentation.****
>
> ** **
>
> But I=92ll point out that the CWE document is identifying a distinction i=
n
> the two terms by saying,  =93This overlapping usage extends to the Web,
> such as the "escape" JavaScript function whose purpose is stated to be
> encoding=94.
>

There is a distinction between them. But in this case it's not particularly
relevant (as both work quite fine). I'll elaborate further in a second.


> But when you say, =93With the end result being the exact same...=94, I do=
n=92t
> think you=92ve thought it through. I=92ve read some of your stuff and I=
=92m
> pretty confident that you understand the benefits of white-listing over
> black-listing. For the uninitiated, yes, a black-list can be configured t=
o
> produce the same results at a given point-in-time, but the fundamental
> approach is different.  A white-list operates on an explicit specificatio=
n
> and lets nothing else through. A black-list assumes that the input data i=
s
> mostly correct and it filters out the bad. To add to that, how do you
> convert from ISO-8859-1 to UTF-8 with a black-list or by escaping?
>

You hit the nail on the head here. You cannot black-list convert ISO-8859-1
to UTF-8. However, when we talk about escaping, we're talking about a
context where the encoding is already correct, we're just preventing
special characters from imparting special meaning. In that case, escaping
is the correct way of handling it.

But if you wanted to output arbitrary input into a UTF-8 document, you
would also need to ensure that it's encoded properly into UTF-8. So I can
see your distinction applying to that case. But from a different angle.

Escaping preserves the security context. Encoding preserves the semantic
context. You could escape away all invalid UTF-8 bytes, but you'd loose the
meaning of the original character set. So semantically, encoding is
necessary. But from a security perspective, the encoding doesn't really
matter much. What matters is the security context (not injecting harmful
code, etc).

Now, both can be handled by the same routine. But that's not necessary to
preserve the security aspect. And that's why I objected to using the term
"encoding" here. If we want to go that route, that's fine. But you don't
need to encode for security. Escaping will handle that (possibly at the
expense of invalid semantic meaning).


> Your reference to mysql_real_escape_string is exactly the point I=92m try=
ing
> to make. The use of that function is =93discouraged=94 because it DID esc=
ape;
> it looked for specific bad characters. It was fundamentally flawed. And
> that is the functionality PHP developers, as you just demonstrated, will
> refer to. The current recommendation is to use a library that properly
> encodes the entire data stream.
>

How is mres fundamentally flawed? And how is it discouraged? It's actually
listed as a valid defense by OWASP:
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defens=
e_Option_3:_Escaping_All_User_Supplied_Input

The only 2 ways of securely getting data to MySQL is either by escaping, or
binding as a parameter on a prepared statement. Neither of which encodes a
data stream (the PS uses a binary format that puts the data in plain binary
form, as is, with a header to identify length).

Black listing works fine for a specified format (like XML, like HTML, like
SQL, like JavaScript). Where you get in trouble with black lists is when
your data format isn't specified (hence edge-cases aren't well known) or
when you're not serializing to a format (generic input black lists). But
for escaping output, black lists are a very well known, well understood,
and easily implemented approach.


> I=92ll also agree that consistency with the industry is not as important
> because there seem to be plenty of misuses. However, I do think that we
> should use terminology that sets the functionality apart. So, given the
> operating mode difference and the precedent set by mysql_escape_string,
> mysql_real_escape_string, etc., I think =93encode=94 is the way to go.
>

I think it strongly depends upon the exact behavior of the library. If we
do wind up doing transcoding as well as escaping, then that may be valid.
If we don't, then it wouldn't.

But I think we can both agree on the need...

Anthony

--e89a8f2346877028ab04c9feabf7--