Are you sure about the PHP version being used? According to https://manual.limesurvey.org/Installation_-_LimeSurvey_CE#Make_sure_you_can_use_LimeSurvey_on_your_website Limesurvey 3.x requires PHP 5.5 or later, you mentioned PHP v5.4.

@DenisChenu, could this be related to the XSS filter?

@Mazi : i don't know … try to deactivate XSS and check …

@cdorin, FYI, this is an issue reported by one of our customers.

WIll also test it on multiple instances and assign it accordingly. Thanks for the tag

It is related to the XSS filter. If disabled, everything is fine. If enabled, the "&amp" is displayed

& is invalid in HTML …

Question : maybe we can deactivate XSS protection on attribute value ? Someone find a reason why it's added ?

Attribute can be shown in Survey, but likle all user entered value if i don't make error ?

Must find it was added, maybe there are a security reason …

Any chance to get this finally fixed at the next release?

Line apply XSS : https://github.com/LimeSurvey/LimeSurvey/blob/0479e3ff93ff1473a25c71e83cc011920b072b4c/application/models/Token.php#L358
blame/parent/browse/blame/parent/browse (because scrutinizer …)

Fixed here : https://github.com/LimeSurvey/LimeSurvey/commit/160b48a95f8bc5b9ac21d02c38720ac12092d9ce

Added here : https://github.com/LimeSurvey/LimeSurvey/commit/aeead563c66883cc97a3e861ab1ce4e7fded9b97

Then linked with https://bugs.limesurvey.org/view.php?id=9840

I assign it to Carsten : in my opinion : XSS can be filtered in «out» : always encode token attribute in view, but not in in (when saved)

@c_schmitz
@cdorin
@eddylackmann
...sorry to bother you, but again I was asked by the customer when a fix can be expected. Any news?

...sorry to bother you, but again I was asked by the customer when a fix can be expected. Any news?

It is "fixed". Just disable the XSS filtering.

We can't have both XSS filtering and leaving ampersand as-is. I argue this is already fixed, since the customer's desired behaviour is achieved if XSS filtering is disabled.

@ollehar, from my point of view there is not really a solution. This is a larger company with many LS users, Most of them are no super admins but need to be able to enter names with special characters like "&" at the participant screen.
What can they do if switching of XSS is no option for security reasons?

What can they do if switching of XSS is no option for security reasons?

Can't have both the cake and eat it. :|

Maybe we can limit HTML escaping to '<' and '>'? If that would be enough to limit XSS.

Here's a thread about it: https://stackoverflow.com/questions/39214564/why-ampersand-should-be-escaped-because-of-xss-injection

Happy reading!

Escaping & is correct. But how is showing &amp as the content instead of & relating to the stackoverflow article?
Escaping correctly doesn't result is showing & as &amp inside a web application.

The XSS filter is not used and complains about that "feature" is low. Most users are working with XSS filter off. Most Limesurvey installations have only 1-2 users, which are mostly having a user role, which never expose them to the XSS-filter.

@ollhar, isn't this actually a matter of properly showing escaped "&" characters?
If not, can we try to exclude "&" from XSS?

Forgive my missing kniowledge about the escaping details and the like. I only follow up on the customer's request but it would be weird to not be able to enter "Olle & Team" as a token name or attribute detail.

@CDorin Can you put priority on this? Or discuss it with Carsten during sprint planning.

To proclaim the only superadmins can entering "&" into fields is a way, but how can anyone take that serious?
I recommend to activate the XSS filter for superadmins for one week in LimeSurvey. The amount of feedback will be big ;-)

The htmlfilter is removing &. Which should not be the case.

html filter replace & by & amp; . Because when you show it insie html page it must be & amp ...

The question is more : did firstname and lastname (and attributes) must be HTML fitered ?

But : with {FIRSTNAME} {LASTNAME} : possible XSS.

