Re: [MRBS-general] Double or missing htmlspecialchars()

[Thomas B. <Tho...@gm...>]

* Thomas Bleher <Tho...@gm...> [2013-01-28 17:12]:
> * Campbell Morrison <cam...@gm...> [2013-01-28 15:03]:
> > Good question.    While the particular problem below could presumably be solved by saving your config file as a UTF-8 file, there will be cases where it is necessary to have special characters in a config string - for example quotes, an ampersand or <br>.     So I think that config strings should be trusted and not put through htmlspecialchars(), but maybe to be on the safe side they should be put through strip_tags() with a small set of allowable tags, eg <br>.
> 
> I don't think allowing tags is safe there, because the types are also
> used in select dropdowns, and <option> tags may only contain text.
> At the very least, tags would need to be stripped there. I vote for
> allowing entities, but not allowing any tags for types.

Entities are now allowed in type strings (r2705). Note that the change
is only in the linked_bookings branch at the moment. The change touched
some code areas that were also touched by the branch, and I wanted to
avoid needless merge conflicts.

Thomas
 
> > > -----Original Message-----
> > > From: Diego Zuccato [mailto:die...@un...]
> > > Sent: 28 January 2013 13:26
> > > To: General purpose list (support/developers/users)
> > > Subject: [MRBS-general] Double or missing htmlspecialchars()
> > > 
> > > Hi.
> > > 
> > > Seems $subj happens when processing booking types for list in reports.
> > > To replicate: use a html entity in $vocab_override['en']["type.E"] and
> > > you'll see it in list, but processed when displaying legend.
> > > I had $vocab_override['it']['type.F']='Festivit&agrave;'; in my config
> > > and I correctly saw 'Festività' in legend but I get
> > > 'Festivit&amp;agrave;' in typematch[] (looking at the source of the
> > > reports page).
> > > 
> > > I don't know what's the correct fix:
> > > - always use the supplied string: who configures the system is
> > > responsible for correctly escaping entities
> > > - always process configured strings with htmlspecialchars()
> > > 
> > > But I think a consistent processing is necessary.
> > >