Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Hi Pierre, I also noticed your tweet ;). > Given the current discussions about the APIs (see my other reply too) > and its usage, and that this proposal is non invasive/self contained > in an extension, I would strongly suggest to already go with it in > PECL, do releases (stay alpha until you ha

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

hi Pádraic, Given the current discussions about the APIs (see my other reply too) and its usage, and that this proposal is non invasive/self contained in an extension, I would strongly suggest to already go with it in PECL, do releases (stay alpha until you have a very good feeling about the API s

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Hi Michael, > After looking over the RFC finally, would it be that crazy to consider > this an extension of the standard string functions? > > str_escape($string, $encoding, $flags) or probably better > str_escape($string, $flags, $encoding) - since encoding could be > defaulted to UTF-8, but flag

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Hi al >> In any case, I’m not here to carry on an endless flame war. I just want to >> make sure that we’re doing what’s necessary to mitigate the number one >> vulnerability in web applications. >> > > I don't think this discussion is a flame war. I think it's a very good and > constructive point

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Bryan, “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, > es

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Wed, Sep 19, 2012 at 9:25 PM, David Muir wrote: > On 20/09/12 07:48, Michael Shadle wrote: >> >> On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady >> wrote: >>> >>> Hi Michael, >>> >>> See the link near the bottom of the RFC - even htmlspecialchars() has >>> unusual behaviour that's potentially

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On 20/09/12 07:48, Michael Shadle wrote: On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady wrote: 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

RE: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

. I just want to make sure that we're doing what's necessary to mitigate the number one vulnerability in web applications. Thanks, Bryan From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Tuesday, September 18, 2012 2:12 PM To: Bryan C. Geraghty Cc: internals@lists.php.net Su

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Wed, Sep 19, 2012 at 10:48 PM, Michael Shadle wrote: > On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady > wrote: >> 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 f

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady wrote: > 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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On 19/09/12 18:48, Pádraic Brady wrote: I think we're running into being overly prescriptive. Escaping can never, by definition, apply to anything that isn't a value string or integer, i.e. anything that is capable of altering the meaning of the HTML/Javascript or CSS into which its inserted. Th

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Sep 19, 2012, at 10:22 AM, Andrew Faulds wrote: > Again, "all the OOP code is a waste of time" doesn't really add anything to > this discussion. Arguing against this being OOP, which I think is useful and > requires, at most, one extra line ($x = new Escaper), is silly. Arguing semantics ov

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Hi Andrew, On Wed, Sep 19, 2012 at 4:39 PM, Andrew Faulds wrote: >> Than I suggest including "For" in all of them. escapeForHtml, >> escapeForUrl, etc. That should clear it up somewhat that we're not >> targeting whole blocks of HTML/JS/CSS. > > That still isn't clear enough, I think. escapeHTMLA

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On 19/09/12 18:19, Michael Shadle wrote: Because a simple str_replace one line will become 6-10 lines of OO code very easily? Does it? Let's use an example from Python, which actually has strin methods. And then stop this argument that isn't related to the topic. PHP: str_replace('yak',

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Wed, Sep 19, 2012 at 10:11 AM, Andrew Faulds wrote: > Please explain in detail how object-oriented code obfuscates, complicates, > murders baby kittens, etc. Because a simple str_replace one line will become 6-10 lines of OO code very easily? Maybe you write "amazing" OO code, but the stuff

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On 19/09/12 17:57, Michael Shadle wrote: If you want to play with OO all day, then use Java. PHP was built on procedural, and now all you OO fanboys are going nuts with it. :) On a short-lived web request I see no reason to complicate and obfuscate the code with OO. Please explain in detail how o

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Wed, Sep 19, 2012 at 9:21 AM, Michael Stowe wrote: > Andrew, I'm the biggest advocate of OOP out there, but the purpose of this > is to provide a nice convenient layer for all developers to use to properly > escape code and increase security within their applications. As such, we > need to ca

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Wed, Sep 19, 2012 at 9:16 AM, Lars Strojny wrote: > There seems to be a need for a procedural API. As their is one, let’s do it > similar to how MySQLi etc. does it and use a context resource: > > $ctx = escape_context_create('UTF-8'); > $str = escape_html_attr($ctx, $str); why bother with t

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On 19/09/12 17:21, Michael Stowe wrote: /"Oh goodness no, let's please only do OOP with the language features. Creating ridiculous "procedural" OOP abstractions helps absolutely nobody"/ Andrew, I'm the biggest advocate of OOP out there, but the purpose of this is to provide a nice convenient

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

*"Oh goodness no, let's please only do OOP with the language features. Creating ridiculous "procedural" OOP abstractions helps absolutely nobody"* Andrew, I'm the biggest advocate of OOP out there, but the purpose of this is to provide a nice convenient layer for all developers to use to properly

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On 19/09/12 17:16, Lars Strojny wrote: Hi, There seems to be a need for a procedural API. As their is one, let’s do it similar to how MySQLi etc. does it and use a context resource: $ctx = escape_context_create('UTF-8'); $str = escape_html_attr($ctx, $str); And so on. cu, Lars Oh goodness no

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Hi, Am 19.09.2012 um 18:11 schrieb Michael Stowe : > Personally, I would like to see it operate similar to MySQLi, where you > have the convenience of OOP, but can still call a function directly in a > procedural manner. There seems to be a need for a procedural API. As their is one, let’s do it

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On 19/09/12 16:36, Pádraic Brady wrote: Hi Steve, Who's he? :) Everybody knows Steve! :P I know at least 10! The ESAPI API uses encodeForHTML, encodeForCss, etc. We can name these in a few different styles which would all be semantically correct but my own sentiment is often to keep the namin

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

>> Hi Steve, > > Who's he? :) Everybody knows Steve! :P I know at least 10! >> The ESAPI API uses encodeForHTML, encodeForCss, etc. We can name these >> in a few different styles which would all be semantically correct but >> my own sentiment is often to keep the naming simple. > > The naming is

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On 19/09/12 15:07, Pádraic Brady wrote: Hi Steve, Who's he? :) The ESAPI API uses encodeForHTML, encodeForCss, etc. We can name these in a few different styles which would all be semantically correct but my own sentiment is often to keep the naming simple. The naming is unclear just now though

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Hi Steve, Missed this one in the rush of emails... > I echo this. I think some clearer names might help, I think something like > these: > > escapeHTMLAttribute for attributes, escapeHTMLText for text inside > tags, escapeXMLAttribute and escapeXMLContent, escapeJSStringLiteral, > escapeCSSIdent

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Tue, Sep 18, 2012 at 7:30 AM, Pádraic Brady 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. > > https://wiki.php.net/rfc/escaper Some Qu

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 another

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

@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. escapeHtml($post->getTitle());?> Please see the different needs for escaping generalised html output, and the same but within an attribute. This is an importa

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 n

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 it.

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Tue, Sep 18, 2012 at 8:50 PM, 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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 a

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 unl

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 t

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On 09/18/2012 03:28 PM, Pádraic Brady wrote: > Hi Rasmus, > > On Tue, Sep 18, 2012 at 7:34 PM, Rasmus Lerdorf 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 goi

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

*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 t

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Hi Rasmus, On Tue, Sep 18, 2012 at 7:34 PM, Rasmus Lerdorf 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 > releases to address

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 the

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Bryan, On Tue, Sep 18, 2012 at 2:52 PM, Bryan C. Geraghty wrote: > 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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 H

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Tue, Sep 18, 2012 at 7:19 PM, Stas Malyshev 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 PHP means it's

RE: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

cape_string, etc., I think "encode" is the way to go. Thanks, Bryan From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Tuesday, September 18, 2012 1:09 PM To: Bryan C. Geraghty Cc: internals@lists.php.net Subject: Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 .

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 actually

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Stas, On Tue, Sep 18, 2012 at 2: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 th

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 b

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 context

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 rules

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 jso

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 dupl

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Bryan et al, On Tue, Sep 18, 2012 at 1:58 PM, Bryan C. Geraghty wrote: > 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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 v

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 s

RE: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

security background to be able to understand these things, we need to be consistent. Bryan -Original Message- From: Pádraic Brady [mailto:padraic.br...@gmail.com] Sent: Tuesday, September 18, 2012 12:29 PM To: jpauli Cc: internals@lists.php.net Subject: Re: [PHP-DEV] RFC: Implementing a

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Hi Stas, On Tue, Sep 18, 2012 at 5:56 PM, Stas Malyshev 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 > every case. It'

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 justi

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

hi Pádraic! On Tue, Sep 18, 2012 at 1:30 PM, Pádraic Brady 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 Scripting remains

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 HTM

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 class

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 at

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 is

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On 18/09/12 18:14, Anthony Ferrara wrote: Stas, On Tue, Sep 18, 2012 at 1:09 PM, 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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Stas, On Tue, Sep 18, 2012 at 1:09 PM, 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 ar

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 implementation

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 id

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 w

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 wa

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Stas, On Tue, Sep 18, 2012 at 12:51 PM, Stas Malyshev wrote: > 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 extensio

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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? Als

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Tue, Sep 18, 2012 at 2:27 PM, Pádraic Brady 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 is > available to

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Sep 18, 2012, at 5:00 AM, Paul Dragoonis 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 ./ext/spl/ class

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 cha

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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. Exist

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping 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 vulnerabil

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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?). Cheers

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

Paul On Tue, Sep 18, 2012 at 7:32 AM, Paul Dragoonis 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 difference between fi

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

On Tue, Sep 18, 2012 at 12:32 PM, Paul Dragoonis 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 options to filter_v

Re: [PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 wrote: > Hi all, > > I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper. > The RFC is a prop

[PHP-DEV] RFC: Implementing a core anti-XSS escaping class

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 conti