Thoughts That Sprung To Mind Around Security and Abuse

[Grunet]

Your issue

Thoughts That Sprung To Mind Around Security and Abuse

Want to preface by emphasizing I think this is a super neat idea that could be super beneficial to the community, and to thank everyone involved for their work on it.

When I was trying to wrap my head around what it was, I had a few thoughts spring to mind around security and abuse scenarios. I wanted to share them just to get them out of my head and better understand if they're actually pointing to anything.

Malicious Actor Posing as Someone Else

If someone malicious submits a request to join, maybe posing as someone else in the community and using their website but with a tiny difference that's hard to spot (like 1 letter off in the domain name, or other standard email phishing sort of techniques) that looks exactly like that person's actual website, it seems like they might be able to sneak in and then phish users of the webring.

Rough Idea to Combat Malicious Actor Posing as Someone Else

Add a out-of-band validation step to make sure the person is who they say they are (e.g. reaching out on one of the socials they offer. Presumably that's harder to manufacture replicas of? Not sure)

Link Destinations Being Masked are Challenging

Similar to the email phishing analogy above, it seems like it'd be hard for a user to safely evaluate whether or not to follow a previous/next/random link since you can't easily tell where it's going to take you or if it might be a malicious site.

Even with no malicious sites in the webring, there's also the concern of the webring's backend getting compromised and a malicious actor taking control of the redirection (e.g. for phishing) without anyone noticing.

Rough Idea to Combat Link Destinations Being Masked are Challenging

If there's some kind of independent way from the backend resource to monitor the redirects that are occurring (e.g. via gateway access logs) presumably it'd be possible to detect if something is going awry with them

Code of conduct

• I agree to follow this project's code of conduct

[ericwbailey]

Hey @Grunet, thanks for raising this issue! Security and abuse are things I take seriously.

To answer your issue points:

If someone malicious submits a request to join, maybe posing as someone else in the community and using their website but with a tiny difference that's hard to spot[…]

Add a out-of-band validation step to make sure the person is who they say they are

I touch on this a bit in #30. Right now the out-of-band validation is me, in that approval is a completely manual step, and I review both the person submitting, and the URLs they provide.

Participation in the webring requires trust in me, but I view this as no different than trust in:

• Clicking a link presented in context that has a non-human readable (post slugs) or obfuscated URL (link shorteners).
• Participating in open source projects that have transparent code and processes.

I also hope my reputation in the community can do some of the lifting here, as well as (hopefully) a groundswell of trust from having many participants who have non-malicious content.

Even with no malicious sites in the webring, there's also the concern of the webring's backend getting compromised and a malicious actor taking control of the redirection (e.g. for phishing) without anyone noticing.

This is something I took a lot of time researching to ensure the attack surface area was as minimal as possible. To that point, here are potential vectors and what I'm doing about them:

• The webring code is hosted on GitHub
  • The webring code itself, including the redirect logic, is publicly viewable.
  • The dependencies are extremely minimal, and are monitored and reported by automation.
  • The dependencies are all server-side rendered and not exposed to the client.
  • My GitHub account is secured via a unique password, and two forms of multifactor authentication. Of the two, one is a physical hardware key.
  • As I am a GitHub employee, my sessions are managed and I need to re-authenticate multiple times per day.
• The code is deployed to Netlify
  • Netlify handles redirects via its functions capability, meaning it is server side.
  • My Netlify account is secured via a unique password and multifactor authentication.
  • All traffic to and from Netlify is via HTTPS, meaning there is a very small chance it can be intercepted without a targeted and sophisticated hacking attempt.
  • Short of the redirect functions, the content is all static, so the sensitive information surface area is next to none (client requests URL).
  • The webring widget contains no client side JavaScript that can be exploited, just HTML. This was a very intentional design decision, including choosing not to make it a web component.
• The email address I use for logins
  • Is Gmail, which while a large target is also supported by Google-level engineering talent.
  • Uses a unique password.
  • Uses multifactor authentication.

As for the content itself on other sites, that is out of my hands. We have run into similar situations with The A11Y Project, through both public and private reports, where resource content points to sites that have been compromised (usually for porn or crypto scams).

For this situation, the link is updated or removed. If this situation were to happen with the webring, deleting the offending site from our memebers.json file should be enough to remove it from the webring. While I cannot control the use of our webring code, its removal means visitors can only navigate away from the offending site, and will no longer be navigated towards it.

Additionally, the webring updates on pull request merge thanks to Netlify. This means the moment the site is removed from GitHub, the redirect is removed from the live site. In this situation, the only chance of a compromised site being visited is someone directly clicking on a member entry link from a browser session that hasn't been refreshed—the Netlify functions for previous, random, and next sites in the webring will no longer point folks to the removed site.

In summary:

• The accounts used are minimal and all have both unique passwords and multifactor authentication,
• The code is open for public evaluation,
• The content is transmitted via HTTPS
• There is no client-side scripting, and
• All proposed content is evaluated by a human (me).

If there's some kind of independent way from the backend resource to monitor the redirects that are occurring (e.g. via gateway access logs) presumably it'd be possible to detect if something is going awry with them

I like this idea! I'm unsure how we could detect a change in content to something unsavory, but it would be good for at least catching 404s. Do you know of any resources I could investigate in this space?

And two more questions for you, if you don't mind:

1. Do you think it'd be worthwhile to set up a SECURITY.md file in this repo that addresses some of these concerns?
2. Do you think we should restrict submissions to only sites that use HTTPS?

[Grunet]

Cool beans, I had a feeling you'd already thought through this (given everything lol) I just couldn't find a discussion of it. Really really thorough analysis and setup! Very nice job

1. Do you think it'd be worthwhile to set up a `SECURITY.md` file in this repo that addresses some of these concerns?

On that note, yeah if it's not too much trouble I think a security.md with some of this info would be great! Well for any strangers like myself at least lol. Not a huge deal though with this issue conversation now in existence.

Supply chain security is the only thing that still comes to mind after reading through it. Like I think I follow that the netlify CLI in the package-lock.json is what's used to deploy the edge function (or something like that?) but I'm not exactly sure where that happens from (one risk being if it happens from an "unclean" place like someone's local computer that could be compromised, the deploy could get infected too. Something like this led to the recent CircleCI breach over the holidays as I understand).

No need to automate it really, but always nice to do it from someplace "clean" (like a Github Codespace) if possible, especially if any sensitive environment variables (or similar) need to be used.

EDIT: Actually never mind I think I understand now the Netlify-to-Github integration probably extends to the edge functions and the CLI is only for local testing (or something?) which obviates the above!

2. Do you think we should restrict submissions to only sites that use HTTPS?

It definitely can't hurt from a security and privacy perspective to restrict to HTTPS I think, or I guess at least ask if there are any really hard blockers preventing someone from using it? I'm not super familiar with what Certificate Authorities do and don't work nicely with various platforms.

I like this idea! I'm unsure how we could detect a change in content to something unsavory, but it would be good for at least catching 404s. Do you know of any resources I could investigate in this space?

I'm not seeing anything around Netlify edge functions from some light googling (which I guess makes sense since any gateway would be fully managed by Netlify?). You're already emitting app-level logs with the redirects (nice!) but yeah idk if there's anything else to be done (for reference I was thinking of something like an AWS or GCP managed load balancer that records a log for every request that comes in and out of them, independent of the backend behind them. But even they might not capture header info by default now that I try to remember)

As for 404s, I haven't seen yet how the Netlify edge function could return one (though I might have missed something?). In terms of detecting if the page being redirected to is 404-ing, I'm not sure if this is possible without directly requesting the page from the edge function before trying to redirect to it (or like doing this on a scheduled cadence or something). Maybe it is, though it seems like that would be odd.

*Also disclaimer I don't even have a personal site to join with at the moment so take my initial thoughts and all of this with that huge grain of salt lol

[ericwbailey]

On that note, yeah if it's not too much trouble I think a security.md with some of this info would be great! Well for any strangers like myself at least lol. Not a huge deal though with this issue conversation now in existence.

Will do!

It definitely can't hurt from a security and privacy perspective to restrict to HTTPS I think, or I guess at least ask if there are any really hard blockers preventing someone from using it? I'm not super familiar with what Certificate Authorities do and don't work nicely with various platforms.

HTTPS was notoriously difficult to set up before Let’s Encrypt, but it is pretty turnkey nowadays for most services. I can add that to the evaluation criteria.

No need to automate it really, but always nice to do it from someplace "clean" (like a Github Codespace) if possible, especially if any sensitive environment variables (or similar) need to be used.

EDIT: Actually never mind I think I understand now the Netlify-to-Github integration probably extends to the edge functions and the CLI is only for local testing (or something?) which obviates the above!

I used Codespaces to develop this! And yep, the the CLI stuff is only for local development (proxied if a Codespace is used).

As for 404s, I haven't seen yet how the Netlify edge function could return one (though I might have missed something?). In terms of detecting […]

Check out #40! It's not ready to be merged yet, but it will identify anything outside the 2xx range of responses 👀