• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.


User text escaping flaws - 2013

Page history last edited by Shal 7 years, 7 months ago


Table of Contents


You can help by writing or correcting items, or just by commenting. Please read About YahooGroupedia.





Beginning in December of 2012 people began reporting odd characters appearing in various places within Yahoo Groups pages, and in some cases features not working correctly. Many of these appear to boil down to flaws in how Yahoo is escaping user-entered text when displayed on their web pages.


When displaying user-entered text on a web page certain characters require special handling -- escaping -- to prevent them from being interpreted as part of the HTML syntax of the enclosing page. These characters are:


less than sign or left angle bracket
lead-in for HTML element tags
greater than sign or right angle bracket
close for HTML element tags
lead-in for character references
quotation mark
denotes HTML element attribute value
denotes HTML element attribute value








Failure to properly escape these characters, when they appear in user-supplied text, can lead to unintended consequences, and in the worst case can enable an XSS exploit of the site or the site's users.


It is suspected that the flaws noted here were introduced in a faulty attempt to limit the vulnerability of Yahoo's pages. "Stopping HTML content" is the WRONG goal. If the engineers have been given that as their mandate they may be prone to making the kinds of errors reported here.

For any field which is supposed to be plain text* the correct goal is to display the user's content literally. So when a user enters the sequence of characters "<", "b", ">", "b", "o", "l", "d", "<", "/", "b" and ">"" the proper display is "<b>bold</b>" -- not the word "bold" in bold type, not the word "bold" by itself, and certainly not a void with no characters at all.

*In Yahoo Groups that is just about everywhere, save the Rich Text Editor, the Home page description, and message bodies in the Messages section of groups that allow attachments (and hence HTML content)





These reports were made in the Yahoo! Groups sub-category of Yahoo! Answers. Some have been deleted for not being questions.



Why did semicolons appear after quotes in photo descriptions?



Some kind of text sanitation bug occurred in Groups photos pages. User-entered apostrophes and double-quotes (and possibly other special characters) gained a spurious semicolon.

But whatever caused this was a one-time event, or a change in the way text is processed. Text entered now does not gain semicolons, only text that was entered some time ago appears to be affected.

Screen shot:
see also this Suggestion:



(fixed) Why are "<" characters disappearing in messages?



Looks like we're in for round two in the message text sanitation errors.

This time I posted a message with an URL properly delimited with <angle brackets>. I have the pending message notification to prove that both <angle brackets> were in the message as posted (by email). When it arrived in Pending, and when it posted, it lost the left angle bracket>.

Weirder, when I tried to edit it while pending the <URL> disappeared entirely. I cancelled the edit.

As before, this is also affecting the header fields seen in View Source.

For example, see this unrelated message:
"Expired page on recovering ownership/moderation"



(fixed) Rejection notices don't work?



When a message is pending a moderator has the option of rejecting it. That opens a message composition window and the moderator can create a message to send back to the member.

However, a few weeks ago (before the hardware upgrade) Yahoo made some changes to how text that originated with members is displayed in Yahoo Groups. And since that time, the rejection composition window has not shown the member's email address in the "To" field, where it had previously been displayed there. Also since that time, and I believe as a consequence of that change, the rejection notice is never received by the member. I believe that Yahoo's attempt to send it fails due to the missing email address.

If you moderate a group this problem is very simple to reproduce. Set your own posting privilege to the Moderated override. Send a test message to the group. Reject the message, but do not check the box to have the message cc'd to the group owners. Wait (in vain) for the rejection notice to arrive in your email inbox.


I tested it again this evening in my test group, sobfarleytest.

I posted the message by email and waited for it to arrive in Pending. I clicked on it to open it. Then I clicked the "Reject" button. I typed a reply ahead of the quoted message body, and clicked on "Send".

Here is some information from the pending message notification:
To approve or reject this message using the web, please visit:
X-Received: (qmail 46094 invoked from network); 20 Jan 2013 02:26:41 -0000
Message-ID: <0B.97.01431.1E55BF05@cdptpa-omtalb.mail
Date: Sat, 19 Jan 2013 18:26:39 -0800
To: sobfarleytest@yahoogroups.com
Subject: Re: [sobfarleytest] A test of message rejection
X-Yahoo-Group-Post: member; u=482551837; y=NDJiC0L3KbcKU3lopKTCahc0QJacbaBc5UDFLk…
X-YGroups-SubInfo: t=0;f=0;g=-etoTZ_UBXb-MtC07OYWHPCJ5_4hi0…



