Wikipedia's 21st birthday is a month from today (January 15, 2022). Is that what you mean by "Wikipedia Birthday 2022"?

Whose we? What's the purpose of the task?

Forgive me. We as in Brand Studio.

Yes. We would like to launch the landing page on Jan 15 2022 to celebrate Wikipedia's birthday.

I'm submitting this to your team for analysis because this application will be hosted on Wikimedia's server, so I need an Application Security Review.

Thank you!

Right. You haven't submitted this to any team. You've created a poorly wrote task with no tags. I'm going to closed this as invalid. Please follow https://www.mediawiki.org/wiki/Security/SOP/Application_Security_Reviews

In T297816#7573411, @MSRamos wrote:

Yes. We would like to launch the landing page on Jan 15 2022 to celebrate Wikipedia's birthday.

That's soon! Have you talked to people in SRE, Traffic or Security about this? There is also a code freeze soon that would further complicate this.

I'm submitting this to your team for analysis because this application will be hosted on Wikimedia's server, so I need an Application Security Review.

It's correct that a security review is needed before code can go into production. You should tag the security team, let me do that for you. Be aware though there is also a turnaround time for such a review and we are close to the holidays. You might also want to reach out directly to the security team about this.

That being said there are other questions here that would have to be answered and other changes to be made by SRE / Traffic before this can be hosted on production servers. This kind of request has a couple moving parts and can't be done by just one person clicking in a UI. One of the first questions would be what is the URL you are expecting to host this site under?

Ideally please reach out to management in Traffic and Serviceops to prioritze this.

Hi. I'm already in contact with the security team and have already received a Privacy Engineering review because I was told that this would be a necessary first step before getting an Application Security review. So, no, the assessment made before, when this tasked was closed, that this wasn't submitted to any team is incorrect. The team is aware of this incoming task.

This is the URL the Brand Studio is proposing: www.wikimediafoundation.org/mywikibirthday

So, no, the assessment made before, when this tasked was closed, that this wasn't submitted to any team is incorrect

How is anyone on Phabricator supposed to know that? Not one tag was present on it and very little information was in the description.

I was under the impression that the Application Security team had received a heads-up regarding the project. As for tags, this being my first time submitting any task on Phabricator, I was not aware of the importance of them in the first place. Now I do.

Hey @MSRamos -

Yes, the Security-Team did get a heads up about this. Typically we follow this process (and provide the details required by the Phabricator intake form) for making such requests, but I understand it's the first time you've ever done this :) It looks like the tags added by @Dzahn should get this into our application security review queue. If you could make a pass at updating the template text on this task (once I add it), that would be great. I'll second that January 15th, 2022 will be a tough timeline for review and deployment. I think we can likely accommodate an application security review by then, but deployment is definitely another matter.

Hi @MSRamos,

so there really is more to this than just the security review.

One thing for example is the following 2 statements are in conflict with each other:

This is the URL the Brand Studio is proposing: www.wikimediafoundation.org/mywikibirthday
this application will be hosted on Wikimedia's server

wikimediafoundation.org is not running on WIkimedia's servers. That is hosted by Automattic (Wordpress VIP). If that is the case and you do not want to suggest any hosting or redirects from any wikimedia.org or wikipedia.org domain then it changes the entire process and who you need to talk to.

In T297816#7573659, @Dzahn wrote:

wikimediafoundation.org is not running on WIkimedia's servers. That is hosted by Automattic (Wordpress VIP). If that is the case and you do not want to suggest any hosting or redirects from any wikimedia.org or wikipedia.org domain then it changes the entire process and who you need to talk to.

I believe they may have meant wikimedia.org/mywikibirthday. Or at least that's what I was initially informed would be the case. Whether that's merely a redirect to a wikimediafoundation.org page or to some other location, I'm not sure.

