Issue with JFormFieldTextarea::getInput() and line breaks

[Clubnite]

Hey folks, i'd like to ask your for your opinions and suggestions regarding the JFormFieldTextarea::getInput().

I am using a textarea to send messages which is a common task. I also store sent messages into the database. Before the data is stored i apply some manipulation in the way that i explode the message text using the new line character as delimiter. To each new line i prepend the '> ' character because i append that stored message below a potentially new message to keep track of it. Finally i implode the lines using '\n' (no double quotes) as delimiter so that i can use it when reading the row and preparing the message for display. This is all good (i think).

Then, when i want to view a message i load the related row and replace all occurances of '\n' by "
" as this is the only working characterset (see: http://stackoverflow.com/a/21612952). Neither PHP_EOL nor the commonly used "\r\n" work to display line breaks.

However, the message for display will only be displayed with new lines when the input is created without using PHPs htmlspecialchars() method.

Now my questions to you is: 

What is the intention of that method when generating the textarea field? Is it to strip out HTML markup? I know what its intention is in general. But i wonder if it could be replaced by a less intrusive alternative not breaking the display of line breaks. Or if not, how else can i get my line breaks back into the message? I require to have them.

[Bakual]

If the textare formfield doesn't work, you can create your own field: https://docs.joomla.org/Creating_a_custom_form_field_type
You could extend it from the textarea one and only override and adjust the getInput method.

And yes, htmlspecialchars() is used to make sure the field doesn't break the whole form when some clever user enters HTML.

[Clubnite]

Ofcourse I could just create my own formfield. But I prefer to learn and understand the motivation for the decision to use htmlentities() over htmlspecialchars().

I suppose there was good reason to use htmlentities() and I'm interested to know it from a security point of view. I just don't want to introduce a security whole through a potentially wrong decision which is why I ask you guys for your opinions. If it's just a compatibility issue I would feel safer when weighing which one to use.

[Sergio Manzi]

Hi!

On 2015-06-24 12:23, Clubnite wrote:

Ofcourse I could just create my own formfield. But I prefer to learn and understand the motivation for the decision to use htmlentities() over htmlspecialchars().

I suppose there was good reason to use htmlentities() and I'm interested to know it from a security point of view. I just don't want to introduce a security whole through a potentially wrong decision which is why I ask you guys for your opinions. If it's just a compatibility issue I would feel safer when weighing which one to use.

I don't think any security concern is addressed by those functions.

htmlspecialchars()  convert to HTML entities the following characters:

'&' (ampersand) becomes '&'
'"' (double quote) becomes '"' when ENT_NOQUOTES is not set.
"'" (single quote) becomes ''' (or ') only when ENT_QUOTES is set.
'<' (less than) becomes '&lt;'
'>' (greater than) becomes '&gt;'

It is thus useful to convert HTML tags into their "HTML representation."

htmlentities(), instead, convert all characters that have a corresponding HTML entity, following different rules accordingly to the specified "flag" parameter (see: http://php.net/htmlentities)

[Niels Braczek]

Am 24.06.2015 um 12:23 schrieb Clubnite:

> But I prefer to learn and
> understand the motivation for the decision to use htmlentities() over
> htmlspecialchars().
> I suppose there was good reason to use htmlentities()

The use of htmlentities() is a relict from times, where many browsers
had problems with UTF-8. It also converts fx. umlauts into their entity
codes, so special characters can be addressed using any encoding.

From a security poit of view, i.e., escaping HTML, htmlspecialchars() is
sufficient and thus the right choice.

Regards,
Niels

--
| New Stars on the Horizon: GreenCape · nibralab · laJoom |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Bakual]

There is a small security issue when you don't use htmlspecialchars() for the output. Basically it means that text entered by the user (or in case of XSS attacks an attacker) is show again and run in the browser.
It depends on what the code on server side does with the submitted input. If it's always processed and sanitised, then there is no issue. But when the submitted data in some cases (like in error conditions) is just returned as is, then it may become an issue.

With using htmlspecialchars() you're always on the safer side.

[Clubnite]

Thank you guys for your valuable responses clarifying that topic!