https://bugzilla.wikimedia.org/show_bug.cgi?id=60629
--- Comment #2 from Philippe Verdy <verd...@wanadoo.fr> --- "Normal priority" ? Aa the Translate extnesion starts being used more widely, along with TNT and similar templates based on detetion of subpages trying to see if it is the source (untranslated) page or the translated subpage, we get cases were the source page to translate contains apostrophe-quotes. And then we get the HTTP 500 server error. Apostrophe-quotes or double quotes or ampersands are not uncommon in titles of pages, and these pages, on multilingual sites like MetaWiki or Commons, will cause such failure. It is also very easy to reproduce it, and within wikis that use a lot of utility templates to display various notice banners (which may be translated in the page's content language detected, #language will crash in those utility templates. IF these utility templates are widely used, a user may insert the malicious code with #template, and could cause LOTS of pages to generate HTTP 500. These templates will not be easily editable by users that have a preference to disply immediately a preview on the first edit. Most users visit the template page to view it alog with its "noinclude" documentation containing some examples of rendering of the template. Such visits will crash before the user can click on the "Edit" tab. Avanced users could also try eduting it by inserting the URL with the "?action=edit" parameter, but they will also fail if their user preferences include the preview on the first load of the editor. The crash may not be easy to detect where it occurs, because it will occur before hte page is fully expanded and the dependencies are computed and saved, the page will never be rendered or could only contain the outdated references to the previous state before the change in some deeply hidden sub-sub-template. May be the server could implement a crash handler for pages so that they are at least autocategorized: we could explore the list to determine which translcluded template or subpage containing #language with bad parameters causes the crash. The crash is so easy to reproduce that I fear that now it will be exploited to generate DoS attacks against servers constantly trying to recover from HTTP 500 crashes by relaunching new instances (with empty caches in memory, each crashes generates lots of IO on disk and on the database). -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
