CookieのSecure属性を有効にしましょうという話
こんばんは!
引き続きセキュリティ対策についてのまとめです
本日は「CookieのSecure属性を有効にしておこう」という話です
まず初めに...
CookieのSecure属性とは何か
これは、「HTTPS通信時のみCookieを送信する」という設定です。
この対策をしていないと、平文HTTP通信でもCookieを送信する様になっています。
これでは第三者が盗聴できる状態であることを指しますので、セッションハイジャックの危険性も高まることを意味しています。
ざっくりとご理解いただけましたでしょうか?
では...
どんな被害があるのか、なぜ対策すべきなのか
について纏めていきましょう...と言いたいところですが
私の力不足で、「Secure属性」が起因する実被害を見つける事ができませんでした...(汗)
一般には上述の通り「セッションハイジャック」の危険性が高まると言われております。
【セッションハイジャックとは】
セッションIDを不正に入手し、利用者になりすましてアクセスする攻撃の事
参考:
今回の 「Secure属性」を付与することがセッションハイジャックの対策になるとお伝えしていましたが
残念ながらこの対策だけでセッションハイジャックを完全に防ぐことはできません。
ですが、簡単にできるSecure属性付与という対策をしていないだけで、簡単にCookieを盗聴されてしまうのですから、面倒と思わず対応していきましょう!
Laravelで対応する場合
こちらは、config/session.php
で設定ができますので、envファイルに追記することで対応が可能になります。
/*
|--------------------------------------------------------------------------
| HTTPS Only Cookies
|--------------------------------------------------------------------------
|
| By setting this option to true, session cookies will only be sent back
| to the server if the browser has a HTTPS connection. This will keep
| the co![](https://storage.googleapis.com/zenn-user-upload/b233a3bac842-20230703.png)okie from being sent to you when it can't be done securely.
|
*/
'secure' => env('SESSION_SECURE_COOKIE'),
SESSION_SECURE_COOKIE=true
では、動作検証で確認してみましょう
はい、この様にsecure属性を付与することができました
Nginxで対策をする場合
こちらは、様々対策方法があると判明しましたので、一つずつ検証してみましょう
まずは、下記の検証をしてみましょう
add_header Set-Cookie "Path=/; HttpOnly; Secure";
結果はこちら
sessionにSecure属性を付与できませんでした。
次の検証をしてみましょう
proxy_cookie_path / "/; HTTPOnly; Secure";
結果はこちら
同様にSecure属性を付与できませんでした。
最後にもう一つ検証してみましょう
proxy_cookie_flags ~ httponly secure samesite=strict;
結果はこちら
同様にSecure属性を付与できませんでした。
これはあくまでも私個人の推測です
① Set-Cookieはクッキーに属性を付与するものではなく、クッキーを追加する為のディレクティブであるから
② proxy_cookie_pathはPath属性の変更に用いられる為、今回のSecure属性の変更に関しては期待する動作が得られなかったのでは?
と考えます。
ここで私は、「nginxでCookieにsecuere属性は付与できないのか?」と考えました
そこから調べに調べ...
私見として、下記の結論に至りました
① Laravelで発行するsessionのCookieはnginx側でsecure属性にできない
Laravelというアプリケーション側で発行されたCookieは、Laravel側で管理しているので
nginx側では制御ができません
従って、sessionのcookieにsecure属性を付与したい場合は、laravel側で設定しましょう
これはレスポンスに付与するCookieも同様です
ここまでの検証は避けますが、実際に動かしてみたところsecure属性は付与できませんでした
② nginxのadd_headerは静的ファイル又はresponseに対して効果を発揮する
以下の検証を行ってみました
【静的ファイルを用意し、nginx側でlocationディレクティブを追加作成】
location /static {
root /app/public;
try_files $uri $uri/ /hoge_fuga/test.html =404;
add_header Set-Cookie "my_hoge_fuga_cookie=im_secure_cookie_yeah; Path=/; HttpOnly; Secure";
}
test.htmlという静的ファイルを配置し、
add_headerで"my_hoge_fuga_cookie"というCookieを生成してみました
動作確認をしてみましょう
secure属性が付与できております!!
やはり、「nginxで生成したCookieであること」は正しいようです
今日はここまでです!
簡単にまとめますと
- アプリケーションで生成したCookieは、アプリケーション側でsecure属性をつけましょう
- Webサーバー側で生成したCookieはWebサーバー側でsecure属性をつけましょう
これは私にとっても大きな学びになりました!!!
最後までお付き合いいただきありがとうございました!
アルサーガパートナーズ株式会社のエンジニアによるテックブログです。11月14(木)20時〜 エンジニア向けセミナーを開催!詳細とご応募は👉️ arsaga.jp/news/pressrelease-cheer-up-project-november-20241114/
Discussion