OK, that handles the strings that are generated by PHP.

How about on the client-side?
(2) What about for JavaScript - when storing and retrieving values from hidden input nodes, is there a preferred encoding/decoding strategy?

Since EM reads and manipulates the values directly from the text boxes, is there a good way to encode them before setting the value of an <input type='hidden'> node with the processed value of another node?


On Thu, Aug 25, 2011 at 4:26 PM, Carsten Schmitz <> wrote:
Hello Thomas,

All data entered  by the survey participants does not need to be encoded
in any way before being saved.

On display you should just make sure that it is properly quoted, for
HTML display htmlspecialchars($value,ENT_QUOTES,'utf-8') is the
preferred and safest way.
For Javascript 'htmlspecialchars($value,ENT_NOQUOTES,NULL,false)' does
not look safe - It depends how you inject the string into the array.
If you are doing this by page inline code then you should use the
function javascript_escape from the helper lib 'common_helper' . Like

echo "<script type='javascript'>
  var myJSStringVar='".javascript_escape('Some awesome string with
"lots of quotes and other oddities ;)")."';

No more filtering is necessary. XSS protection is only for
administration user (to prevent an admin with few permissions to inject
XSS code somewhere  in a survey so that he might trick a Superadmin into
giving up his credentials by for example showing a fake login mask). It
is NOT needed for participant data because participant response data is
properly escaped everywhere in the administration when displayed.


> Any value that is submitted in a text box is saved to the database.
>  Then, if someone uses the equivalent of {INSERTANS:xxxx} or
> {xxxx.shown}, that value will be:
> (1) stored in a JavaScript array for dynamic insertion when needed
> (2) put in a tool-tip for the PrettyPrint strings (that color code the
> Expression and show the javaScript name and current value of each
> variable used)
> (3) embedded in whatever string (e.g. question, answer, help,
> description) was desired within the HTML markup.
> Currently, I'm using htmlspecialchars($value,ENT_NOQUOTES,NULL,false)
> to encode the JavaScript values for (1) and (2).  I am not using
> htmlspecialchars() for (3), but could potentially use it when XSS
> protection is disabled.
> Use of htmlspecialchars() becomes slightly tricky since I also have a
> HtmlStripTags() function that is needed to extract the visible value
> from what is entered in order to evaluate the Relevance equations.  I
> expect I could use an open-source implementation of
> htmlspecialchars_decode(), but before I got that route, wanted to ask
> the broader questions:
> (1) For a text-entry box, what is the preferred way of encoding the
> entered content so that it displays properly and safely when a
> respondent clicks Previous to review their answers  (or just prints
> out their answers at the end)?
> (2) What about for JavaScript - when storing and retrieving values
> from hidden input nodes, is there a preferred encoding/decoding strategy?
> (3) Are (or should) either of these be different when XSS protection
> is turned off (e.g. to let authors create embedded JavaScript but
> avoid XSS by the respondent)?
> (4) Are there there any future plans by LimeSurvey to further protect
> against XSS that should be taken into consideration?
> /Tom

EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
limesurvey-developers mailing list