Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Cannot redirect from /.well-known/security.txt #256

Open
alexbishop1 opened this issue Aug 4, 2021 · 11 comments
Open

Cannot redirect from /.well-known/security.txt #256

alexbishop1 opened this issue Aug 4, 2021 · 11 comments

Comments

@alexbishop1
Copy link

It appears to not be possible to make /.well-known/security.txt redirect to https://vdp.cabinetoffice.gov.uk/.well-known/security.txt in line with https://gds-way.cloudapps.digital/standards/vulnerability-disclosure.html.

Configuring a redirect in either the global configuration file or the config.rb file as described at https://tdt-documentation.london.cloudapps.digital/maintain_project/redirects/ results in requests to /.well-known/security.txt being responded to with a text/plain response containing raw HTML:

              <html>
                <head>
                  <link rel="canonical" href="https://vdp.cabinetoffice.gov.uk/.well-known/security.txt" />
                  <meta http-equiv=refresh content="0; url=https://vdp.cabinetoffice.gov.uk/.well-known/security.txt" />
                  <meta name="robots" content="noindex,follow" />
                  <meta http-equiv="cache-control" content="no-cache" />
                </head>
                <body>
                </body>
              </html>

This seems to be because Middleman performs redirects by serving HTML pages with meta refreshes but the .txt file extension causes the HTML to be served with a text/plain content type.

It’s probably possible to get this working by editing the nginx.conf file but this does not seem this is intended to be modified by users of the Tech Docs Template gem.

The alternative is to serve the security.txt file directly rather than redirecting but this causes a maintenance headache.

Since there may be lots of tech docs sites that wish to redirect to https://vdp.cabinetoffice.gov.uk/.well-known/security.txt it makes sense for the gem to support this.

It might even make sense for the gem to always redirect requests for /.well-known/security.txt to https://vdp.cabinetoffice.gov.uk/.well-known/security.txt because most security vulnerabilities would probably be in the gem itself rather than any specific tech docs site that uses it. (This assumes that security reports for the gem should go through the Cabinet Office CDIO Cyber Security vulnerability disclosure programme.)
@36degrees
Copy link
Contributor

36degrees commented Aug 13, 2021 •
edited
Loading

Unfortunately, because the tech docs projects are static sites (generated using middleman), the only thing that gets deployed is the generated HTML, CSS and JS.

There is no 'server' running that can set location headers on the response. This is why the current redirect logic generates HTML that includes a meta redirect – which as you've already flagged will only work for HTML files.

Because the exact hosting setup will vary from project to project, I think this would be out of scope for the tech docs gem / template. Whilst many tech docs instances might be serving their docs using nginx and might be able to use the nginx.conf included for PaaS deployments, this isn't guaranteed. For example, tech docs project could be deployed to GitHub Pages or another static site hosting solution like Netlify.

Unfortunately, I think this is something that needs to be implemented on a project-by-project basis.

@jamietanna jamietanna mentioned this issue Oct 28, 2021
Merged
@jamietanna
Copy link
Contributor

jamietanna commented Oct 28, 2021 •
edited
Loading

FYI I've managed to get this working by adding the following to config.rb:

def external_redirect(from, to)
  configure :development do
    page "/#{from}", content_type: "text/html"
    redirect from, to: to
  end

  redirect "#{from}.html", to: to
end

external_redirect("security.txt", "https://vdp.cabinetoffice.gov.uk/.well-known/security.txt")
external_redirect(".well-known/security.txt", "https://vdp.cabinetoffice.gov.uk/.well-known/security.txt")

This appears to work for some hosting providers, YMMV

(Via)

Note there's a better solution below

@m-green
Copy link
Contributor

m-green commented Oct 28, 2021

@alexbishop1 Do you think @jamietanna's solution above would work for GDS tech docs repos as a whole?

@jamietanna
Copy link
Contributor

I think @OllieJC's solution on co-cddo/api-catalogue#236 is better and I think it would be a good one to solve centrally if possible - it also works both locally and when deployed 🙌

@m-green
Copy link
Contributor

m-green commented Oct 28, 2021 •
edited
Loading

Ah thanks! Although I'm not sure if we could add it centrally - it seems to be a solution to a recommendation from the GDS Way, so we would potentially be imposing a GDS (or Cabinet Office?) security requirement on non-GDS organisations that use the TDT. Let me know if I've misunderstood though!

@jamietanna
Copy link
Contributor

Could it be the sort of thing that we set to be at least configurable, so we set a helper for it, and if a consumer sets in their config the security_txt_url, then we enable it?

@m-green
Copy link
Contributor

m-green commented Oct 29, 2021

Ah yep that sounds like a plan. We're lacking dedicated developers for the Tech Docs Templates unfortunately - is there any chance you'd be able to create a PR? I can also ask a tech writer to work with you on the documentation for the configuration.

@jamietanna
Copy link
Contributor

I certainly can.

As an aside @arnau has mentioned that this could be an accessibility issue, as it's performed using a non-HTTP redirect, so we may need to highlight this as a problem for use of at least GitHub Pages.

@m-green
Copy link
Contributor

m-green commented Oct 29, 2021 •
edited
Loading

Ah that's good to know. I think we probably shouldn't implement this if it's going to cause an accessibility issue. We've recently completed work to make the TDT fully accessible, so we'll need to avoid knowingly making the TDT inaccessible again.

@arnau
Copy link

arnau commented Oct 29, 2021

It used to be an issue but would be better to check with accessibility experts just in case I'm wrong :)

@m-green
Copy link
Contributor

m-green commented Oct 29, 2021 •
edited
Loading

Ah gotcha @arnau - in that case it sounds like we can can ask an accessibility expert to review the PR when it's ready. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@arnau @36degrees @jamietanna @m-green @alexbishop1