Ok, thank you @sbassett. (This is a good example why this kind of thing needs clarification and planning early. If it's about wikimedia.org that means it is still true what I said before about needing involvement from SRE.

A personal comment on the suggested name would be how this would be specific to just the 22nd birthday. Wondering what happens for the 23rd and 24th birthday. Is there an expectation of a permanent site for birthdays that always exists but has new content every year? is there a place where we can read about the plan?

@sbassett @Dzahn The landing page will live on wikimediafoundation.org, like our 20th Birthday Landing Page did: https://wikimediafoundation.org/wikipedia20/

In T297816#7573717, @MSRamos wrote:

@sbassett @Dzahn The landing page will live on wikimediafoundation.org, like our 20th Birthday Landing Page did: https://wikimediafoundation.org/wikipedia20/

Ah, ok. If there are no implications for the wikimedia.org domain, then this is definitely a bit less of a concern, both for the application security review and any deployments.

@sbassett Correct! It lives under our Corp website umbrella. Happy to clarify if any other questions arise! (Which I'm sure they will)

@MSRamos Thank you for the clarification! Yes, as Scott said this makes this a bit less of a concern. You can then mostly ignore my previous comments about having to talk to SRE etc :) Instead you should be able to get this all done by contacting people within comms department directly. Let's just confirm there is no additional part such as "please also redirect something under wikipedia.org over to this page". And also happy to clarify questions if you have any. Cheers

removing Traffic and SRE, keeping on "serviceops-radar" so will have an eye on it.

@Varnent cc'ing you just in case, added wikimediafoundation.org tag because it is about that. of course please correct me if wrong

@RhinosF1: Could we be a bit more lenient, please? Thanks.

Hi, all! Happy new year. Wondering if there are any updates or concerns for the launch next week. Thank you!

In T297816#7600123, @MSRamos wrote:

Hi, all! Happy new year. Wondering if there are any updates or concerns for the launch next week. Thank you!

So 1/15 is a Saturday - is the intended launch date before then? We technically haven't assigned this task yet, since our quarterly review planning meeting will be early next week. Given that this won't be hosted in Wikimedia production, I think it should be fine to perform a post-launch review of sorts, and work through any issues shortly after launch.

Hi! Yes. The intended launch date is 1/14.
I think that works, too. I already spoke with @Varnent and that seems reasonable.
Thank you so much for all your help! Let me know if there's anything else I can/should do.

@sbassett Thank you for your update. I already messaged the vendor and will let you know what they say regarding changes to the code.

@sbassett here's the response I've received from our vendor:
"In response to your earlier question about the JS script changing;
The JS code did not change for the search and the results page. We are unsure if the JS code needs to be tweaked when we fix the bugs on the collage page but we will be sure to have the security team vet it if we need to update the JS code in phase 2."
Since we probably won't be moving forward with the collage, I believe there won't be any new issue with the JS. Let me know if this helps! Thank you.

Security Review Summary - T297816 - 2022-01-14
Last commit reviewed: ed580369dbf4a8248e4a6d97299fde2bf5815fff

Overall, the Birthday Buddy app/lib looks to be in good shape as an external dependency. And while it doesn't satisfy several of our (and scorecards') standard criteria for overall quality and safety of third-party/vendor code, no major issues were found while running several static analysis tools against the repo and performing a bit of manual pentesting against the demo site, and the overall risk rating is determined to be: low.

General Security Information

Vulnerable Packages - Production

None found via npm audit, snyk or auditjs, risk: low.

I would note, however, that the html2canvas dependency appears to accept release-candidate versions within package.json, which isn't great.

Vulnerable Packages - Development

Overall risk for these dependencies is medium.

Outdated Packages

As reported via npm outdated:

(no explicit vulnerabilities reported, simply noting for completeness' sake.)

Static Analysis Findings

1. lockfile-lint 4.6.2 returned no results. low risk
2. git secrets, as run with default AWS patterns and rudimentary secret keyword rule sets, returned only false positives. low risk
3. gitleaks returned no results. low risk
4. whispers 1.5.3 returned only MINOR, non-issue results. low risk
5. scan scan:latest returned no results. low risk
6. semgrep 0.75.0 which was run with the following rule sets:
   1. p/javascript: This policy returned one false positive. low risk
   2. p/typescript: This policy returned no results. low risk
   3. p/nodejscan: This policy returned no results. low risk
   4. p/nodejs: This policy returned a few the same issues related to fs method calls that the p/gitlab-eslint policy below found. It also took issue with the spawn method call setting shell: true within rollup.config.js. But since that is simply used to build the project via rollupjs, it is a false positive within this context. low risk
   5. r/generic.unicode.security.bidi.contains-bidirectional-characters: bidi/trojan source detection, no results found. low risk
   6. p/secrets This policy returned no results. low risk
   7. p/ci: This policy returned no results. low risk
   8. p/security-audit: This policy returned no results. low risk
   9. p/xss: low risk
   10. p/supply-chain: This policy returned no results. low risk
   11. p/owsap-top-ten: This policy returned no results. low risk
   12. p/gitlab-eslint: This policy found some false positives in various fs methods which took dynamic arguments within the scripts/setupTypeScript.js helper script. low risk
   13. p/eslint-plugin-security: This policy returned no results. low risk
   14. p/python: This policy returned no results. low risk
7. ossf scorecards (via their docker image) found a score of 4.5/10 for birthday-buddies/main. Since this falls within the middle-ish of their defined range, I'm going to rate it as a medium risk, with the obvious caveat that there are several limitations with tools like these. However such tools cover similar checks (and provide another lens of analysis) to the Security-Team's existing third party code review checklist.

Manual Pentesting
I performed a small amount of manual pentesting against the provided demo site, largely in the way of submitting various blind XSS payloads through the two primary form inputs. I was not able to find any valid exploits, which makes sense, as there aren't really any obvious ways to directly interact with the DOM via said form inputs.