Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63193
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <505AEB97.8010303@lsces.co.uk>
References: <505AEB97.8010303@lsces.co.uk>
Date: Thu, 20 Sep 2012 12:25:22 +0200
Message-ID: <CAH-PCH6ocZ4vUu3VgLgcQPzp7wBx1LO8vK3TJTQmS9YfD2d-WA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=e89a8ff245c76dde5504ca1f8a86
Subject: Re: [PHP-DEV] Decode, transcode, sanitize, filter, escape
From: tyra3l@gmail.com (Ferenc Kovacs)

--e89a8ff245c76dde5504ca1f8a86
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
>
> My point here is that much of what is being discussed on 'a core anti-XSS
> escaping class' is missing the some of the basic problems and 'filtering'
> is my own take on the correct way of managing this!


and this is where you are wrong.
see
https://www.owasp.org/index.php/Abridged_XSS_Prevention_Cheat_Sheet#A_Posit=
ive_XSS_Prevention_Model
 and
https://www.owasp.org/index.php/Abridged_XSS_Prevention_Cheat_Sheet#Why_Can=
.27t_I_Just_HTML_Entity_Encode_Untrusted_Data.3F



> Many of the recent XSS holes have simply been the likes of the 'highlight=
'
> function is smarty which had no filtering at all ... and just needed
> sanitizing before anything was done with it.


you didn't experienced all of the possible contexts where an XSS
vulnerability can take place. this doesn't mean that those vectors doesn't
exists.


> This 'class' is purely targeting a small area of the problem and
> repackaging functions which still need the user to understand which
> 'filter' to apply to which string?


nope.
this class is targeting to provide the developers with a tool to safely
encode content into each possible context.

If it expected to simply apply a process to the output which will 'protect
> users' then it can never succeed.


escaping the output doesn't mean that you can't also filter the input
(usually they walk hand in hand: "filter in escape out")
you are the only one preaching here that half of that is an ok solution.
if you only filter the input, you cannot use more than one output context
without the risk of compromise, and you also put all your defense in the
belief that you data stored in your relational database (or cache, etc.) is
safely filtered.


> Te users need to understand just where to 'filter' the strings they are
> using and what filters to use.
>

yeah, that's one thing that we can't fix, as for properly encoding the
output you need to know the output context.


>
> Now if what is proposed is a 'class' that will decompose an html page wit=
h
> embeded css and js and magically remove any XSS injection then it might b=
e
> useful, and I think the creator of that would be in line for a Nobel pris=
e?


?
how does it relate to the current discussion


--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--e89a8ff245c76dde5504ca1f8a86--