# RFC: Implementing a core anti-XSS escaping class - Thread: https://externals.io/message/63049 - Original archive: https://news-web.php.net/php.internals/63049 - Started by padraic.brady@gmail.com on 2012-09-18T11:30:31+00:00 - Messages: 69 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/63049.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #63049 — padraic.brady@gmail.com — 2012-09-18T11:30:31+00:00 URL: https://externals.io/message/63049#63049 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 continued lack of understanding surrounding how to properly escape data. To try and offset this, I've written articles, attempted to raise awareness and wrote the Zend\Escaper class for Zend Framework. Symfony 2's Twig has since adopted similar measures in line with its own focus on security. That's all. The RFC should be self-explanatory and feel free to pepper me with questions. As the RFC notes, I'm obviously not a C programmer so I'm reliant on finding a volunteer who's willing to take this one under their wing (or into their basement - whichever works). https://wiki.php.net/rfc/escaper Best regards, Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team --- ## #63050 — Paul Dragoonis — 2012-09-18T11:32:35+00:00 URL: https://externals.io/message/63049#63050 · In reply to: #63049 Hi Paddy, Couldn't this just be a new option for the `filter_var()` function? $clean = filter_var($_POST['someVar'], XSS_CLEAN); - Paul. > 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 continued lack of understanding > surrounding how to properly escape data. To try and offset this, I've > written articles, attempted to raise awareness and wrote the > Zend\Escaper class for Zend Framework. Symfony 2's Twig has since > adopted similar measures in line with its own focus on security. > > That's all. The RFC should be self-explanatory and feel free to pepper > me with questions. As the RFC notes, I'm obviously not a C programmer > so I'm reliant on finding a volunteer who's willing to take this one > under their wing (or into their basement - whichever works). > > https://wiki.php.net/rfc/escaper > > Best regards, > Paddy > > -- > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > Zend Framework Community Review Team --- ## #63051 — Paul Dragoonis — 2012-09-18T11:34:36+00:00 URL: https://externals.io/message/63049#63051 · In reply to: #63050 > 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_var, ie.: FILTER_ESCAPE_[URL, JS, CSS, HTMLATTR]. - Paul. > > - Paul. > > > > […] --- ## #63052 — Anthony Ferrara — 2012-09-18T11:39:42+00:00 URL: https://externals.io/message/63049#63052 · In reply to: #63050 Paul > 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 filtering and escaping. Remember, Filter In, Escape Out. If you really wanted something like that, then perhaps add a escape_var extension. But I think the proposed API is better as it's more explicit. Anthony --- ## #63053 — Paul Dragoonis — 2012-09-18T12:00:10+00:00 URL: https://externals.io/message/63049#63053 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, Paul. > 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 character encodings used in real life are far more > diverse. Additionally, the RFC was an attempt to make escaping as > explicit and restrictive as possible - give a user too many options, > or too many dispersed units of functionality, and they'll invariably > confuse and misinterpret themselves to Hell ;). > > Note: There is a stack of folk, for example, who use the ext/filter > URL validator for HTTP validation - it also passes php:// and > javascript:// URLs. If we're not explicit, they won't ever notice when > they're doing it wrong. > > Paddy > > > > […] > > > > -- > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > Zend Framework Community Review Team --- ## #63054 — Derick Rethans — 2012-09-18T12:11:32+00:00 URL: https://externals.io/message/63049#63054 · In reply to: #63049 > 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 continued lack of understanding > surrounding how to properly escape data. To try and offset this, I've > written articles, attempted to raise awareness and wrote the > Zend\Escaper class for Zend Framework. Symfony 2's Twig has since > adopted similar measures in line with its own focus on security. > > That's all. The RFC should be self-explanatory and feel free to pepper > me with questions. As the RFC notes, I'm obviously not a C programmer > so I'm reliant on finding a volunteer who's willing to take this one > under their wing (or into their basement - whichever works). > > https://wiki.php.net/rfc/escaper I understand that this is really beneficial to have, but, I wonder, why can't this be a composer-installable class, implemented in PHP? It solves the issue that you need to find a volunteer, as well as that updating it is a lot easier, and, you don't have to rely on shared hosters having it enabled. I realize that you want to have this generally available, but for that we have ext/filter - which is not really used too much I *think*. Why would this be different? IMO, we should make a composer installable package for this, and then litter all our escaping related document pages with links to this new package. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine --- ## #63057 — padraic.brady@gmail.com — 2012-09-18T12:27:33+00:00 URL: https://externals.io/message/63049#63057 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. Existing functions are widely misused, misconfigured or have builtin security issues yet are popularly advanced as "escaping" for XSS. XSS is also...XSS. It's either the first or second most common vulnerability in web applications (depending on whose data you use). I think it warrants PHP distributing a proper solution out of the box. Paddy > > > > […] > > I understand that this is really beneficial to have, but, I wonder, why > can't this be a composer-installable class, implemented in PHP? It > solves the issue that you need to find a volunteer, as well as that > updating it is a lot easier, and, you don't have to rely on shared > hosters having it enabled. > > I realize that you want to have this > generally available, but for that we have ext/filter - which is not > really used too much I *think*. Why would this be different? IMO, we > should make a composer installable package for this, and then litter all > our escaping related document pages with links to this new package. > > cheers, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > Posted with an email client that doesn't mangle email: alpine -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team --- ## #63058 — padraic.brady@gmail.com — 2012-09-18T12:28:16+00:00 URL: https://externals.io/message/63049#63058 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 character encodings used in real life are far more diverse. Additionally, the RFC was an attempt to make escaping as explicit and restrictive as possible - give a user too many options, or too many dispersed units of functionality, and they'll invariably confuse and misinterpret themselves to Hell ;). Note: There is a stack of folk, for example, who use the ext/filter URL validator for HTTP validation - it also passes php:// and javascript:// URLs. If we're not explicit, they won't ever notice when they're doing it wrong. Paddy > > > […] > > I see from your RFC that you have a bunch of functions, I believe all > these could be options to filter_var, ie.: FILTER_ESCAPE_[URL, JS, > CSS, HTMLATTR]. > > - Paul. > > > […] -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team --- ## #63065 — Michael Shadle — 2012-09-18T16:24:04+00:00 URL: https://externals.io/message/63049#63065 · In reply to: #63053 > 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, > Paul. Please provide it as a procedural extension as well like filter is. I don't care if there is an OO counterpart, but I detest OO and don't want to see basic php things being introduced now (if accepted) only as OO. It feels like PHP is losing its roots... --- ## #63066 — jpauli — 2012-09-18T16:31:13+00:00 URL: https://externals.io/message/63049#63066 · In reply to: #63057 > 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. Existing functions are widely misused, misconfigured or > have builtin security issues yet are popularly advanced as "escaping" > for XSS. > > XSS is also...XSS. It's either the first or second most common > vulnerability in web applications (depending on whose data you use). I > think it warrants PHP distributing a proper solution out of the box. > > Paddy > > > > […] > > > > -- > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > Zend Framework Community Review Team > > > -- > Pádraic Brady > > http://blog.astrumfutura.com > http://www.survivethedeepend.com > Zend Framework Community Review Team > > -- > > > 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 servers tried to push (mod_security and its counterpart in Nginx), its PITA to maintain if you want something that covers a large area. By the way : why not let the web server do this as nowadays, they seem to manage that problem ? Julien.P --- ## #63067 — Michael Shadle — 2012-09-18T16:39:55+00:00 URL: https://externals.io/message/63049#63067 · In reply to: #63066 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 :)) --- ## #63068 — Rasmus Lerdorf — 2012-09-18T16:45:24+00:00 URL: https://externals.io/message/63049#63068 · In reply to: #63067 > 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 :)) It is utf-8 by default as of PHP 5.4. --- ## #63069 — Stas Malyshev — 2012-09-18T16:51:35+00:00 URL: https://externals.io/message/63049#63069 · In reply to: #63049 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, a problem with putting code of this complexity in core would be that if it every had a defect - e.g. we forgot to account for some weird browser quirk that does not follow RFCs, or some strange encoding combination, or just a plain bug - it would be very hard for the users to mitigate without upgrading PHP - which is not always under their control. When using PHP code, they could just d/l new ZF class, but with core implementation it'd be much harder. So far I am not convinced we should really do it. But if somebody creates PECL extension and it proves popular, it may be merged into core once it does. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #63070 — Anthony Ferrara — 2012-09-18T16:56:03+00:00 URL: https://externals.io/message/63049#63070 · In reply to: #63069 Stas, On Tue, Sep 18, 2012 at 12:51 PM, Stas Malyshev wrote: > Hi! > > > […] > > We already have filter extension. Is it really necessary to invent yet > another way of filtering data? > Filtering is very different from escaping. They each handle similar but unique problems: http://stackoverflow.com/questions/4218136/is-filter-input-escape-output-still-valid-with-pdo/4218219#4218219 > Also, a problem with putting code of this complexity in core would be > that if it every had a defect - e.g. we forgot to account for some weird > browser quirk that does not follow RFCs, or some strange encoding > combination, or just a plain bug - it would be very hard for the users > to mitigate without upgrading PHP - which is not always under their > control. When using PHP code, they could just d/l new ZF class, but with > core implementation it'd be much harder. > > So far I am not convinced we should really do it. But if somebody > creates PECL extension and it proves popular, it may be merged into core > once it does. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #63071 — Stas Malyshev — 2012-09-18T16:56:36+00:00 URL: https://externals.io/message/63049#63071 · In reply to: #63057 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 code in Perl without ever using CPAN". Makes no sense, right? Why we should insist on this in PHP? > solutions. Existing functions are widely misused, misconfigured or > have builtin security issues yet are popularly advanced as "escaping" > for XSS. Do you think your functions won't be misused, misconfigured and never would have bugs? Exactly the same would happen. Having yet another API doing the same as old API is not a solution. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #63072 — Stas Malyshev — 2012-09-18T17:00:40+00:00 URL: https://externals.io/message/63049#63072 · In reply to: #63070 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 for input, does not mean we can't use the same for output, there is absolutely no need to reinvent the wheel just because we're using it in different place now. It is a mistake to think that because we started to use filtering on input data, now the word "filtering" means it should never applied to output and we have to invent whole new API to do the same. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #63073 — Andrew Faulds — 2012-09-18T17:03:54+00:00 URL: https://externals.io/message/63049#63073 · In reply to: #63072 > Hi! > > > […] > 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 for > input, does not mean we can't use the same for output, there is > absolutely no need to reinvent the wheel just because we're using it in > different place now. It is a mistake to think that because we started to > use filtering on input data, now the word "filtering" means it should > never applied to output and we have to invent whole new API to do the same. 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. -- Andrew Faulds http://ajf.me/ --- ## #63074 — Stas Malyshev — 2012-09-18T17:09:14+00:00 URL: https://externals.io/message/63049#63074 · In reply to: #63073 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 of filtering. Moreover, even existing filters do not match your description: FILTER_SANITIZE_ENCODED, FILTER_SANITIZE_MAGIC_QUOTES, FILTER_SANITIZE_SPECIAL_CHARS, FILTER_SANITIZE_FULL_SPECIAL_CHARS, FILTER_SANITIZE_STRING, `FILTER_CALLBACK` But in general, look at implementation of filters anywhere - like Apache filters or IIS filters - nowhere it is said that filter can only remove data. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #63076 — Andrew Faulds — 2012-09-18T17:11:04+00:00 URL: https://externals.io/message/63049#63076 · In reply to: #63074 > Hi! > > > […] > Again, you are confusing particular implementation of a particular > filter with the idea of filtering. Moreover, even existing filters do > not match your description: > FILTER_SANITIZE_ENCODED, FILTER_SANITIZE_MAGIC_QUOTES, > FILTER_SANITIZE_SPECIAL_CHARS, FILTER_SANITIZE_FULL_SPECIAL_CHARS, > FILTER_SANITIZE_STRING, `FILTER_CALLBACK` > > But in general, look at implementation of filters anywhere - like Apache > filters or IIS filters - nowhere it is said that filter can only remove > data. Ah, sorry, I think I'm confusing the standard English language meaning of filter with regards to the physical device or signal processing, with the meaning in the field of computer science etc. -- Andrew Faulds http://ajf.me/ --- ## #63077 — Anthony Ferrara — 2012-09-18T17:14:24+00:00 URL: https://externals.io/message/63049#63077 · In reply to: #63074 Stas, On Tue, Sep 18, 2012 at 1:09 PM, Stas Malyshev wrote: > Hi! > > > […] > > Again, you are confusing particular implementation of a particular > filter with the idea of filtering. Moreover, even existing filters do > not match your description: > 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. > FILTER_SANITIZE_ENCODED, FILTER_SANITIZE_MAGIC_QUOTES, > FILTER_SANITIZE_SPECIAL_CHARS, FILTER_SANITIZE_FULL_SPECIAL_CHARS, > FILTER_SANITIZE_STRING, `FILTER_CALLBACK` > > But in general, look at implementation of filters anywhere - like Apache > filters or IIS filters - nowhere it is said that filter can only remove > data. > Actually, that's the basic definition of a filter (from a security context). Just because people implemented other things and called them filters does not make them filters in the context of this discussion. The other point that you seem to be missing is that filtering is generic for an application. You would apply the same filters for content that came in from an HTTP post as content that came in from a JSON API call. The data is what's filtered for your application. Escaping on the other hand is context dependent. You need a different form of escaping for each output type (HTML, HTML attribute, XML, XML attribute, XML processing instruction, JSON, database query, etc). So you cannot do a generic escaping like you can do a generic filtering. Escaping should be done as close to the edge as possible. Check out this post I did a while ago with a pretty drawn out section talking about the two concepts... http://blog.ircmaxell.com/2011/03/what-is-security-web-application.html Anthony --- ## #63078 — Andrew Faulds — 2012-09-18T17:16:34+00:00 URL: https://externals.io/message/63049#63078 · In reply to: #63077 > Stas, > > On Tue, Sep 18, 2012 at 1:09 PM, Stas Malyshev > wrote: > > Hi! > > > […] > content > > […] > make > > […] > > Again, you are confusing particular implementation of a particular > filter with the idea of filtering. Moreover, even existing filters do > not match your description: > > > 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, English language context, and signal processing context, a filter removes. In computer science, but not computer security, it processes. I'm very confused :P -- Andrew Faulds http://ajf.me/ --- ## #63080 — padraic.brady@gmail.com — 2012-09-18T17:29:14+00:00 URL: https://externals.io/message/63049#63080 · In reply to: #63066 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 - these are always broken in time. In this specific case, the rules for escaping are well known and very rarely change unless HTML sees some very dramatic changes in how tags and attributes are defined. Paddy > > > […] > > 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 servers tried to push (mod_security and its > counterpart in Nginx), its PITA to maintain if you want something that > covers a large area. > By the way : why not let the web server do this as nowadays, they seem > to manage that problem ? > > Julien.P -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team --- ## #63081 — Andrew Faulds — 2012-09-18T17:31:03+00:00 URL: https://externals.io/message/63049#63081 > > 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 attribute: escapeHtmlAttr, escapeCss, or both? > HTML on* attributes: escapeHtmlAttr, escapeJs, or both? > HTML href/src attributes: escapeHtmlAttrs, escapeUrl, or both? > HTML script/style elements: Is escapeHtml needed? > > I can probably correctly guess some of these, but I think ideally the > method and class names should make this more obvious. If escapeJs is > only for string literals in JS code (again, the name doesn't make that > clear to me), what does escapeCss actually do, since string literals > aren't very common in CSS? 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, escapeCSSIdentifier, and another needs adding (for url('*') things), escapeCSSStringLiteral. -- Andrew Faulds http://ajf.me/ --- ## #63082 — padraic.brady@gmail.com — 2012-09-18T17:32:17+00:00 URL: https://externals.io/message/63049#63082 · In reply to: #63067 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 will obviously be near and dear to my design patterned heart ;). Paddy > 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 :)) > -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team --- ## #63083 — Anthony Ferrara — 2012-09-18T17:33:34+00:00 URL: https://externals.io/message/63049#63083 · In reply to: #63066 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 servers tried to push (mod_security and its > counterpart in Nginx), its PITA to maintain if you want something that > covers a large area. > By the way : why not let the web server do this as nowadays, they seem > to manage that problem ? > As Padraic indicated, this is solving a different problem than the web server even can. This has to be solved at the application layer (it physically can't be sovled above it)... As far as implementation pains, if I was to support this, I would want to see something like the ESAPI (Enterprise Security API - by OWASP) used for the actual implementation: http://code.google.com/p/owasp-esapi-c/ Perhaps providing a thin wrapper around it, but I wouldn't go much further than that. And I don't think I'd support our own implementation (not using an established C library)... Anthony --- Next page: https://externals.io/message/63049.md?page=2