Re: RFC: Implementing a core anti-XSS escaping class
| From: | David Muir | Date: | Thu, 20 Sep 2012 03:25:23 +0000 |
| Subject: | Re: RFC: Implementing a core anti-XSS escaping class | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-63178@lists.php.net to get a copy of this message | ||
On 20/09/12 07:48, Michael Shadle wrote:
On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady <padraic.brady@gmail.com> wrote:-1 on the flag based api, though. Would much rather have dedicated functions. It's easier to read, and less verbose. <!-- str_escape with flags --> <?php $enc = getMyEncoding();?> <table title="<?=str_escape($foo, ESCAPE_HTML_ATTRIBUTE, $enc)?>">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 ;).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 flags are really what differentiate the behavior... Then there is not a handful of functions but rather one that can be used as the abstraction point and the flags passed to it will change it's behavior, much like the filter functions. (I just see this falling under one solid defacto escape function standard, and it could live by itself as "escape" or something, or as it operates on strings, prefix it as such) I'm on the fence with a default encoding. I tend to always use UTF-8, so would probably just use the default. But that means I become less aware of encoding being central to the issue, and therefore much easier to accidentally leave it as UTF-8 when it should be something else.
<tr>
<td><?=str_escape($foo, ESCAPE_HTML, $enc)?></td>
<td><?=str_escape($bar, ESCAPE_HTML, $enc)?></td>
</tr>
</table>
<!-- dedicated escaping functions -->
<?php $enc = getMyEncoding();?>
<table title="<?=escape_html_attribute($foo, $enc)?>">
<tr>
<td><?=escape_html($foo, $enc)?></td>
<td><?=escape_html($bar, $enc)?></td>
</tr>
</table>
<!-- OOP style -->
<?php $e = new Escaper(getMyEncoding())?>
<table title="<?=$e->escapeHtmlAttr($someTitle)?>">
<tr>
<td><?=$e->escapeHtml($foo)?></td>
<td><?=$e->escapeHtml($bar)?></td>
</tr>
</table>
I prefer the OO API since it's succinct, but if we are to have a procedural API as well, lets make it concise and clear. The last thing we want for solving the no 1 security threat to web-apps is a confusing and hard-to-use API like the filter extension.
Cheers,
David