I'll look into updating the Liquipedia extension next week, thanks for the ping.

I've pulled this onto our wiki and as far as I can see it, it should be fine now. Again thank you for working on this :)

No worries, sometimes things take time, and that's ok. Thank you for your work on this :)

I added a call to error_log() like so

At least in Firefox I am still seeing it. I've been wondering if I had a cached version of some script, but I've tried this on multiple PCs now

This change has broken compatibility with MediaWiki 1.31

[82208d4b3c9721c73b0185b9] /smash/Special:RunQuery/Match_history OOUI\Exception from line 31 of /path/to/wiki/vendor/oojs/oojs-ui/php/Theme.php: OOUI\Theme::singleton was called with no singleton theme set.

I pulled this version, but I can still recreate this with this url https://liquipedia.net/commons/Special:RunQuery/Find_images?pfRunQueryFormName=Find+images&Find+images[person]=%3Cimg%20src=%22x%22%20onerror=%22alert(1)%22%3E&Find+images[event]=&Find+images[date][day]=&Find+images[date][month]=&Find+images[date][year]=&Find+images[description]=&pf_free_text=&wpRunQuery=Run+query# (I use the git version now at 4ac1f9d4371974c823225da7273ddf2ce9b89dfd)

In T259433#6406933, @sbassett wrote:

The liquipedia.net issue appears related to a fork of ext.pf.select2.tokens.js on their end, as it does not ever appear to be a part of PageForms' git history

As far as I can see, there is still an issue here, as I can still create URL parameters that are XSS exploitable

Hmm yeah I wanted to patch in a full replace there, but forgot that JavaScript does not replace all occurrences without using a regex.

This wiki uses MW 1.31.8 and PF 4.9.5, but I can still get an alert from a URL parameter. Maybe I am missing something?

I'm back, because I realized that your fix works in 1.34, but does not seem to work in 1.31.8.

When going to https://sandbox.semantic-mediawiki.org/wiki/Sp%C3%A9cial:RunQuery/Tokens and putting <img/src=="x onerror=alert(1)//"> into the box, the code also gets executed.

Thank you for working on this. The patch you merged seems to fix the issue with passing it in as a url parameter, it seems to leave open the option of self XSS-ing by putting the string into the search box though. I don't know if this is something that is important to fix, but it mightbe nice.

The reason why I added Core is that there is no way to hook into this behaviour for all I could see in the relevant file, but I trust you to know what kind of tags are relevant.

Ah thanks so much, I've spent too long looking at this so i guess I missed that T_T

Yeah, the fact that it doesn't happen everytime is why i titled it as possible race condition. I don't use an adblocker/scriptblocker myself, so I can only speak about a non-adblocker state.

Well, that line that i linked is the one the chrome developer tools gighlight for me as to where $.debounce is not a function.