I recommend to activate the XSS filter for superadmins for one week in LimeSurvey. The amount of feedback will be big ;-)

I already have sample user access on some instance, and we can do a lot ....

Question Why exactly it's an issue ? When you really need & in lastname ?

The "&" is part of many company names in Germany.
But I don't understand why a user have to explain why & should be a valid character for a Lastname field. Or any other field.
The developer has to explain, why "&" cannot be used in the field. I hope the solution is not to add a company field (where & is allowed).

Yes, and when a string with & are shown in HTML it's always & amp;

My opinion : the only issue is

• View in browse
• Send by email text.

Capture d’écran du 2020-02-11 16-01-45.png (15,615 bytes)   

Capture d’écran du 2020-02-11 16-01-45.png (15,615 bytes)   

Capture d’écran du 2020-02-11 16-02-03.png (12,714 bytes)   

Capture d’écran du 2020-02-11 16-02-03.png (12,714 bytes)   

To sum up:
Ollehar: No issue: XSS works as intended
DenisChenu; the only issue is...." View in browse" / "Send by email text"

Correct, the issue hasn't changed since 2019-06-14.
Displaying the entered content (here &) everywhere like it was entered is the expected behavior.
And that is not working during browsing data, sending e-mail and perhaps when displaying name inside the survey.
I don't have these issues, cause I don't use the XSS filter at all. So it might work correctly in the survey.

perhaps when displaying name inside the survey.

I think there are more potential issue without XSS when displaying in a HTML page (or an HTML email)

I don't see a way to fix this - even displaying it correctly is a problem.
Because we don't know who is sending the email or looking at the participants list - was it the XSS-filtered user who entered it in the first place or a superadmin? Is the ampersand supposed to be there or not, etc.

Maybe a solution for affected people would be to have the XSS filter as a user-based setting.

Maybe a solution for affected people would be to have the XSS filter as a user-based setting.

It can not be a setting for user : since it's a security settings : it must be an user rights setting.

@c-schmitz: Even displaying is a problem?
Someone is entering a company name into a field and save it. That name contains "&" as part of the name.
And to display that name correctly with escaped & in HTML is impossible for LimeSurvey?

It's same as here in Mantis. I type & into this Notefield.

The are NO issue when sending email in HTML format
Neither in HTML view or txt view

There are NO issue with {TOKEN:LASTNAME} usage

See the screenshots ...

Capture d’écran du 2020-02-12 12-01-28.png (4,015 bytes)   

Capture d’écran du 2020-02-12 12-01-28.png (4,015 bytes)   

Capture d’écran du 2020-02-12 12-01-52.png (12,888 bytes)   

Capture d’écran du 2020-02-12 12-01-52.png (12,888 bytes)   

Capture d’écran du 2020-02-12 12-02-14.png (14,145 bytes)   

Capture d’écran du 2020-02-12 12-02-14.png (14,145 bytes)   

Capture d’écran du 2020-02-12 12-02-28.png (16,925 bytes)   

Capture d’écran du 2020-02-12 12-02-28.png (16,925 bytes)   

Capture d’écran du 2020-02-12 12-04-10.png (17,137 bytes)   

Capture d’écran du 2020-02-12 12-04-10.png (17,137 bytes)   

Capture d’écran du 2020-02-12 12-04-44.png (12,765 bytes)   

Capture d’écran du 2020-02-12 12-04-44.png (12,765 bytes)   

Only real issue : when sending email as text (Survey setting : Use HTML format for token emails: to NO)

Another way to fix it would be to see participants data generally as unsafe. That would mean we would XSS-filter it always on output. In the administration this is already done. For the survey taking part this could be also done. It will just be a problem for people who store data with HTML in their participants fields and want to show it in the survey (it would be no problem for E-mails). Question is if users do that (I bet there are) and how many they are.

@jelo

And to display that name correctly with escaped & in HTML is impossible for LimeSurvey?

