【Webセキュリティの教科書①】履歴をもたない「ステートレス」と、その解決策としての「クッキーとセッション管理」
こんにちは、ペンギン男です🐧
なかなかセキュリティに関して関心が起こらない
正直、セキュリティに関しては、突っ込んで学習する気はありませんでした。理由として
- ネットワーク技術に固有の問題というイメージ↓
- ネットワーク技術は、とかく覚えることが多い↓
- ネットワーク技術は、実機がないと、なかなかピンとくることが難しいというイメージ
からです。
一方、通常のセキュリティ対策としては、特にメールの
取り扱いに関しては
- メール自体を開くな
- 添付ファイルを開くな
- URLをクリックするな
というもので、それなりに忠実に実行しているつもりですが、これだけセキュリティの重要性
が叫ばれている中で、あまりに、アッサリしていて、どこか歯がゆい思いをしていました（その割には、学習しようという意思はなかなか起こらなかったのですが💦）
ネットワーク技術中心というよりWebアプリケーション中心のセキュリティという分野発見
そんな中、たまたまセキュリティの本を手にして、少し関心が湧きました。ハッキングなんて、ハッカーサイドの一方的な攻撃かと思いきや（誘導されているとは言え）被害者サイドの操作も少なからずあることを発見。ちょっとした感動でした。その時の記事↓
penguinotokonoseikatsu.hatenablog.com
ついては、次のステップに進むべく、同じ筆者の書籍に挑戦↓しかし、ハードル高過ぎました💦
そんなこんなで、「安全なWebアプリケーションの作り方」は、一旦、脇に置いて、よりビギナーよりの本書に挑戦↓
出典はアマゾンさん。
【目次】
(ページネーションはkindleでの表記に従います)
「脆弱性」というキーワードは、ここでは控えめ
先の「安全なWebアプリケーションの作り方」では、「脆弱性」がメインのテーマ。しかし、ここでは、大きな六つのうちの一つ。
No.21〜24を抜粋
しかし、内容を追ってみると、すべてはWebアプリケーションの脆弱性に関連してそう。
セッション管理
あるWebページを閲覧したらセッション一回としてカウントされます。セッションした行為及び、そのセッションの内容は秘匿しておきたいところですが、一方で、自動的に覚えてもらったほうが便利なことも。パスワード入力の手間を省いたり、オンラインショッピングで、一旦チョイスした商品を覚えてもらったりとか。
しかし、HTTPというWebアプリケーションで使う通信ルール（プロトコルというのが専門的らしいですが）では、「状態」という概念がないそうです。
No.37
つまり、もともとステートレス（静的なやりとりをするもの）なのです。たとえるなら、ロールプレイングゲームで村人に「いつ、だれが、何度」話しかけても同じ回答しか返さないーーーそういう仕様です。
どうやら、ステートレスというのは、毎回のセッションを記憶してないということらしい💦
そこで発明されたのがセッション管理。セッションIDを都度のセッションに充当するとこにしたのだとか。
No.37
セッションIDの例
しかし、これ、実装は相当大変そうだし、外部への漏洩とか、パラメータ（個々を識別する情報）が容易に改変できるというセキュリティ問題があるよう。
クッキー
そこで開発されたのが、よく耳にする「クッキー」。どんなステップかと言うと
No.38
こんなCookieでも脆弱性は存在するので、その対応としては二つの手があります。
No.39を編集
イメージとしては、クッキーがすべての情報を持っているのかと思ってましたが、クッキーは、便利な「整理札」のようなものですね。おそらく。クッキーは、本件に関する次回の記事で取り上げらる予定です。
#Web担当者のためのセキュリティの教科書
#セッション
