Create optional XSS filter step for the parser
Open, Needs TriagePublic


Modern extensions should use RL for all js (There's some legit exceptions, but none are used on publically-editable WMF wikis). Thus parser hooks should not output any inline scripts. Since the largest attack surface for XSS in MW is the parser, I think it might make sense as a defense-in-depth to check the parser output for script tags, javascript: href attributes, and onfoo event handler attributes.

Any blacklist probably won't be bulletproof, but combined with logging, might allow us early detection if someone found a hole but hasn't fully figured out how to exploit it, and also might increase the skill level someone needs to exploit a hole.

If we eventually use CSP, which blocks inline event handlers/javascript urls - this becomes important, as we can't block <script> with CSP as its impossible to distinguish legit loads of user js from someone exploiting an XSS to load a malicious user's js.

Bawolff created this task.Dec 8 2015, 11:54 PM
Bawolff updated the task description. (Show Details)
Bawolff raised the priority of this task from to Needs Triage.
Bawolff added a project: Security-Team.
Bawolff added a subscriber: Bawolff.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptDec 8 2015, 11:54 PM
csteipp added a subscriber: csteipp.Dec 9 2015, 5:11 PM

The general direction is interesting, and could be a nice control. I'm not sure how much protection we'll get vs the amount of work to implement and maintain, but certainly worth exploring.

<script> tags are certainly an obvious target, although it would be nice to also flag any potential javascript attributes as well. Maintaining either a blacklist or whitelist would take some work, but it's possible. Maybe we could reuse some of htmlpurifier's whitelist, and alert whenever we parse output that has content that isn't whitelisted?