is totally false ! Please test before writing something : in fact & NEED to be escaped to be displayed in HTML

See the screenshot at https://bugs.limesurvey.org/view.php?id=14972#c55897

Yes, I meant a user-based permission.

It will just be a problem for people who store data with HTML in their participants fields.

Why not, but if user have XSS enabled : it must be filtered ......

The only issue is "Use HTML format for token emails: to NO"

And to display that name correctly with escaped & in HTML is impossible for LimeSurvey?

Yes, it is. To show it you would have to HTML decode it first, which means that you could introduce XSS in the administration. This is not just about the ampersand here, but about all critical characters.

OK, so three measures here:

• Implement XSS filter user permission
• Change existing global permission to have the following options 'Force to Yes (Default)', 'User-based', 'Force to No', while the old On/off will map to the "Force to yes" and "Force to No."
• Remove XSS filter on input/import for participant data and generally filter participant data instead on output (survey taking, invitations/reminders) - no exceptions!

(Todo: I am not sure about that last point because someone out there is probably using participant data attributes to store URLs and such - also do not know who entered the data in the first place)

These are significant changes, can only be implemented in 4.x.

filter participant data instead on output (survey taking)

Must be when sending html email too ....

1. I currently trust the screenshots from the ticket starter. If you all tell me they are faked, fine.
2. In the screenshot I see a &amp instead of a &. And you tell me that is like you want LimeSurvey to behave?

datenausgabeModfied.jpg (13,839 bytes)   

datenausgabeModfied.jpg (13,839 bytes)   

It's only on the list ... This is not a real issue ...
And in this part : we must encode HTML else anybody can do anything with your account.

Must be when sending html email too ....

Sure, for HTML email it should also be automatically encoded.

@jelo The screenshots are not faked, but the problem is deeper than you currently seem to realize.

The funny thing is, that my understanding or misunderstanding is not important.
The only important thing is the official reasoning of LimeSurvey for that behavior (Entering &, displaying &amp).

Now I read: "It's only on the list ... This is not a real issue."
The whole ticket is about that the list is displaying the entered text wrong.

The real issue might be implementing a ZeroTrust model inside LimeSurvey without making the user experience zero too.
I second your idea with user permission. Placing XSS-protections settings in the Userpermssion profil is the shortcut solution.

@jelo Yes, and I understand your user story.
The measures I proposed above will completely take care of both user experience and security, so I am wondering why you keep implying that "that is like I want LimeSurvey to behave?"

c_schmitz: There are more participants in this ticket than you. If you read all the notes the conclusion that it is intended behavior is not far fetched. To allow deactivating of XSS countermeasure to prevent showing &amp is not contradicting the intended behavior statement.

But as cdorin is the product owner and ticket owner he can surely be able to sum it up after the next sprint.
And since it is a userstory from a customer of Mazi, they need to be pleased. Not me, I don't use the participation list for mailings.

Thanks for your time.

Now I read: "It's only on the list ... This is not a real issue."
The whole ticket is about that the list is displaying the entered text wrong.

This is for me @jelo, not for @c_schmitz or @cdorin or any LimeSurvey team.

And sorry : maybe the screenshot was about list, but text of issue are

14972: Ampersand will be translated into "&amp"
If survey participants add firstname, lastname or more attributes like company names with an ampersand (&), this will be translated for example into “&amp”.
This problem does not existfor Super-Admin, just by regular users.

It's not limited to list in the description.

And in https://bugs.limesurvey.org/view.php?id=14972#c55867, i ask

Question Why exactly it's an issue ? When you really need & in lastname ?

You really need & decoded in list ? Really needed ? No, i don't think ...

You really need to show "Your company are LimeSurvey & plugin" during survey : OK, no issue here. Encoded 1 is OK....

Anyway, discussion is finished. Solutions is in 14972:55904

Should I move this to new features? I believe I fixed a similar issue related to ' earlier.

What's the priority?