Brian, The JSPWiki plugin environment does foresee some helper functions to help sanitizing the output of a plugin. But it is mostly up to the plugin (and the plugin author) to be cautious about the rendered html. Especially if the plugin is composing the html by means of string handling.
Eg. With the TableOfContents plugin has a title parameter which get's rendered as an h4 in the plugin's output; it is up to the Plugin writer to make sure the TextUtil.replaceEntities(title) is called so malicious <script>'s cannot survive. However if the plugin would be using eg jdom2 to render the output html, chances are that there is less to worry about. Br, dirk On Tue, May 21, 2019 at 9:03 PM Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi Brian, > > the vulnerability involved some plugins' parameters not being sanitized > before being used verbatim on the returned String, > which could end up causing an XSS vulnerability. We did not sanitize them > through plugin manager, so if your plugin uses > its parameters on the result String, without being sanitized, then it > should do it or you'll risk the same type of vulnerability > on your installation. > > I don't have the code in front of me right now so I can't tell if we can > built-in the sanitizing of plugins' parameters without > risking to break 3rd party plugins. I'll take a look at it, but in any case > I think the best advise is to sanitize your plugin's > input. > > Regarding 2.11.0.M4, attachment file names are now indexed, and with the > TikaSearchProvider contributed by Ulf Dittmer [#1], > if your photos contain enough metadata, then it'll get indexed too, so > they're probably a good fit for your PhotoCollectionPlugin :-) > > > best regards, > juan pablo > > [#1]: https://jspwiki-wiki.apache.org/Wiki.jsp?page=TikaSearchProvider > > > On Mon, May 20, 2019 at 1:55 AM Brian Burch <br...@pingtoo.com> wrote: > > > On 20/5/19 1:59 am, Juan Pablo Santos Rodríguez wrote: > > > Severity > > > Medium > > > > > > Vendor > > > The Apache Software Foundation > > > > > > Versions Affected > > > Apache JSPWiki up to 2.11.0.M3 > > > > > > Description > > > A carefully crafted plugin link invocation could trigger an XSS > > > vulnerability on Apache JSPWiki, which could lead to session > hijacking. > > > Initial reporting indicated ReferredPagesPlugin, but further analysis > > > showed that multiple plugins were vulnerable. > > > > > > Mitigation > > > Apache JSPWiki users should upgrade to 2.11.0.M4 or later. > > > > > > Credit > > > This issue was discovered RunningSnail. > > > > > > ref: https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2019-10078 > > > > > > > Hi Juan Pablo, > > > > I am slowly upgrading my PhotoCollectionPlugin to work under the current > > JSPWiki. Ironically, you keep moving the "goalposts" faster than I can > > "kick the ball"! > > > > I followed the announcement links, but they are circular and not very > > helpful. Obviously there should be a reluctance to assist potential > > exploiters target vulnerable wikis (I have two). > > > > To save me spending precious time trawling the source code changes, is > > it possible for you to answer my rather simple but important question:- > > > > Was the vulnerability found in the plugin invocation framework, or a > > result of developers like me cut-n-pasting an existing plugin when > > creating their new one? > > > > In other words, will my upgraded plugin be automatically protected, or > > should I examine my old and stable logic for this vulnerability? > > > > I hope this question can be answered quickly - I realise you have been > > very busy lately and must be looking forward to a well-earned rest. > > > > Best wishes, > > > > Brian > > >
