【Webセキュリティ対策②】クッキーによる機動的なセッション管理

こんにちは、ペンギン男です🐧

ネットワーク系のエンジニアは特に人手不足だし、プログラマーに寄せられる無理難題も、ネットワーク系だと少なめだとか。

たしかに、セキュリティという本題に入るまでに、抑えておくべき知識が多く、なかなか本題に辿りつけません💦そんな中でも、ワードだけは身近な、クッキーとセッション管理を。中身はあまり知りません💦

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践

出典はアマゾンさん。

【目次】

よく見る「パーセントエンコーディング」

これこれ、特殊きごうや日本語なとURLに使用できない文字をURL上に記述する場合に見かけるもの。やたらと%の嵐💦例えば「ペンギン」だと

%E3%83%9A%E3%83%B3%E3%82%AE %E3%83%B3%0D%0A

ちなみに探してみれば、ちゃんとあるもので、日本語をエンコードしてくれるサイト見つかりました↓

よく見る「クッキー」

まず、HTTPというプロトコルはスタートレスだそうです。ステートレスというのは、都度、情報をキープしないことだそうです。

とはいえ、実際には、前回のやり取りを記憶してほしい時も多々あります。すく頭に浮かぶのは、パスワードとかI.D.ですね。あとは、Amazonでカートに入れた商品を覚えておいてほしいとかですね。私は、なんとなくレベルですが、パスワードは毎回入力派です。ログインのたび、別途「HTTP認証」というものをすれば、ブラウザ（デバイスとも言い換えられる？）側で、その状態を覚えてくれているようです。しかしながら、そこそこの手間なので、我々サイド＝ブラウザ側ではなく、サーバ側で覚えておいてくれる技術があります。例の（クッキー」です。

クッキーは何をしてくれる？！

P-43

クッキーは、サーバ側からブラウザに対して、「名前＝変数」の組を覚えていくように指示するものです

下手にJavaScriptなんかかじると、動的なものが中途半端に気になりますが、ここでは、定性的な情報を覚えておいてもらえれば良いわけですね。これだけ見ると割合にシンプルですね💦

クッキーによるセッション管理

クッキーは、セッション毎に管理されるようです。銀行窓口なんかで整理番号が発行されたりしますが、それに相当するものを「セッションI D」と呼ぶそうです。

P-46

•   クッキーが保持できる値の個数や文字列長には制限がある
•   クッキーの値は利用者本人には参照・変更できるので、秘密情報の格納には向かない

クッキーなんて、それこそ、どこでも使われているはず。知識の圧倒的な不足も手伝って、この情報だけに触れると、ひたすら怖いですが💦

あと、この情報を悪用されないためには、まずは、セッションI Dが、簡単にバレないようにすることですね。

セッションI Dの保護

セッションIDに求められるのは、次の三つ。

P-47

1.    第三者がセッションIDを推測できないこと
2.    第三者からセッションIDを強制されないこと
3.    第三者にセッションIDが漏洩できないこと

素人目にも、どの項目も、セキュリティ管理のための、ど真ん中の条件ばかりですね。ということもあってか、本書で、あとで細かくフォローされるようです。

よく見るクッキーの属性

サーバからのレスポンスメッセージで、見かける属性が紹介されていたので、念のため共有させてください。

P-50

•   Domain→ブラウザがクッキー値を送信するサーバーのドメイン
•   Path→ブラウザがクッキー値を送信するURLのディレクトリ
•   Expires→クッキー値の有効期限。指定しない場合はブラウザの終了まで。
•   Secure→SSLの場合のみクッキーを送信
•   HttpOnly→この属性が指定されたクッキーはJavaScriptからアクセスできない

個人的には「Path」と「HttpOnly」が分かりにくかったので、少しスッキリ😊  

最後に

これは個人的な意見というよりは、割と一般性があると思いますが、ネットワーク系は、なかなか、とっつきにくいですよね。でも、本書は丁寧な進め方のせいか、ポイントのつかみ方が秀逸なのか、意外と読み進められめすね。不思議💦

また、次回

#安全なWebアプリケーションの作り方 

#クッキー

#HTTP認証