Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

weierophinney
Administrator
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            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Reply | Threaded
Open this post in threaded view
|

Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

David Muir-2
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 <[hidden email]> 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            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

Marco Pivetta
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.



On 22 May 2014 07:15, David Muir <[hidden email]> 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
<[hidden email]>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            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

David Muir-2
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 <[hidden email]> 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.



On 22 May 2014 07:15, David Muir <[hidden email]> 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
<[hidden email]>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            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

jeremiah
Maybe give mustache a try, instead of rolling your own.

Jeremiah

> On May 24, 2014, at 10:31 PM, David Muir <[hidden email]> wrote:
>
> 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 <[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]>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            | [hidden email]
>>> Zend Framework          | http://framework.zend.com/
>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>>
>>> --
>>> List: [hidden email]
>>> Info: http://framework.zend.com/archives
>>> Unsubscribe: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

David Muir-2
Jeremiah,

I don’t think mustache would help in this case.
If we were using mustache, it would expect the template to look like this:
<input type=“text” name=“additional[{{rowId}}]” />

but the template we get from Zend\Form would look like this:
<input type=“text” name=“additional&#x5B;&#x7B;&#x7B;rowId&#x7D;&#x7D;&#x5D;” />

The consensus on stackoverflow seem to be to use the textarea hack to decode it. Is that safe to do from an xss standpoint?

Cheers,
David


On 25 May 2014, at 6:00 pm, Jeremiah Small <[hidden email]> wrote:

Maybe give mustache a try, instead of rolling your own.

Jeremiah

On May 24, 2014, at 10:31 PM, David Muir <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]> 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
<[hidden email]>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            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: [fw-general] Zend Framework 1.12.6, 2.2.7, and 2.3.1 Released!

David Muir-2
I have considered looking at JS MVC setups, but have held off, partly because it's such a big break from what my team and I are used to, but also because I've seen others (notably Twitter) return to a more traditional, server-side html rendering approach after having gone the JS application route because the performance was so much better. That was 2 years ago though, so I don't know how much has changed since then.

I've heard good things about AngularJS, so I might look at that for future projects. In the mean time, I'll look at using __ for templates.

Cheers,
David



Sent from my iPhone

On 27/05/2014, at 9:11 PM, Stefano Torresi <[hidden email]> wrote:

Personally I'd suggest going for the double underscore notation.

By the way, having been there, this is one of the symptoms that eventually drove me in the direction of dropping PHP from rendering as much as possible, especially forms.

Even for apparently simple UIs, integrating server side and client side HTML processing can become unpractical, to say the least.

Probably it's too late now for your current project, but it's the trend of the moment anyway, so maybe embrace it for your next one. ;)

Il 25/mag/2014 12:27 "David Muir" <[hidden email]> ha scritto:
Jeremiah,

I don’t think mustache would help in this case.
If we were using mustache, it would expect the template to look like this:
<input type=“text” name=“additional[{{rowId}}]” />

but the template we get from Zend\Form would look like this:
<input type=“text” name=“additional&#x5B;&#x7B;&#x7B;rowId&#x7D;&#x7D;&#x5D;” />

The consensus on stackoverflow seem to be to use the textarea hack to decode it. Is that safe to do from an xss standpoint?

Cheers,
David


On 25 May 2014, at 6:00 pm, Jeremiah Small <[hidden email]> wrote:

> Maybe give mustache a try, instead of rolling your own.
>
> Jeremiah
>
>> On May 24, 2014, at 10:31 PM, David Muir <[hidden email]> wrote:
>>
>> 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 <[hidden email]> 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 <[hidden email]> 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
>>> <[hidden email]>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            | [hidden email]
>>>> Zend Framework          | http://framework.zend.com/
>>>> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>>>>
>>>> --
>>>> List: [hidden email]
>>>> Info: http://framework.zend.com/archives
>>>> Unsubscribe: [hidden email]
>>