如何为nginx（虚拟主机）找出一个合理的内容安全策略来源？
How to figure out a reasonable content security policy source for nginx (virtual hosts)?
我目前正在尝试了解更多关于 nginx 和作为网络服务器的给定安全性。我想象中的设置是带有 3 个虚拟主机的 nginx。这些主机中的每一个都是 运行 一个博客。
在学习了一些 nginx 强化教程之后，我确实发现自己陷入了那些 http-headers...如果我有多个虚拟机，我不确定通过 nginx 执行内容安全策略是否是正确的方法主机，这可能取决于来自不同站点的不同内容。
不过我目前的立场是弄清楚如何在每个 *-src 参数中为 nginx 设置一个合理的内容安全策略白名单。
既directive reference and source list reference也不
the latest content security policy level 3 确实回答了所有 *-src 的“最佳实践白名单”问题。
假设我对每个参数都设置了 'self'：
default-src:
如果设置为 'self'
，这是唯一有意义的参数
script-src, style-src, img-src, connect-src, font-src, child-src:
剩下的真是让我头疼。我怎么知道每一个好的来源？如果我将它们设置为 'self'，用户会始终收到 400 HTTP 错误吗？
正如我之前所说，我不确定通过 nginx 执行内容安全策略是否正确。如果我是 运行 拥有 5 个以上客户端的网络服务器，我将不可能知道这些客户端的每个“好”来源。我想再次指出，我只是想知道这些源参数。其他 HTTP-Headers（不仅是内容安全策略）对我来说很有意义，而且完全合理。
此致，
巨人
更新：经过更多研究
我确实在 Github 上找到了一个非常有用的 Repo。我将与大家分享。
简短说明：
Nginx 服务器配置是一个 collection 配置片段，可以帮助您的服务器提高网站的性能和安全性，同时确保资源以正确的方式提供 content-type 并且可以访问，如果需要，甚至 cross-domain.
Link 回购：https://github.com/h5bp/server-configs-nginx
但是我建议您阅读并了解每一个选项！
我仍然使用我自己的 CSP 政策，如下面的原始答案所示。我认为这些信息可能对 nginx 世界的任何初学者都有用。
我去研究了我的问题。目前，我的配置还不错，我将在本 post 的底部分享。
这个 Whosebug 问题实际上是一个很好的起点：How does Content Security Policy work?
我最后的立场是确保一切安全，如果任何用户获得 CSP - 错误，他们必须告诉服务器管理员他们想要向 CSP 添加另一个来源。如果来源看起来值得信赖，它将被添加，否则被拒绝（我可能会以某种方式自动执行该过程）。
如果有人对进一步的 SSL 配置感兴趣，您可以查看此 github 页面：https://gist.github.com/plentz/6737338
这是我的 nginx header 配置（根据 2019 年 7 月 22 日更新 headers - 见下文）：
# don't send the nginx version number in error pages and Server header
server_tokens off;
# config to don't allow the browser to render the page inside an frame or iframe
# and avoid clickjacking http://en.wikipedia.org/wiki/Clickjacking
# if you need to allow [i]frames, you can use SAMEORIGIN or even set an uri with ALLOW-FROM uri
# https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options
add_header X-Frame-Options SAMEORIGIN always;
# when serving user-supplied content, include a X-Content-Type-Options: nosniff header along with the Content-Type: header,
# to disable content-type sniffing on some browsers.
# https://www.owasp.org/index.php/List_of_useful_HTTP_headers
# currently suppoorted in IE > 8 http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
# http://msdn.microsoft.com/en-us/library/ie/gg622941(v=vs.85).aspx
# 'soon' on Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=471020
add_header X-Content-Type-Options nosniff always;
# This header enables the Cross-site scripting (XSS) filter built into most recent web browsers.
# It's usually enabled by default anyway, so the role of this header is to re-enable the filter for
# this particular website if it was disabled by the user.
# https://www.owasp.org/index.php/List_of_useful_HTTP_headers
add_header X-XSS-Protection "1; mode=block" always;
# with Content Security Policy (CSP) enabled(and a browser that supports it(http://caniuse.com/#feat=contentsecuritypolicy),
# you can tell the browser that it can only download content from the domains you explicitly allow
# http://www.html5rocks.com/en/tutorials/security/content-security-policy/
# https://www.owasp.org/index.php/Content_Security_Policy
# I need to change our application code so we can increase security by disabling 'unsafe-inline' 'unsafe-eval'
# directives for css and js(if you have inline css or js, you will need to keep it too).
# more: http://www.html5rocks.com/en/tutorials/security/content-security-policy/#inline-code-considered-harmful
add_header Content-Security-Policy "default-src 'self' https://google.com https://youtube.com https://facebook.com https://fonts.google.com https://fonts.googleapis.com https://ajax.googleapis.com https://www.google-analytics.com https://cdnjs.cloudflare.com https://code.jquery.com https://connect.facebook.net https://s.imgur.com https://imgur.com https://i.imgur.com https://500px.com https://drscdn.500px.org https://www.reddit.com https://www.flickr.com https://c1.staticflickr.com https://maxcdn.bootstrapcdn.com http://code.ionicframework.com https://cdn.fontawesome.com/; script-src 'self' 'unsafe-inline'; style-src 'self'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'none'; media-src 'self'; form-action 'self'; frame-ancestors 'self';" always;
在我的用户的帮助下，这将是一个漫长的学习过程。
我希望这也会对其他人有所帮助。
2019 年 7 月 22 日更新
如评论中所述，在某些情况下 headers 将显示但在第一行之后被忽略。请小心，因为：
nginx treats the white space between the quotes literally, so as long as you begin each new line with a space or tab character, the header will remain valid.
注意：
在 RFC 7230 中弃用了对拆分 header 行的支持：
Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). This specification deprecates such
line folding except within the message/http media type
最安全的解决方案是接受配置文件中的某些行可能比您希望的长得多。
我目前正在尝试了解更多关于 nginx 和作为网络服务器的给定安全性。我想象中的设置是带有 3 个虚拟主机的 nginx。这些主机中的每一个都是 运行 一个博客。
在学习了一些 nginx 强化教程之后，我确实发现自己陷入了那些 http-headers...如果我有多个虚拟机，我不确定通过 nginx 执行内容安全策略是否是正确的方法主机，这可能取决于来自不同站点的不同内容。
不过我目前的立场是弄清楚如何在每个 *-src 参数中为 nginx 设置一个合理的内容安全策略白名单。
既directive reference and source list reference也不
the latest content security policy level 3 确实回答了所有 *-src 的“最佳实践白名单”问题。
假设我对每个参数都设置了 'self'：
default-src:
如果设置为 'self'
script-src,style-src,img-src,connect-src,font-src,child-src:
剩下的真是让我头疼。我怎么知道每一个好的来源？如果我将它们设置为 'self'，用户会始终收到 400 HTTP 错误吗？
正如我之前所说，我不确定通过 nginx 执行内容安全策略是否正确。如果我是 运行 拥有 5 个以上客户端的网络服务器，我将不可能知道这些客户端的每个“好”来源。我想再次指出，我只是想知道这些源参数。其他 HTTP-Headers（不仅是内容安全策略）对我来说很有意义，而且完全合理。
此致， 巨人
更新：经过更多研究
我确实在 Github 上找到了一个非常有用的 Repo。我将与大家分享。
简短说明： Nginx 服务器配置是一个 collection 配置片段，可以帮助您的服务器提高网站的性能和安全性，同时确保资源以正确的方式提供 content-type 并且可以访问，如果需要，甚至 cross-domain.
Link 回购：https://github.com/h5bp/server-configs-nginx
但是我建议您阅读并了解每一个选项！ 我仍然使用我自己的 CSP 政策，如下面的原始答案所示。我认为这些信息可能对 nginx 世界的任何初学者都有用。
我去研究了我的问题。目前，我的配置还不错，我将在本 post 的底部分享。
这个 Whosebug 问题实际上是一个很好的起点：How does Content Security Policy work?
我最后的立场是确保一切安全，如果任何用户获得 CSP - 错误，他们必须告诉服务器管理员他们想要向 CSP 添加另一个来源。如果来源看起来值得信赖，它将被添加，否则被拒绝（我可能会以某种方式自动执行该过程）。
如果有人对进一步的 SSL 配置感兴趣，您可以查看此 github 页面：https://gist.github.com/plentz/6737338
这是我的 nginx header 配置（根据 2019 年 7 月 22 日更新 headers - 见下文）：
# don't send the nginx version number in error pages and Server header
server_tokens off;
# config to don't allow the browser to render the page inside an frame or iframe
# and avoid clickjacking http://en.wikipedia.org/wiki/Clickjacking
# if you need to allow [i]frames, you can use SAMEORIGIN or even set an uri with ALLOW-FROM uri
# https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options
add_header X-Frame-Options SAMEORIGIN always;
# when serving user-supplied content, include a X-Content-Type-Options: nosniff header along with the Content-Type: header,
# to disable content-type sniffing on some browsers.
# https://www.owasp.org/index.php/List_of_useful_HTTP_headers
# currently suppoorted in IE > 8 http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
# http://msdn.microsoft.com/en-us/library/ie/gg622941(v=vs.85).aspx
# 'soon' on Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=471020
add_header X-Content-Type-Options nosniff always;
# This header enables the Cross-site scripting (XSS) filter built into most recent web browsers.
# It's usually enabled by default anyway, so the role of this header is to re-enable the filter for
# this particular website if it was disabled by the user.
# https://www.owasp.org/index.php/List_of_useful_HTTP_headers
add_header X-XSS-Protection "1; mode=block" always;
# with Content Security Policy (CSP) enabled(and a browser that supports it(http://caniuse.com/#feat=contentsecuritypolicy),
# you can tell the browser that it can only download content from the domains you explicitly allow
# http://www.html5rocks.com/en/tutorials/security/content-security-policy/
# https://www.owasp.org/index.php/Content_Security_Policy
# I need to change our application code so we can increase security by disabling 'unsafe-inline' 'unsafe-eval'
# directives for css and js(if you have inline css or js, you will need to keep it too).
# more: http://www.html5rocks.com/en/tutorials/security/content-security-policy/#inline-code-considered-harmful
add_header Content-Security-Policy "default-src 'self' https://google.com https://youtube.com https://facebook.com https://fonts.google.com https://fonts.googleapis.com https://ajax.googleapis.com https://www.google-analytics.com https://cdnjs.cloudflare.com https://code.jquery.com https://connect.facebook.net https://s.imgur.com https://imgur.com https://i.imgur.com https://500px.com https://drscdn.500px.org https://www.reddit.com https://www.flickr.com https://c1.staticflickr.com https://maxcdn.bootstrapcdn.com http://code.ionicframework.com https://cdn.fontawesome.com/; script-src 'self' 'unsafe-inline'; style-src 'self'; img-src 'self' data:; connect-src 'self'; font-src 'self'; object-src 'none'; media-src 'self'; form-action 'self'; frame-ancestors 'self';" always;
在我的用户的帮助下，这将是一个漫长的学习过程。 我希望这也会对其他人有所帮助。
2019 年 7 月 22 日更新
如评论中所述，在某些情况下 headers 将显示但在第一行之后被忽略。请小心，因为：
nginx treats the white space between the quotes literally, so as long as you begin each new line with a space or tab character, the header will remain valid.
注意：
在 RFC 7230 中弃用了对拆分 header 行的支持：
Historically, HTTP header field values could be extended over
multiple lines by preceding each extra line with at least one space
or horizontal tab (obs-fold). This specification deprecates such
line folding except within the message/http media type
最安全的解决方案是接受配置文件中的某些行可能比您希望的长得多。