0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

セッションを用いたセキュリティ攻撃(セッションID、クッキー)

Posted at
前提
プログラミング初学者(2~3ヶ月)が学んだ内容をまとめています。
実際の現場では通用しないことや間違った内容が含まれている可能性があります。
間違っている部分や浅い部分については追記、ご指摘いただけると幸いです。

セッションを用いたセキュリティ攻撃について学んだ内容をまとめました。
#セッションを狙った攻撃と対策
##セッションとは?
セッションとは、データを一時的に保存しておく仕組みのことです。
この一時保存される保存先はクッキーと呼ばれます。
youtubeやtwitterに同じ端末からアクセスすると自分のアカウントでログインされた状態になっていますよね。
あれはセッションという仕組みでログイン情報がクッキーに一時的に保存されているため、毎回ログインをしなくてもログイン状態になっているということです。
このログイン情報などが一時的に保存されているクッキーを狙った攻撃をセッションハイジャックといいます。
##セッションハイジャック
XSSなどを用いて、正規利用者ではないものが正規利用者のセッションを取得する攻撃方法です。

XSSはwebアプリやwebページを開いたらスクリプトが発動し、個人情報が攻撃者へ送信されるといったものです。
以前まとめた記事が以下です。
https://qiita.com/Nako4/items/845da2ed4872524c2a15

クッキーにはセッションIDという識別番号を用いて保存します。
このセッションIDを盗み出されることで、セッションハイジャックが成立します。
セッションID
通信中の正規利用者へ付与される固有の識別情報のこと
##攻撃されると危険な理由
危険性については、なんとなく察することができると思います。
セッションを悪意ある攻撃者に取得されるとログイン情報が第三者の手に渡ってしまい、正規利用者のできることが全てできる状態になってしまうということです。
例えば、配送先の住所や購入情報(クレカ番号)を登録している場合
・正規利用者の個人情報を見ることができる
・勝手に物品購入をする
・送金ができる
・メールアドレスを使ってなりすましメールを送る
このように正規利用者への被害はとても大きくなります。

##セッションを用いた攻撃方法
具体的にセッションへの攻撃方法は3つあります。
・セッションIDの推測
・セッションIDの盗み出し
・セッションIDの強制

セッションIDの推測

Webアプリケーションに用いられるセッションIDの生成規則に問題があると、第三者にセッションIDが予測されやすくなります。
問題があるセッションID
・ユーザーIDやメールアドレス
・リモートIPアドレス
・日時
セッションIDの推測は外部から参照可能な値を用いて行われる手法です。
対策
独自でセッションID生成は行わない。
推測可能なセッションIDを生成しないために、独自での生成機構は作らず、フレームワークなどのWebアプリケーション開発ツールを利用することが安全とされています。
セッション管理機能に脆弱性が発見された場合、すばやく指摘・改善されることが期待できるためです。
Ruby on Railsもこのアプリケーション開発ツールの1つです。

セッションIDの盗み出し

JavaScriptでは、

<script>document.cookie</script>

というスクリプトで
クッキーの情報が表示できます。
このスクリプトへ細工をして、攻撃側のサーバに正規利用者のクッキーの情報を送付するようにすると、セッションハイジャックが成立します。
インターネット環境のセキュリティ対策が不十分であると、正規利用者とサーバーの通信の際に、故意または偶然にセッションIDが第三者へ受信されることがあります。

対策
・XSSを防ぐ
・安全なインターネット環境を用いる。
インターネット環境の安全性向上のためには、インターネット上の通信を暗号化する仕組みを使います。
この暗号化の仕組をSSLといいます。

SSL(Secure Sockets Layer)
SSLはインターネット上の通信を暗号化してくれる技術です。
暗号化して通信を行うことで、第三者からの情報の盗聴や改ざんを防ぐことができます。
このSSLを使うことで、クッキーのような常用な情報をやりとりする際に安全性を保つことができます。
SSL化されたURLはhttps://から始まるwebページのことです。

セッションIDの強制

セッションを攻撃者が顔分から強制的に固定化する方法です。
具体的な手順は
①攻撃者が正規の利用者としてセッションID(abc)を取得
②正規利用者に対して、①で取得したセッションIDを強制
③正規利用者は標的アプリケーションにログイン
④攻撃者は正規利用者に強制したセッションID(abc)を使って標的アプリケーションにアクセスする

セッションとは利用者の状態を保持するために使われていました。
正規利用者は攻撃者が強制したセッションでログインなどの認証が完了した状態が一時保存されています。
つまりこのセッションを用いて攻撃者もログイン済みのページにアクセスすることができてしまいます。
対策
ログイン後にセッションIDを変更する
セッションIDを固定化する方法は多種多様であるため、固定化されないように常に変更し続けることが重要です。
例えば、ログインした直後にセッションIDを変更するとしておくことで、セッションを強制されていても、ログイン後に更新されるため、攻撃者が強制したセッションを用いてWebアプリケーションを利用することはできません。
Ruby on RailsのGemの1つであるdeviseはこの仕組を採用しています。

##まとめ
セッションとはログイン情報を一時保存できる仕組みでクッキーという場所に保管されている。
セッションを用いたセキュリティ攻撃には推測、盗み出し、強制の3つがある。
推測:独自の生成規則を作らず、既存のフレームワークを使うことでセッションIDを推測されにくくなる。
盗み出し:基本的なXSSの対策を行う。
強制:セッションIDをログイン後に変更することでセッションIDの固定化を防ぐ。

0
1
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?