lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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 "&amp;" 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 "&amp;".

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 <> 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.


On Mon, Jun 1, 2020 at 8:35 PM Philippe Verdy <> 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 "&lt;" 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 "&amp;", and then any "<" found anywhere into "&lt;"
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 <> 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 '&lt;' 

Le lun. 1 juin 2020 à 07:19, Robert Burke <> a écrit :
On Mon, Jun 1, 2020 at 8:25 AM Philippe Verdy <> wrote:
> Editing any page on the 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: