 |
lua-l archive |
|
|
||
|
The wiki always escaped page content, that wasn't the XSS issue.However while fixing the edit breakage, I noticed an undocumented feature where page content was supporting entity refs like "<". This caused confusion-- for example source code about HTML encoding would incorrectly have the literal string "<" displayed as "<". So I disabled entity ref support and manually removed entity refs where appropriate.Removing the entity refs could not be done automatically, since it depends on context. For example, a script would not know when "<" is intended literally-- as in the source code case-- or when it was intended to be displayed as "<".On Wed, Jun 3, 2020 at 3:01 AM Philippe Verdy <verdyp@gmail.com> wrote:I flly understand that you needed to fix the XSS issue (because before that anyone could post dangerous HTML and random _javascript_s that could steal data from the user visiting the page, including perfoming automated "tracking" requests with other remote rogue server), but this caused existing pages to become broken when reedited later.Of course we should not need to use HTML-encoding with character entities to edit pages (this can be invisible in the text editor so we can freely type "<" inside the input form), but then when saving, these dangerous "<" characters must be inoccuited by transforming them internally into "&" everywhere (this transform can be safely inverted in the page editor when relaoding the page)When loading an existing page that still contains dangerous "<" characters, they can be loaded in the input form "as is", but when saving they will be translate internally into "&".Your database should then no longer contain any page containing unencoded "<" characters: a bot could load all pages and save them with this transform, which should not even need to be tracked in the page history if these legacy uses had no dangerous effect, such as no "<meta>" element with dangerous href values, no dangeous "<img>" tags, no on[eventname]="..." scripted attributes.Le mar. 2 juin 2020 à 12:15, John Belmonte <john@neggie.net> a écrit :Indeed, I made a patch for an XSS issue recently and broke page edits. The site is now informally locked until I've worked it out.Regards,--JohnOn Mon, Jun 1, 2020 at 8:35 PM Philippe Verdy <verdyp@gmail.com> wrote:Note: this bug affects ANY page that currently contains some '<' including many Lua sample code between {{{triple braces}}}.The page is parsed when saving, anything that looks like a possible HTML tag will cause an exception where the whole text is lost. Then ALL HTML-escapes like "<" or numeric character entities are converted to plain-text literal characters (not generating any HTML). The wiki then stores and displays the result of this parsing.Something changed recently on the code implementing the wiki, which caused incompatible behavior.A very large number of wiki pages are affected by this new bug. Be careful. The wiki implementation has a serious bug, at least it should not allow saving the page if there are '<' but should inform the user that he must fix the content, or the wiki should first HTML-encode any "&" found anywhere into "&", and then any "<" found anywhere into "<"Visibly the HTML-escaping of the input text was removed or forgotten in the new implementation!Le lun. 1 juin 2020 à 07:35, Philippe Verdy <verdyp@gmail.com> a écrit :I identified the bug. Any wiki page where there's a single '<' character inside will be blanked entirely when saving.The source page can be restored by first converting each of them to '<'Le lun. 1 juin 2020 à 07:19, Robert Burke <sharpobject@gmail.com> a écrit :On Mon, Jun 1, 2020 at 8:25 AM Philippe Verdy <verdyp@gmail.com> wrote:
>
> Editing any page on the lua.org wiki has a severa bug:
> you can edit a page, add a single character, post legitimate comment, but when saving all the text is cleared.
> Looking at the diff, you cannot even restore its content (reload the old version, don't change anythin, try saving, the saved page is blank again (nothing is restored)!
>
It looks like it works to me: http://lua-users.org/wiki/TestPage