Prior work in this space: T335892#9936225. The various TPR rules could easily be modified to find http leaks, etc. within Wikimedia codebases.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| In Progress | None | T371814 [EPIC] Universal Security Dashboard | |||
| Declined | mmartorana | T342468 Craft more mediawiki-specific and php semgrep rule sets |
Event Timeline
Comment Actions
@sbassett: Hi, the Due Date set for this open task passed a while ago.
Could you please either update or reset the Due Date (by clicking ), or set the status of this task to resolved in case this task is done? Thanks!
Comment Actions
@sbassett: Hi, the Due Date set for this open task passed a while ago.
Could you please either update or reset the Due Date (by clicking ), or set the status of this task to resolved in case this task is done? Thanks!
Comment Actions
To split this up (discussion between me and @sbassett)
- Research the existing PHP rulesets that are in semgrep - default rules
- Research historical vulnerabilities and what would be a good candidate for a new rule - e.g. message API (but in general there's a lot of good coverage there, but would be good to find these issues earlier), permissions layer (however this might be tricky), csrf
- Review the rules we already contracted semgrep to write - semgrep functions that are potentially ones that can be used incorrect - can we refine which ones are most effective and less false positives, or use as inspiration for more? https://gitlab.wikimedia.org/repos/security/wikimedia-semgrep-rules especially https://gitlab.wikimedia.org/repos/security/wikimedia-semgrep-rules/-/blob/main/php/mw-php-sec-sniff.yaml
Comment Actions
Resetting task status from "In Progress" to "Open" as this task has been "in progress" for more than one and a half years (see T380300).