web-dev-qa-db-ja.com

nginx（仮想ホスト）の合理的なコンテンツセキュリティポリシーソースを理解する方法は？

私は現在、nginxとWebサーバーとしてのセキュリティについて詳しく学ぼうとしています。私の想像上のセットアップは、3つの仮想ホストを備えたnginxです。これらの各ホストはブログを運営しています。

Nginxの強化チュートリアルをいくつか実行した後、私はそれらのhttp-headers...で立ち往生していることに気付きました。複数の仮想ホストがある場合、nginxを介してコンテンツセキュリティポリシーを適用することが正しい方法かどうかはわかりません。さまざまなサイトのさまざまなコンテンツで。

ただし、現時点での私の立場は、すべての*-srcパラメーターでnginxの適切なコンテンツセキュリティポリシーホワイトリストを設定する方法を理解することです。

ディレクティブ参照およびソースリスト参照 も 最新のコンテンツセキュリティポリシーレベル も、すべての*-srcの「ベストプラクティスホワイトリスト」の質問に答えませんでした。

これらすべてのパラメーターに'self'を設定したとしましょう。

  • default-src：

これは、'self'に設定した場合に意味のある唯一のパラメーターです。

  • script-src、style-src、img-src、connect-src、font-src、child-src：

残りは私に本当の頭痛を与えています。どのように私はすべての良い情報源を知ることになっていますか？それらを'self'に設定すると、ユーザーは常に400 HTTPエラーを受け取りますか？

前に言ったように、nginxを介してコンテンツセキュリティポリシーを適用することが正しい方法かどうかはわかりません。 5つ以上のクライアントでWebサーバーを実行している場合、それらのクライアントのすべての「適切な」ソースを知ることは不可能です。繰り返しになりますが、私はこれらのソースパラメータについて疑問に思っているだけです。他のHTTPヘッダー（コンテンツセキュリティポリシーだけでなく）は私にとって意味があり、完全に合理的です。

よろしく、メガジン

securitynginxhttp-headerswebservercontent-security-policy
6
Megajin

更新：さらに調査した後

Githubで非常に役立つリポジトリを見つけました。これを皆さんと共有します。

簡単な説明：Nginx Server Configsは、サーバーがWebサイトのパフォーマンスとセキュリティを向上させるのに役立つと同時に、リソースが正しいコンテンツタイプで提供され、アクセスできるようにするための構成スニペットのコレクションです。クロスドメインでも必要です。

リポジトリへのリンク： https://github.com/h5bp/server-configs-nginx

ただし、すべてのオプションを読んで学ぶことをお勧めします。以下の元の回答で示したように、私はまだ独自のCSPポリシーを使用しています。この情報は、nginxユニバースの初心者にとって役立つかもしれないと思いました。

私は行って、自分の問題についてさらに調査を行いました。現時点では、この投稿の最後で共有する構成に問題はありません。

このStackoverflowの質問は、実際には良い出発点でした： コンテンツセキュリティポリシーはどのように機能しますか？

私の最後の立場は、すべてを保護することです。ユーザーのいずれかがCSPを取得している場合-エラーは、サーバー管理者に別のソースをCSPに追加することを通知する必要があります。ソースが信頼できると思われる場合は追加され、そうでない場合は拒否されます（そのプロセスを何らかの方法で自動化する可能性があります）。

誰かがさらにSSL構成に興味がある場合は、このgithubページを検索できます： https://Gist.github.com/plentz/6737338

これが私のnginxヘッダー設定です（2019年7月22日の更新に従って更新されたヘッダー-以下を参照）：

# 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は、引用符の間の空白を文字通り処理するため、新しい各行をスペースまたはタブ文字で開始する限り、ヘッダーは有効なままです。

注：

ヘッダー行の分割のサポートは、RFC7230で非推奨になりました。

から RFC 7230セクション3.2.4

歴史的に、HTTPヘッダーフィールドの値は
各余分な行の前に少なくとも1つのスペースを置くことによる複数の行
または水平タブ（obs-fold）。この仕様はそのようなものを非推奨にします
メッセージ/ httpメディアタイプ内を除く行の折りたたみ

最も安全な解決策は、構成ファイルの一部の行が希望よりもはるかに長くなる可能性があることを受け入れることです。

アップデートのソース： https://stackoverflow.com/a/50043114/4457744

17
Megajin