Page MenuHomePhabricator

Set up automated/regular end-to-end testing of potential and past security issues
Open, Needs TriagePublicSecurity

Description

Suggested to me by @Bawolff, though I've expanded the scope.

We should have a script/bot that regularly tries to exploit potential security issues (e.g. anything related to media files, shelling out, etc.) and probably past ones for regression testing. I'd imagine this script lives in toolforge/wmcloud somewhere, runs regularly, firing off emails if something fails. Ideally it would not actually edit the wiki, instead using preview or other methods to avoid making public write actions.

E.g. for T257062 we could try to action=parse a malicious <score> block and see if it errors out. I'm sure there's a bunch of other things we could find going through past security issues or looking at places we've added preventative hardening measures.

Event Timeline

This task is not on any team's workboard and is access restricted (author, subscribers, and members of acl*security), so the chances that someone will find this task and work on this are low. Does this need to be access restricted?

Another case: T287542: API action=parse&prop=headhtml leaking user tokens and other private info in cross-origin requests (again)

This task is not on any team's workboard and is access restricted (author, subscribers, and members of acl*security), so the chances that someone will find this task and work on this are low. Does this need to be access restricted?

Not anymore, it's no longer a secret that Score has security issues.

Legoktm changed the visibility from "Custom Policy" to "Public (No Login Required)".Jul 28 2021, 12:23 AM
Legoktm changed the edit policy from "Custom Policy" to "All Users".