見出し画像
Photo by seikoala

Basic認証/Cookie・Sessionについて

sumi

CookieやSessionについてよく聞くけどよく分からない〜状態だったので、認証におけるセキュリティについて勉強してみました。

Basic認証

簡易的な認証で、一旦401（unauthorized）を返し、idとpasswordの入力画面で入力した値で再度リクエストします。

画像1

Basicの後ろの文字列は「ID：パスワード」とコロン（：）で繋ぎ、Base64エンコードしたものです

一度Basic認証に成功するとその後はブラウザが自動的にAuthorizatioonヘッダを付与してくれますが、実際はリクエストごとにIDとパスワードを送ってます。

セッションとクッキーによる認証

サーバー側でアプリケーションの状態を覚えておくことを「セッション管理」という。これにクッキーを組み合わせることで認証ができます。

１：サーバー側でセッションを開始

<?php
 session_start();

レスポンスヘッダのSet-Cookieにより、ブラウザに対してクッキーの値をお覚えるように指示します。

画像2

パスワードとIDを入力してログインするときに、上記でSet-Cookieで指定された「to6q...」を入れてリクエストします

画像3

クッキーの値（to6q...） はセッションIDと呼ばれてセッション情報にアクセスするためのキー情報になります。

いったんクッキー値を覚えたブラウザはその後同じサイトにリクエストを送信するときは覚えたクッキー値を送信します。

【クッキー】
クライアントで保持するデータ。個数や文字列に制限がある
Chromeはここから見れる→ chrome://settings/siteData
秘密情報の格納には向かない整理番号として扱う

↑セッションIDを整理番号として使う特性から、連番だと推測される可能性があるので十分な桁数の乱数を使用します。メンテナンスされているPHPや.NET等で提供されているセッション管理機構を利用するのが一般的です。自作すると脆弱性が混入する可能性が高まります。

↑上記のMDNにあるようにcookieは簡単に取得できます。クロスサイトスクリプティングによりJSを悪用して盗まれる可能性があるときに有効なのが、HttpOnly属性です。完全に防ぐことはできませんが、攻撃を難しくします。

設定はphp.iniでできます。

session.cookie_httponly = On

漏洩のリスク

上記で書いたようにセッションIDが漏洩すると、悪意のあるユーザーが他人になりすましてログインすることが出来てしまいます。

公衆無線ＬＡＮなど盗聴しやすい環境は危険性が高いです。TSLによる暗号化が有効です。↓

認証情報を含むリクエスト

デフォルトではクロスオリジンに対するリクエストにはクッキーの認証に用いられるヘッダは送信されません。

クッキーなどの認証用ヘッダを伴うクロスオリジンリクエストは、クライアント側で withCredentialsをtrueにして、サーバー側でも Access-Control-Allow-Credentialsをtrueにする必要があります。

参考


スキ頂けると嬉しいです〜