Add feature to manage plugins without using the command line

[BenSurgisonGDS]

See: Design and build a means to automatically install, upgrade, and uninstall a plugin with a push of a button

• Links in Plugins page changed to buttons for accessability
• No client-side javascript maintains previous functionality including instructions of how to install a plugin
• Additional client-side javascript asset:
  • initiate install via ajax and display processing panel
  • polls status of install until complete or failure
  • display appropriate confirmation or failure panel
  • account for user refreshing page after confirmation panel is displayed
• Server-side changes to initiate install mode via ajax and return status of install
• Make sure the above works for uninstall, and upgrade modes as well as install
• Add Acceptance tests to test all the above in Linux, Windows, and MacOS for both node 16 and 18
• Implement CSRF Protection
• Add warning and confirmation button if plugins install page linked from external site
• Add console logging to aid in debugging

[lfdebrux]

@BenSurgisonGDS thanks for the demo earlier, this is coming along well. I've been thinking a bit more about the security of this. I'm thinking about the fact that this feature lets the user install code onto their machine, and could be used by third parties to install code on to the users' machine.

At the moment, a user could click a link on an external website, and the kit would immediately start installing the plugin. The user may not necessarily know or expect that based on the text of the link, and would have no way to cancel the action if they weren't expecting or didn't want the change. I know that at the moment we have some protection because we only install packages from our list, but that might not stay the case in future, and it's generally better to be prudent now.

I’d like to see this feature to have the following restriction: if someone clicks a link to install a plugin from outside the kit, or types a URL into the browser, they will see an ‘are you sure?’ page to confirm (I think we can keep it so that if they click the existing button from the kit website they don’t see that page).

I think we can do this by a) requiring that a POST is made before the JavaScript kicks in and b) use some kind of CSRF mitigation to ensure the POST request is coming from the kit website (preferably the synchronizer token pattern) [1].

We should also have tests that check we can't install a plugin with a link without first getting user authorization.

[joelanman]

We just met about this, I think the outcome was it was easier to show everyone the page with the button on it, regardless of how they got there. I've added to the Figma:

https://www.figma.com/file/sWnqT4u4uup91TuTe9T3tp/GOV.UK-Prototype-Kit?node-id=325%3A68&t=fRtdngYlr08O97Mu-0

[joelanman]

found a tutorial to do csrf by hand, might be helpful:
https://levelup.gitconnected.com/how-to-implement-csrf-tokens-in-express-f867c9e95af0

[lfdebrux]

We've decided to go with the csurf package for our CSRF token middleware. Although it is deprecated [1], we could not find any well-supported alternative or single fork that has been chosen by the community (a large number of projects, including new projects, still rely on csurf).

Because the code is stable and has been for 3 years, and there are no known vulnerabilities that would affect our use case, the risk of using the deprecated library is in my opinion lower than the risk of picking an alternative or a fork that is more liable to change. There is possibly a greater risk of hijacking of the csurf npm package than of a well maintained package, however with the npm shrinkwrap mitigation we have in place (see #1654) that would be unlikely to affect our users.

An alternative would be to create our own fork of csurf, or our own alternative implementation; however we would then not benefit from the community scrutiny of our code that is a major benefit of using open source software, and we would have an additional maintenance burden that we do not want.

Note: there is a known vulnerability in the implementation of the double submit cookie pattern implementation in csurf [3], however as we are using cookie: false we are using the synchronization token pattern implementation [4], which is not vulnerable.

[BenSurgisonGDS]

@BenSurgisonGDS thanks for the demo earlier, this is coming along well. I've been thinking a bit more about the security of this. I'm thinking about the fact that this feature lets the user install code onto their machine, and could be used by third parties to install code on to the users' machine.

At the moment, a user could click a link on an external website, and the kit would immediately start installing the plugin. The user may not necessarily know or expect that based on the text of the link, and would have no way to cancel the action if they weren't expecting or didn't want the change. I know that at the moment we have some protection because we only install packages from our list, but that might not stay the case in future, and it's generally better to be prudent now.

I’d like to see this feature to have the following restriction: if someone clicks a link to install a plugin from outside the kit, or types a URL into the browser, they will see an ‘are you sure?’ page to confirm (I think we can keep it so that if they click the existing button from the kit website they don’t see that page).

I think we can do this by a) requiring that a POST is made before the JavaScript kicks in and b) use some kind of CSRF mitigation to ensure the POST request is coming from the kit website (preferably the synchronizer token pattern) [1].

We should also have tests that check we can't install a plugin with a link without first getting user authorization.

All the above now implemented.

[lfdebrux]

I think it would be preferable to use the hidden attribute instead of a CSS class, that way the page is more likely to look correct if the stylesheets haven't loaded or have been overridden for some reason.

Currently without stylesheets the page to install a plugin will read:

Install Step By Step from GOV.UK Prototype Kit

In terminal, press ctrl + c to stop your prototype, then run:

npm install @govuk-prototype-kit/step-by-step

When you've installed the plugin, restart your prototype in the terminal by typing:

npm run dev

Install
Installing ...
Install complete
There was a problem installing
[Please contact support](https://prototype-kit.service.gov.uk/docs/support)

[lfdebrux]

Ideally this page would work without CSS (in fact it does, if you click the button! You just can't tell from the browser...)

[BenSurgisonGDS]

The hidden attribute works when it ia done on a div so I have wrapped the confirmation button in a div to make it work with only the hidden attribute. Css is now unnecessary for this functionality.

[BenSurgisonGDS]

Fixed using the hidden attribute and some small markup changes

[joelanman]

Seems to be a problem in Safari on Mac, the process does not start automatically but instead shows the install button. Thats not a blocking issue so happy to raise it separately if you prefer.

[BenSurgisonGDS]

Seems to be a problem in Safari on Mac, the process does not start automatically but instead shows the install button. Thats not a blocking issue so happy to raise it separately if you prefer.

Yes, please raise separately.
Please see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Dest

[joelanman]

awesome! Great work all round