Hey Marco,
No, the placeholders are not part of user input. They’re hard-coded in, but
because they’re inside attributes, they’re now getting escaped, when before
they weren’t.
Eg.
<script id=“my-template” type=“text/html”>
<?php
$field = clone $form->get(‘name’);
$field->setAttribute(‘name’, “additional[{rowId}]”);
echo $form->formText($field);
?>
</script>
Then in js, we have something like this:
var template = $(‘#my-template’).html();
template.replace(‘{rowId}’, valueToInject);
$(‘#target-form’).append(template);
We’ve gotten around it by using the following trick, but it feels kludgey, and
doesn’t always work:
var template = $('<textarea/>').html($(‘#my-template').html()).html();
Alternatives that I haven’t tried yet, so I don’t know if all of them will work:
1. hard-code the templates entirely, and forgo using Zend\Form (ugh)
2. call html_entity_decode() on the output of formText() before echoing (should
solve the reliability issues we’ve had with the textarea trick)
3. replace the placeholders to use underscores instead of curly braces
(assuming this would work since that’s what the docs for Form Collections uses)
4. place the template into a data attribute instead of a <script> element so
that the browser parses the entities back into regular characters for me
Cheers,
David
On 24 May 2014, at 9:08 am, Marco Pivetta <ocram...@gmail.com> wrote:
> Hey David,
>
> Template parameter placeholders shouldn't really be part of the user input,
> should they? I think you had a quite bad security issue upfront there ;-)
>
> If you really need unescaped strings, then you could eventually override the
> `escapeHtmlAttr` helper, but be reeeeeeeeeeeeally careful about what you are
> doing. I won't take responsibility for any security issues introduced by
> doing that.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> On 22 May 2014 07:15, David Muir <davidkm...@gmail.com> wrote:
> The security fix broke our javascript templates that contained form
> elements. :-(
> All the curly braces in attributes are being converted to html entities, so
> our string replace calls aren't finding the braces anymore. Is there a way
> to easily get the old behaviour?
>
> Cheers,
> David
>
>
>
>
> On Wed, Apr 16, 2014 at 6:16 AM, Matthew Weier O'Phinney
> <matt...@zend.com>wrote:
>
> > We've just pushed out several new releases:
> >
> > - Zend Framework 1.12.6: This fixes a BC break with regards to a
> > number of Locales that was introduced in 1.12.4; you can read about it
> > at http://bit.ly/zf-1-12-6
> >
> > - Zend Framework 2.2.7 and Zend Framework 2.3.1: These fix a security
> > issue reported at
> > http://framework.zend.com/security/advisory/ZF2014-03 - a potential
> > XSS vulnerability in a number of ZF2 view helpers. Additionally, ZF
> > 2.3.1 contains more than 80 bugfixes; you can read about these
> > releases at http://bit.ly/zf-2-3-1
> >
> > If you are using ZF2, and specifically view helpers, we highly
> > recommend upgrading to either 2.2.7 or 2.3.1 ASAP.
> >
> > Packages are available via composer, pyrus, or
> > http://framework.zend.com/downloads/latest
> >
> > --
> > Matthew Weier O'Phinney
> > Project Lead | matt...@zend.com
> > Zend Framework | http://framework.zend.com/
> > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
> >
> > --
> > List: fw-general@lists.zend.com
> > Info: http://framework.zend.com/archives
> > Unsubscribe: fw-general-unsubscr...@lists.zend.com
> >
> >
> >
>
