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

Description

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?

Nirmos added a subscriber: Nirmos.Tue, Oct 16, 5:03 AM