Nginxを触る

とあるリポジトリのアクセスログ収集のために、初めて0からnginxを触るのでメモしていく

nginx(docker) -> Next.js(ローカル)という形で、docker上でのみ動くプロキシサーバとして使いたい。
proxy_passでhost.docker.internalを指定してローカルで起動しているNext.jsにリクエストを流した。

proxy_pass http://host.docker.internal:3000;

takara

dockerで動かしている場合、ビルドしないとnginx.confの設定変更が読み込まれないので注意(しばらくハマった)

takara

ChatGPTに聞いていた所、UpgradeというHTTPヘッダの付与も指示されていた。

            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;

どうやらNextのバージョン12以降で使われている機能で必要になるらしい。

以下の version12のリリースの際に HMR connection に webSocket を使用することになり、その際にこのコードブロックがNext.jsから提示されたっぽい。

HMR(Hot Module Replacement)の事。エディタでファイルを編集していて、保存した後に勝手に表示するコンポーネントも更新してくれるアノ機能。実はwebSocketが使用されているらしい。

HTTPのupgrade headerと、なぜそれがNext.js+Nginxな構成に必要なのか[備忘録] #Next.js - Qiita

takara

他の似た構成のリポジトリを参考に、追加が必要そうなヘッダを調べていく

takara

Cross-Origin-Opener-Policy

Cross-Origin-Opener-Policy とは
ユーザがサイトAを閲覧しているとき
サイトA からサイトBをウィンドウとして開いた場合 (noopnerはつけてない)、Bはwindow.openerを介してAにアクセスすることができます（仮にAとBのオリジンが違っていても、制限はありますがAのプロパティにアクセスできます。）

このようなアクセスは、サイトのアイソレーション上好ましくありません。このようなことを防ぐために、Cross-Origin-Opener-Policyヘッダを利用します。もし、指定されたPolicyに合わない場合は、上記のような繋がりは解除されます(ウィンドウを閉じて開き直したのと同じ状態)

window.openerの存在を知らなかった

takara

Referrer-Policy
リファラ情報をどこまで含めるかの設定。
Referrer-Policy - HTTP | MDN

サイトにおける要件により変わってくるかと思いますが、大体のサイトで求められるのが
外部サイトには全てのURLを送りたくない
同じサイト内での遷移は全てのURLを送りたい(tracking等便利な為)
HTTPへリクエストを送るときはrefererを送りたくない(中間者攻撃を防ぐため)
の3点です。この条件を満たすのはstrict-origin-when-cross-originとなるので
知ってるようで知らないRefererとReferrer-Policyのお話 #Security - Qiita

takara

Strict-Transport-Security

HTTP の Strict-Transport-Security レスポンスヘッダー (しばしば HSTS と略されます) は、ウェブサイトがブラウザーに HTTP の代わりに HTTPS を用いて通信を行うよう指示するためのものです。

max-age=<expire-time>
秒単位で、そのサイトに HTTPS だけで接続することをブラウザーが記憶する時間です。

includeSubDomains 省略可
省略可能で、この引数が指定されると、この規則がサイトのすべてのサブドメインにも適用されます。

Strict-Transport-Security - HTTP | MDN

takara

X-Content-Type-Options

X-Content-Type-Options は HTTP のレスポンスヘッダーで、 Content-Type ヘッダーで示された MIME タイプを変更せずに従うべきであることを示すために、サーバーによって使用されるマーカーです。これにより、MIME タイプのスニッフィングを抑止することができます。言い替えれば、 MIME タイプを意図的に設定することができます。

X-Content-Type-Options - HTTP | MDN

X-Content-Type-Options:nosniffとは？
この属性を付与するとファイルの内容をContent-Type属性から判断してねとお願いできる。
IEではContent-Typeを指定していても、htmlと勝手に判断してJavascriptが実行されてしまうことがあるためMSが実装した。
IE以外のブラウザでも使える属性である。

なんのために使うの？
ファイルダウンロード時にファイル形式をブラウザに誤認させてJavascriptを実行させてしまうような攻撃(XSS攻撃)を防ぐことができる。

Content-TypeとX-Content-Type-Options: nosniff #Security - Qiita

takara

X-Download-Options

HTTP の X-Download-Options ヘッダーは、ブラウザー (Internet Explorer) がアプリケーションからのダウンロードでファイルを「開く」の選択肢を表示しないようにし、アプリケーションのコンテキストで実行するアクセス権を得ることがないようにして、ファイルとすることでフィッシング詐欺を防止します。

この解説が分かりやすかった
X-Download-Options - mrsekut-p

takara

X-Frame-Options

X-Frame-Options は HTTP のレスポンスヘッダーで、ブラウザーがページを <frame>、<iframe>、<embed>、<object> の中に表示することを許可するかどうかを示すために使用します。サイトはコンテンツが他のサイトに埋め込まれないよう保証することで、クリックジャッキング攻撃を防ぐために使用することができます。

X-Frame-Options - HTTP | MDN

安全なウェブサイトの作り方 - 1.9 クリックジャッキング | 情報セキュリティ | IPA 独立行政法人情報処理推進機構

takara

X-XSS-Protection

HTTP の X-XSS-Protection レスポンスヘッダーは Internet Explorer, Chrome, Safari の機能で、反射型クロスサイトスクリプティング (XSS) 攻撃を検出したときに、ページの読み込みを停止するためのものです。サイトが強力な Content-Security-Policy を実装しており、インライン JavaScript ('unsafe-inline') の使用を無効にしている場合、これらの保護は現代のブラウザーではほとんど不要となります。

1; mode=block
XSS フィルタリングを有効化します。攻撃を検知すると、ページをサニタイジングするよりも、ページのレンダリングを停止します。

X-XSS-Protection - HTTP | MDN