Skip to content
This repository has been archived by the owner on Jan 24, 2023. It is now read-only.

re: Skynet & MySky Security Fixes - 05/08/2021 #89

Open
dghelm opened this issue May 8, 2021 · 3 comments
Open

re: Skynet & MySky Security Fixes - 05/08/2021 #89

dghelm opened this issue May 8, 2021 · 3 comments
Assignees

Comments

@dghelm
Copy link
Contributor

dghelm commented May 8, 2021

Yesterday, David made an announcement on Discord:

As we were doing final checks before fully launching MySky and the leaderboard, we realized that there were a handful of security issues which may break compatibility with existing skapps. We tried our best to patch things together, but ultimately decided that the best course of action is to delay the launch until Wednesday. We believe that MySky is the future of the Internet, and we really want to make sure that things are done correctly. This security change impacts user seeds, and all existing MySky seeds will break / need to be changed once the fix is deployed.

If you are a dev building with MySky, we will have a follow-up announcement in #app-dev later today, explaining how you can test your app against the changes and make sure that everything still works. For most devs, the update will not break your code.

This document will cover how to test your app against the Skynet and MySky changes we'll be releasing Wednesday, May 12th.

If any of these steps break, you should reach out on Discord, either in the #app-dev channel or by DMing dghelm#8125.

What am I testing for?

We're seeing two major changes on May 12th.

  1. Portals will disable access to Skynet API endpoints from subdomained Skynet URLs. This means you cannot access skapp.hns.siasky.net/skynet/*, skapp.hns.siasky.net/[skylink] or [base32Skylink].siasky.net/[notFileInUploadedDir].
    These changes protect against a vulnerability that could let a malicious app extract a user's MySky or SkyID seed.
  2. MySky will change how it internally handles seeds and userIDs. You should not need to make changes in your code, but data attached to old seeds will become 'read-only' after the switch.
    These changes will secure and protect user MySky seeds moving forward.

Test for MySky Change

The MySky app available on siasky.dev is the version we plan to release into production on Wednesday. It should work without code changes, but you'll want to test your app.

  1. Access your app through siasky.dev (using a URL like https://snew.hns.siasky.dev)
  2. Launch MySky and check URL in the address bar -- if it says siasky.net instead of .dev, you have hardcoded the portal in your app. This needs to be fixed.
  3. Login with MySky, and test things out.

Fixing a hardcoded portal URL

Your app should not make any requests to siasky.net when accessed through siasky.dev -- it breaks the decentralization of Skynet for your users.

Commonly, this happens because you've hardcoded a portal URL in your code. The most common reason this happens is not changing

const client = new SkynetClient('https://siasky.net');

to

const client = new SkynetClient();

before deploying your app to Skynet.

You can also use the Browser Console technique described below to confirm that no requests are being sent to siasky.net

Test for API Endpoint Change

This test may be trickier, as you'll want to look at the requests your browser is making to Skynet.

  1. Access your app through siasky.dev (like https://snew.hns.siasky.dev)
  2. Press F12 to open your Browser's Developer Console. Then click the "Network" tab.
  3. Do something that interacts with Skynet beyond the initial page load. Examine the request URL.
    1. First, no requests should point to siasky.net. If any request does, see "Fixing a hardcoded portal URL" section above.
    2. No requests should go to yourapp.siasky.dev/[skylink] or .../skynet/registry -- these requests will fail when made on siasky.dev. See this image for an example.

Fixing subdomained access

Three scenarios might cause requests to be pointed to API endpoints at a subdomained URL:

  1. You're loading a Skynet library by using <script> tags with a relative URL. For example, SkyID's recommended loading method will no longer be compatible with Skynet:
<script src="/hns/sky-id/skyid.js"></script>

Instead, you should do one of the following:

  • link to an immutable Skylink
  • detect your current portal then build and load the appropriate HNS url
  • build the JS library into your project
  • temporarily use a hard-coded portal URL for the JS file in the script tag as a short-term fix.
  1. You're using an older (even if production) version of skynet-js. Update to the latest beta using npm install skynet-js@beta and take a look at the Upgrade Guide and CHANGELOG-BETA for details on recent breaking changes. Yes, you're being forced to use a beta -- we're sorry and will have a stable release soon.

  2. You're using SkyID, which currently is not compatible with the upcoming changes to Skynet.

@dghelm
Copy link
Contributor Author

dghelm commented May 12, 2021

In addition to these changes, full skyfile metadata is no longer being returned in the header information for each skyfile request. We've exposed a new API endpoint and the fix has been incorporated into skynet-js 4.0.6-beta.

@dghelm
Copy link
Contributor Author

dghelm commented May 13, 2021

Changes are now live on both MySky and siasky.net.

@mrcnski
Copy link
Contributor

mrcnski commented Jun 25, 2021

@dghelm Can this be closed now?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants