hi Will,
On Mon, Sep 17, 2012 at 7:45 PM, Will Fitch willfi...@php.net wrote:
While I've spent the better part of a week trying to determine the best
solution, I want to run this by Ilia, Wez and/or Edin for input. Anyone
else on the list is also encouraged to provide feedback as well.
hi,
On Mon, Sep 17, 2012 at 7:54 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
Something like the attached patch could work, but that means we would
have to update all the config.m4s :]
As far as I remember, the enable/disable option default behavior is
what is used in the --help. So
Hi all,
I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
The RFC is a proposal to implement a standardised means of escaping
data which is being output into XML/HTML.
Cross-Site Scripting remains one of the most common vulnerabilities in
web applications and there is a
Hi Paddy,
Couldn't this just be a new option for the filter_var() function?
$clean = filter_var($_POST['someVar'], XSS_CLEAN);
- Paul.
On Tue, Sep 18, 2012 at 12:30 PM, Pádraic Brady padraic.br...@gmail.com wrote:
Hi all,
I've written an RFC for PHP over at:
On Tue, Sep 18, 2012 at 12:32 PM, Paul Dragoonis dragoo...@gmail.com wrote:
Hi Paddy,
Couldn't this just be a new option for the filter_var() function?
$clean = filter_var($_POST['someVar'], XSS_CLEAN);
I see from your RFC that you have a bunch of functions, I believe all
these could be
Paul
On Tue, Sep 18, 2012 at 7:32 AM, Paul Dragoonis dragoo...@gmail.com wrote:
Hi Paddy,
Couldn't this just be a new option for the filter_var() function?
$clean = filter_var($_POST['someVar'], XSS_CLEAN);
- Paul.
Not without losing significant semantic meaning. There's a huge
Yep, I see where my suggestion for filter_var() isn't relevant.
I use symfony2's ecaper in the PPI\Templating\ component, and really like it.
Zend2's also seems pretty good.
It'd be nice to have this available as a ./ext/spl/ class or an
independent extension (really needed for 1 class?).
On Tue, 18 Sep 2012, Pádraic Brady wrote:
I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
The RFC is a proposal to implement a standardised means of escaping
data which is being output into XML/HTML.
Cross-Site Scripting remains one of the most common
On Mon, 17 Sep 2012, Hannes Magnusson wrote:
On Mon, Sep 17, 2012 at 9:59 AM, jpauli jpa...@php.net wrote:
I'm confused.. --enable-all is already supported, just like --disable-all ?
-Hannes
AFAIR no :) We have a --disable-all , but no --enable-all.
I'm +1 to add such an option
Hey,
I'm going to make this brief, because I suspect a lot of people are going
to jump at the opportunity to cry bloody murder when I suggest this.
I wonder if it would make sense to have a way to globally hook into
__construct() - sort of like how you can hook into the autoloaders with
Hi Derick,
This is already available over composer. The RFC contains links to the
two frameworks which have implemented Escapers in line with the RFC.
The point of the RFC is to ensure a consistent API for escaping is
available to all PHP programmers without resorting to userland
solutions.
Hi Paul,
The thing is that filter_var() is strongly associated with input
sanitisation whereas Escaper addresses the other end of output. Also,
escaping is inextricably linked to character encoding - we can't run
into situations where the functions are specific to something like
UTF-8 when the
On Tue, 2012-09-18 at 08:19 -0400, Rasmus Schultz wrote:
Hey,
I'm going to make this brief, because I suspect a lot of people are going
to jump at the opportunity to cry bloody murder when I suggest this.
I wonder if it would make sense to have a way to globally hook into
__construct() -
On Tue, Sep 18, 2012 at 6:07 AM, Johannes Schlüter
johan...@schlueters.dewrote:
On Tue, 2012-09-18 at 08:19 -0400, Rasmus Schultz wrote:
Hey,
I'm going to make this brief, because I suspect a lot of people are going
to jump at the opportunity to cry bloody murder when I suggest this.
On Tue, Sep 18, 2012 at 3:18 PM, Kris Craig kris.cr...@gmail.com wrote:
On Tue, Sep 18, 2012 at 6:07 AM, Johannes Schlüter
johan...@schlueters.dewrote:
On Tue, 2012-09-18 at 08:19 -0400, Rasmus Schultz wrote:
Hey,
I'm going to make this brief, because I suspect a lot of people are
Hello Rasmus!
~~~
RS Hey,
RS I wonder if it would make sense to have a way to globally hook into
RS __construct() - sort of like how you can hook into the autoloaders with
RS spl_autoload_register() ...
RS This could be useful for things like dependency
Sounds to me like aspect-oriented programming, applied to object construction.
Take a look at: https://github.com/AOP-PHP/AOP
2012/9/18 Rasmus Schultz ras...@mindplay.dk:
Hey,
I'm going to make this brief, because I suspect a lot of people are going
to jump at the opportunity to cry bloody
On Tue, Sep 18, 2012 at 5:14 PM, Amaury Bouchard ama...@amaury.net wrote:
Sounds to me like aspect-oriented programming, applied to object construction.
Take a look at: https://github.com/AOP-PHP/AOP
+1, this is the same case as AOP, but for constructor.
Thus AOP may fit the need.
Julien.P
--
On Sep 18, 2012, at 5:00 AM, Paul Dragoonis dragoo...@gmail.com wrote:
Yep, I see where my suggestion for filter_var() isn't relevant.
I use symfony2's ecaper in the PPI\Templating\ component, and really like it.
Zend2's also seems pretty good.
It'd be nice to have this available as a
On Tue, Sep 18, 2012 at 2:27 PM, Pádraic Brady padraic.br...@gmail.com wrote:
Hi Derick,
This is already available over composer. The RFC contains links to the
two frameworks which have implemented Escapers in line with the RFC.
The point of the RFC is to ensure a consistent API for escaping
Also as there is also htmlspecialchars() which most people use for escaping
this seems like a better, more centralized functionality and better
nomenclature for escaping on output in general with options for various types
(and should just be utf-8 by default :))
--
PHP Internals - PHP Runtime
On 09/18/2012 12:39 PM, Michael Shadle wrote:
Also as there is also htmlspecialchars() which most people use for escaping
this seems like a better, more centralized functionality and better
nomenclature for escaping on output in general with options for various types
(and should just be
Hi!
I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
The RFC is a proposal to implement a standardised means of escaping
data which is being output into XML/HTML.
We already have filter extension. Is it really necessary to invent yet
another way of filtering data?
Also,
Stas,
On Tue, Sep 18, 2012 at 12:51 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
The RFC is a proposal to implement a standardised means of escaping
data which is being output into XML/HTML.
We already have
Hi!
The point of the RFC is to ensure a consistent API for escaping is
available to all PHP programmers without resorting to userland
I do not see why without resorting to userland is a worthy goal in
every case. It's like saying I want to code in Python without ever
using import or I want to
Hi!
Filtering is very different from escaping. They each handle similar but
unique problems:
It is a purely artificial distinction. Filtering is taking one set of
data and returning other set of data, it can be applied on input,
output, or anywhere you want to. Just because we used filtering
On 18/09/12 18:00, Stas Malyshev wrote:
Hi!
Filtering is very different from escaping. They each handle similar but
unique problems:
It is a purely artificial distinction. Filtering is taking one set of
data and returning other set of data, it can be applied on input,
output, or anywhere you
Hi!
No it's not. A filter removes, but escaping lets the original content
pass through unchanged, with the necessary in-band signalling to make
sure that its content is not treated as in-band signalling.
Again, you are confusing particular implementation of a particular
filter with the idea
This is one of the main use cases of AOP. Demonstrated by this script:
?php
class Bar {}
class Foo {
public function __construct(Bar $b) {
echo 'instance of ' . get_class($b);
}
}
function doDi($joinpoint) {
// do smart stuff, then call:
On 18/09/12 18:09, Stas Malyshev wrote:
Hi!
No it's not. A filter removes, but escaping lets the original content
pass through unchanged, with the necessary in-band signalling to make
sure that its content is not treated as in-band signalling.
Again, you are confusing particular
Stas,
On Tue, Sep 18, 2012 at 1:09 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
No it's not. A filter removes, but escaping lets the original content
pass through unchanged, with the necessary in-band signalling to make
sure that its content is not treated as in-band signalling.
On 18/09/12 18:14, Anthony Ferrara wrote:
Stas,
On Tue, Sep 18, 2012 at 1:09 PM, Stas Malyshev smalys...@sugarcrm.com
mailto:smalys...@sugarcrm.com wrote:
Hi!
No it's not. A filter removes, but escaping lets the original
content
pass through unchanged, with the necessary
On 9/18/12 7:30 AM, Pádraic Brady wrote:
That's all. The RFC should be self-explanatory and feel free to pepper
...
https://wiki.php.net/rfc/escaper
I like where this is going and agree that PHP officially embracing an API would be helpful
even for users stuck on old PHP versions.
First
Hi Julien,
I think you're mixing these up. The RFC addresses escaping or encoding
of data on output to HTML/XML (e.g. PHP templates or Twig). It doesn't
act as an input filter to catch attempted XSS/SQLi where fuzzing can
disguise the attempt and wheedle its way past countless regular
expressions
On 18/09/12 18:19, Steve Clay wrote:
First issue: I've not studied the referenced PHP implementations, but
in cases where multiple contexts seem to apply it's not clear from the
RFC which function(s) should be used, and if multiple, how their calls
would be composed. Examples:
HTML style
Hi Michael,
See the link near the bottom of the RFC - even htmlspecialchars() has
unusual behaviour that's potentially insecure. I have no objections to
there being functions, of course, and the RFC makes that clear.
However, many programmers like me are obsessed are objects so having
an SPL
Julien,
Implementing this to Core may be very nice, but as well very hard to do.
String escaping is a pain to implement in C. One would tell : once
it's done, it's OK, but unfortunately, that's not the case, as XSS
rules evolve throught time as the attacks evolve.
See the escape modules web
On Tue, Sep 18, 2012 at 2:15 PM, Derick Rethans der...@php.net wrote:
Can you please explain to me how it is not working?
~/Sources/php/php-5.3 (PHP-5.3) $ ./configure --enable-all
configure: error: Cannot find enchant
And no, ext/enchant is not enabled by default.
The Windows buildsystem
Hi Stas,
This is not an input filter and PHP already suffers the same
outrageous disadvantages by offering htmlspecialchars(),
rawurlencode(), etc. The rules for escaping are well established and
DO NOT change overnight. Those for Javascript and CSS are in their
respective standards. Those for
hi Pádraic!
On Tue, Sep 18, 2012 at 1:30 PM, Pádraic Brady padraic.br...@gmail.com wrote:
Hi all,
I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
The RFC is a proposal to implement a standardised means of escaping
data which is being output into XML/HTML.
Cross-Site
Hi!
No, he's not. Filtering and escaping are two very significant concepts
in security. Just because PHP implemented some escaping concepts into
the filter function does not mean that the concerns are co-related.
Again, you are taking very narrow definition of filterting, which is not
Hi Stas,
On Tue, Sep 18, 2012 at 5:56 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
The point of the RFC is to ensure a consistent API for escaping is
available to all PHP programmers without resorting to userland
I do not see why without resorting to userland is a worthy goal in
Hello everyone,
Paddy is correct here. The purpose of this API is output ENCODING which is a
very good thing. This discussion provides a very good case for a point I
made via Twitter this morning: In this RFC, all uses of the term escape
should be replaced by the term encode.
This is not solely
On 18/09/12 18:55, Stas Malyshev wrote:
Again, you are taking very narrow definition of filterting, which is not
justified by anything but your very narrow use case, and try to present
it as if this is the only meaning filtering has (despite numerous
examples of using of filters in more generic
El 18/09/12 13:30, Pádraic Brady escribió:
Hi all,
I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
The RFC is a proposal to implement a standardised means of escaping
data which is being output into XML/HTML.
Cross-Site Scripting remains one of the most common
Bryan et al,
On Tue, Sep 18, 2012 at 1:58 PM, Bryan C. Geraghty br...@ravensight.orgwrote:
Hello everyone,
Paddy is correct here. The purpose of this API is output ENCODING which is
a
very good thing. This discussion provides a very good case for a point I
made via Twitter this morning: In
On 9/18/12 1:55 PM, Stas Malyshev wrote:
Again, nowhere it is said that you can not apply different filters to
different data or different context. Again, you narrow down definition
of filtering, to which I see no purpose unless you seek to arrive at
pre-determined conclusion that we need to
Hi!
Programmers haven't figured out how to use the 1-2 covering functions
that already exist and you expect them to do it in userland code?
I expect them to use libraries. I don't think anything that is written
in PHP means it's wrong and has to be rewritten in C.
Maybe we should ditch
Hi Steve,
I can add some examples but it's not clear cut all the time. For
example, contexts can nest three levels deep in some cases even ;).
HTML inside Javascript inside HTML. Then there's the boogie man of
other forms of DOM-based XSS...
So the nesting is quite simple to compose but the
Hi!
Filter has already gone down this road--I doubt the value added by having a
second, much
more verbose way to call htmlspecialchars()--but I don't see why we must
continue down
that path.
So, you don't think there should be second, more verbose way to call
htmlspecialchars - that's
Andrew Faulds wrote:
No, he's not. Filtering and escaping are two very significant concepts in
security. Just because PHP implemented some escaping concepts into the filter
function does not mean that the concerns are co-related.
Ah, again you see, I'm confusing things :) In the security
On 09/18/2012 02:21 PM, Stas Malyshev wrote:
Hi!
Filter has already gone down this road--I doubt the value added by having a
second, much
more verbose way to call htmlspecialchars()--but I don't see why we must
continue down
that path.
So, you don't think there should be second,
Stas,
On Tue, Sep 18, 2012 at 2:21 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Filter has already gone down this road--I doubt the value added by
having a second, much
more verbose way to call htmlspecialchars()--but I don't see why we must
continue down
that path.
So, you
Stas,
Encoding or Escaping is universally used in association with output in
the standard security language. I really don't see anything to debate
here. I take your point that the escaper could be implemented as a
series of filters. I think that would be the wrong move because nobody
will
Leigh wrote:
so perhaps we need to use a different word, for
the process, but the same 'process' applies to all of these 'conversions'.
An input data format is converted to an output data format?
How about an encoder, or an escaper.
Actually - just coder
It's encoding, recoding or decoding
Antony,
I'll concede that the term escaping is improperly used in many places;
even in the OWASP documentation.
But I'll point out that the CWE document is identifying a distinction in the
two terms by saying, This overlapping usage extends to the Web, such as
the escape JavaScript
On Tue, Sep 18, 2012 at 7:19 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Programmers haven't figured out how to use the 1-2 covering functions
that already exist and you expect them to do it in userland code?
I expect them to use libraries. I don't think anything that is written
in
Hi Ángel,
The methods all refer to literal strings, values or digits. We can't
reasonably escape data while allowing valid markup for the current
context since that's a contradiction by its very nature. If you needed
to let user values drive CSS names, Javascript functions or variable
naming, or
Bryan,
On Tue, Sep 18, 2012 at 2:52 PM, Bryan C. Geraghty br...@ravensight.orgwrote:
Antony,
** **
I’ll concede that the term “escaping” is improperly used in many places;
even in the OWASP documentation.
** **
But I’ll point out that the CWE document is identifying a
Anthony Ferrara wrote:
Personally, I'd rather have a dedicated API. It's the only way that
semantic meaning of the API will be preserved.
In this case, I would start it as a PECL extension implementing the ESAPI
library. Get the API right, and prove it works, then pull it into core.
Sounds
Lester,
Basically if you are STORING XSS intrusions then you have badly designed
code as there is no reason that it would be stored. If you want to
'display' suspect code, then it is 'escaped' before it is stored so
preventing a potential problem if another viewer accesses the raw data!
I
Hi Rasmus,
On Tue, Sep 18, 2012 at 7:34 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
If we want to add more filters for more specific purposes, I am not
completely against it, although the more specific they get the more
churn there will be. We are not going to be able to kick out weekly
*Basically if you are STORING XSS intrusions then you have badly designed
code as there is no reason that it would be stored. If you want to
'display' suspect code, then it is 'escaped' before it is stored so
preventing a potential problem if another viewer accesses the raw data!*
While that is
On 09/18/2012 03:28 PM, Pádraic Brady wrote:
Hi Rasmus,
On Tue, Sep 18, 2012 at 7:34 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
If we want to add more filters for more specific purposes, I am not
completely against it, although the more specific they get the more
churn there will be. We
Bear in mind the RFC, in userland (and likely any PECL ext) implements
the ESAPI rules. They've been hacked on a lot over the years which is
why I made sure they were followed exactly. It's very unlikely that a
browser bug could scupper these unless they allowed in more unencoded
characters to be
On 09/18/2012 03:46 PM, Pádraic Brady wrote:
Bear in mind the RFC, in userland (and likely any PECL ext) implements
the ESAPI rules. They've been hacked on a lot over the years which is
why I made sure they were followed exactly. It's very unlikely that a
browser bug could scupper these unless
On 18/09/12 20:50, Rasmus Lerdorf wrote:
On 09/18/2012 03:46 PM, Pádraic Brady wrote:
Bear in mind the RFC, in userland (and likely any PECL ext) implements
the ESAPI rules. They've been hacked on a lot over the years which is
why I made sure they were followed exactly. It's very unlikely that
On Tue, Sep 18, 2012 at 8:50 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 09/18/2012 03:46 PM, Pádraic Brady wrote:
Bear in mind the RFC, in userland (and likely any PECL ext) implements
the ESAPI rules. They've been hacked on a lot over the years which is
why I made sure they were followed
On 18/09/12 21:11, Paul Dragoonis wrote:
The existing implementations at symfony\zend are working pretty well.
They're using string manipulation and regex functions.
If we port it to C, can't we still use the exact same functions that
the PHP_FUNCTION() macros are calling to pretty much clone
On 18/09/12 21:06, Pádraic Brady wrote:
Hi Ángel,
The methods all refer to literal strings, values or digits. We can't
reasonably escape data while allowing valid markup for the current
context since that's a contradiction by its very nature. If you needed
to let user values drive CSS names,
On Tue, Sep 18, 2012 at 8:59 AM, Pierre Joye pierre@gmail.com wrote:
hi,
On Mon, Sep 17, 2012 at 7:54 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
Something like the attached patch could work, but that means we would
have to update all the config.m4s :]
As far as I remember,
@All,
I'd like to provide a real use case since i feel people have went off
on a tangent of their own. i.e: a list of blog posts.
?php foreach($posts as $post): ?
pa href=/blog/view/?=$post-getID();?
title=?=$escaper-escapeHtmlAttr($post-getTitle());?
Anthony Ferrara wrote:
Lester,
Basically if you are STORING XSS intrusions then you have badly designed
code as there is no reason that it would be stored. If you want to 'display'
suspect code, then it is 'escaped' before it is stored so preventing a
potential problem if
On Tue, Sep 18, 2012 at 7:30 AM, Pádraic Brady padraic.br...@gmail.com wrote:
Hi all,
I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
The RFC is a proposal to implement a standardised means of escaping
data which is being output into XML/HTML.
Good point - I agree. Thanks for taking the time to think about this!
On Tue, Sep 18, 2012 at 12:22 PM, jpauli jpa...@php.net wrote:
On Tue, Sep 18, 2012 at 5:14 PM, Amaury Bouchard ama...@amaury.net
wrote:
Sounds to me like aspect-oriented programming, applied to object
construction.
On Fri, Sep 14, 2012 at 10:36 AM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
I was asked in a private email that it is true or not that *anybody* can
create an RFC.
As this isn't the first time to see that question I think that we could
document that a little bit clearly.
Here is how I
On Tue, Sep 18, 2012 at 8:14 AM, Amaury Bouchard ama...@amaury.net wrote:
Sounds to me like aspect-oriented programming, applied to object
construction.
Take a look at: https://github.com/AOP-PHP/AOP
Yeah I wasn't aware of this, either, but I can think of several scenarios
in which it'd be
Hello,
https://wiki.php.net/rfc/alternative_callback_syntax is a proposal for a simple
alternative syntax for creating function callbacks.
The basics: Given a function/method call, replace the argument list with ::function. PHP
would evaluate this as a callback for the function/method, fully
78 matches
Mail list logo