(fixed) The Rich-Text Editor malfunctions?



Some HTML elements get corrupted when you preview a message in the Rich-Text editor, causing bizarre results on the preview page.

Fortunately a simple example is easy to reproduce.

1) Copy an URL to the clipboard. I don't think it matters what it points to, I used this one:
2) Go to a group where you have posting privileges.
3) Click the "Post" link in the left column.
4) Click the "Rich-Text Editor." link on the composition page.
5) Type a sentence, such as "Here is a link for you."
6) Select a part of the sentence. I selected "a link".
7) Click on the "Add a Link" icon in the tool bar (just to the left of the smile emoticon).
8) Paste the previously copied URL, click OK.

Observe that the selected text is now link colored and underlined.

9) Click the "Preview" button (on the lower right).

Observe the peculiar results. In my case it was:
a link for you.

" >
Here is a link for you.

10) Click the "Edit" button.

Observe that your original sentence has been truncated, eliminating the link and the text after it.

Note: if you click "Send" in step (9) instead of Preview, the posted message will be ok. Except that a spurious space appears after the link.

I suspect that this malfunction is caused by faulty display processing of the user-supplied text, incorrectly handling user supplied HTML code.



(fixed) File names in <angle brackets> disappear



Faulty XSS prevention has broken file names in Groups Files section.

Yet another consequence of Yahoo's flawed implementation of cross-site scripting prevention is that file names that have the structure of an HTML element disappear. Leaving the Files list with a file that can't be opened or edited.

The steps to reproduce this effect are simple.

1) Go to a group where the Files section is available and you have the privilege to create files.
2) Click the "Files" link in the left column.
3) Click "Create Text File"
4) In the File Name: field type an HTML element look-alike. Such as "<File Name>", the other fields are optional.
5) Click the "Create File" button

Observe that the file list now has a text file with no (visible) name.
Observe that there is no place to click on it to open it.

6) Click the "Edit" link next to that file.

Observe that the File Name field appears to be blank.

7) Make any change, or no change, to the file's fields.
8) Click the "Save Changes" or "Cancel" button.

Observe the error page:
"The page you've requested returned this error:
Bad path '/'

9) Go back to the Files section.
10) Click the "Delete" link next to that file.

Observe the File Name: field is empty

11) Click the "Delete File" button.

Observe the above described error page.

12) Return to the Files section.
13) Click the "Cut" link next to that file

Observe that the file moves to the "clipboard".

I don't (yet) know what happens when you leave it there, but I think that's enough dysfunction for this question.

I implore Yahoo to get someone competent to review the changes made to the presentation code for Yahoo Groups, and correct the underlying problem rather than continuing to treat the dysfunctions in a piecemeal fashion. Perhaps this blog post will help you find the tools you need:



Misinterpretation of < character in Messages fixed, almost.



I noticed one night that a message of mine which had demonstrated the bug in Yahoo Groups Messages sections appeared to be fixed. But then I got this in the Digest next morning:

Screen shot:

The original message (quoted in the digest message shown) demonstrated the bug where the < character was being misinterpreted as the lead-in for an HTML element. This is in a group, yahoo_group_of_groups, which excludes attachments -- and therefore all message bodies are (supposed to be) plain text only.

A question reporting that bug was on my list to be documented with step by step instructions, but now that's (mostly) mooted. If it would help, I can create a step-by-step to demonstrate this bug in the Digest messages.


Also similar problems in Individual messages, when Fully Formatted.
Screen shots:





Misinterpretation of apostrophe in Messages chrome?



The user's profile display name can contain apostrophes, this now causes a mistake in the display of the display name in the Messages section of Yahoo Groups.

I'll bet other "special" characters (characters that require escapement when displayed from user-supplied text) can cause similar hilarity.

Screen shot:




Answers is not immune to double escaping

(Not separately reported)


Once you start seeing these things, you find them everywhere! This minor malfunction spotted in an email notification from Yahoo! Answers.


In this case, it was probably the truncation of the message at a certain character count that broke what was likely to have been ' -- the numeric character reference for an apostrophe.


Screen shot:



Comments (0)

You don't have permission to comment on this page.