🐥

Laravelの脆弱性対策について

2021/11/25に公開

Laravel

tech

はじめに

今回は、Laravelのプロジェクトで行うべき脆弱性対策の中でも、サクッと実装できる設定項目を中心にまとめていきたいと思います。

セッション管理用CookieにSecure属性を付与する

secure属性を付与することで、HTTPS通信のみを許可することが可能になります。(HTTP通信によるアクセスを防ぐことができる)
Laravelの場合は、以下のように設定することでsecure属性を付与することが可能です。

// session.php

    'secure' => true,

secure属性が付与されているかどうかは、デベロッパーツールのNetworkタブから確認ができます。

Cache-Controlの指定

Laravelではデフォルトで、cache-controlはno-cacheとなっています。
一見「キャッシュ禁止」に見えるのですが、この状態だとブラウザのキャッシュ履歴からページの復元が可能になっています。
セキュリティ上、ページによってはこの動作を制限したい場合もあるかと思うので、その場合はno-storeにする必要があります。

・Cache-Control: private → Webサーバから返されるコンテンツがただ一人のユーザのためのものであることを示す。このコンテンツは、複数のユーザが共有されるキャッシュに記録されるべきではないことを表している。ただし、これは、一人のユーザのみが利用するキャッシュ（ブラウザのキャッシュ等）への記録を禁じるものではない。Cache-Control: private のみが指定されている場合、何らかのキャッシュへの記録が行われるおそれがある。

・ Cache-Control: no-store → このヘッダは、Webサーバから返されてくるコンテンツをキャッシュに記録するな、という指示である。

・Cache-Control: no-cache → 一見「キャッシュを使うな」のように見えるこのヘッダが実際に意味するところは少々ニュアンスが異なる。このヘッダの意味は、いちどキャッシュに記録されたコンテンツは、現在でも有効か否かを本来のWebサーバに問い合わせて確認がとれない限り再利用してはならない、という意味である。

・Cache-Control: must-revalidate → このヘッダは、キャッシュに記録されているコンテンツが現在も有効であるか否かをWebサーバに必ず問い合わせよ、という指示である。

引用元
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/405.html

CORSの設定をする

WebクライアントとAPIサーバーを分けて実装をしている場合には、CORSの設定が必要になります。

もともとブラウザはセキュリティ上の理由で、同一オリジンポリシーに従い、同じオリジンに対してのみリクエストを許可しています。

同一オリジンポリシーに従うと、他のオリジンからのアクセスが制限されてしまうため、例えばフロントとサーバーを分けて実装している時などは、アクセスを拒否されていまいます。
(Laravel側をlocalhost:8000、Nuxt側をlocalhost:3000で動かしていた場合は、
localhost:3000のNuxt側からlocalhost:8000のLaravel側のAPIにアクセスができません)

そのため、Laravel7以降ではcors.phpというファイルがもともと用意されており、同ファイル内のallowed_originsがデフォルトでは*と指定されています。

この状態だと全てのオリジンからの通信を許可している状態になるため、必要なオリジンのみに制限をします。

    // cors.php
    'allowed_origins' => [],

    'allowed_origins_patterns' => // ここに許可するオリジンを指定する

.htaccessファイルの見直し

.htaccessファイルとは、Apacheが使用されている環境で使用可能な、ディレクトリ単位で認証情報やリダイレクト先を指定できるファイルのことです。
Apacheを使用している場合でも、ユーザー認証の設定はhttpd.confに書くことを推奨されており、.htaccessファイルの使用自体推奨されていないようです。

.htaccessファイルがあると、Cookieを削除した状態でもブラウザ上から下記のURLにアクセスすることで.htaccessファイルが確認できてしまいます。

https://mysite.go.jp/.htaccess  // 元のオリジンに「/.htaccess」を追加してる

.htaccessファイルからは、本来公開されるべきではない設定ファイルや他ユーザのログインID等が閲覧可能となっています。

不要な場合は削除してしまいましょう。

セッションの保持時間

意外な落とし穴だったのが、セッションの保持時間です。

.envファイルのSESSION_LIFETIMEは120(2時間)に設定されているにもかかわらず、実際は10時間以上保持されていることが判明しました。

調べてみると、本番環境はTaskDefinitionファイルで環境変数を指定しており、同ファイルのSESSION_LIFETIMEは10時間以上となっていました。

さいごに

今回は比較的サクッと実装できるLaravelの脆弱性対策についてまとめました。

ここ違うよ！ってところがあれば、優しく教えていただけるとありがたいです。

最後まで読んでいただきありがとうございました！