IPAの「安全なウェブサイトの作り方」を読み進める第3回！
この記事は上記の文書を個人的にまとめた防備録となるので注意。
この文書の目次は以下。
1) SQL インジェクション
2) OS コマンド・インジェクション
3) パス名パラメータの未チェック/ディレクトリ・トラバーサル
4) セッション管理の不備
5) クロスサイト・スクリプティング
6) CSRF(クロスサイト・リクエスト・フォージェリ)
7) HTTP ヘッダ・インジェクション
8) メールヘッダ・インジェクション
9) アクセス制御や認可制御の欠落
前回はディレクトリ・トラバーサルについて学んだ。
今回は「セッション管理の不備」、「セッション・ハイジャック」とかのことかな。
1.セッション管理の不備とは
セッション管理の不備では、「セッション・ハイジャック」と「セッションIDの固定化」の２種類の脆弱性が紹介されている。
それぞれ見ていこう。
まずは「セッション・ハイジャック」について。
安全なウェブサイトの作り方より。
ウェブアプリケーションの中には、セッション ID(利用者を識別するための情報)を発行し、セッション管理を行っているものがあります。このセッション ID の発行や管理に不備がある場合、悪意のある人にログイン中の利用者のセッション ID を不正に取得され、その利用者になりすましてアクセスされてしまう可能性があります。この問題を悪用した攻撃手法を、「セッション・ハイジャック」と呼びます。
「セッション・ハイジャック」とは、自分のセッションIDからの他人のセッションIDを推測したり、罠や盗聴により他人のセッションIDを盗むことで、他人になりすましウェブアプリケーションにアクセスすること。
続いて、「セッションIDの固定化」について。
安全なウェブサイトの作り方より。
悪意ある人があらかじめ用意したセッションID を、何らかの方法で利用者に送り込み、利用者がこれに気付かずにパスワードを入力するなどしてログインすると起こりうる問題です。
セッションIDを固定化させることで、利用者が使っているセッションIDがわかるため、そのセッションIDを使ってログインすればなりすますことができる。
上記2つのセッション管理の不備により発生する脅威は、
・ログイン後の利用者のみが利用可能なサービスの悪用
・ログイン後の利用者のみが編集可能な情報の改ざん
・ログイン後の利用者のみが閲覧可能な情報の閲覧
基本的にログイン後のほうが大事なことするよね・・・
注意が必要なウェブサイトはログイン機能をもつウェブサイト全般。
あと、ログイン機能を持たなくてもセッションIDを発行するサイトも注意。
2.セッション管理の不備の対策
示された解決策はこちら。
PHPでのプログラミング的な解決策は徳丸本を読んだ時にする。
セッション ID を推測が困難なものにする
セッション ID は、生成アルゴリズムに暗号論的擬似乱数生成器を用いるなどして、予測困難なものにしてください。
セッションIDを単純なアルゴリズムで生成すると簡単に推測されてしまうため。
セッション ID を URL パラメータに格納しない
セッション ID を URL パラメータに格納していると、利用者のブラウザが、Referer 送信機能によって、セッション ID の含まれた URL をリンク先のサイトへ送信してしまいます。悪意ある人にその URL を入手されると、セッション・ハイジャックされてしまいます。セッション ID は、Cookie に格納するか、POST メソッドの hidden パラメータに格納して受け渡しするようにしてください。
ここよくわからん。
hiddenでも見られるんじゃないのか？
要チェック。
HTTPS 通信で利用する Cookie には secure 属性を加える
ウェブサイトが発行する Cookie には、secure 属性という設定項目があり、これが設定された Cookieは HTTPS 通信のみで利用されます。Cookie に secure 属性がない場合、HTTPS 通信で発行したCookie は、経路が暗号化されていない HTTP 通信でも利用されるため、この HTTP 通信の盗聴によりCookie 情報を不正に取得されてしまう可能性があります。HTTPS 通信で利用する Cookie には secure属性を必ず加えてください。かつ、HTTP 通信で Cookie を利用する場合は、HTTPS で発行する Cookieとは別のものを発行してください。
Cookieには secure属性というものがある。
これは HTTPS通信のみで利用可能で、盗聴されないらしい。
Cookieについてまた今度記事を書こう。
ログイン成功後に、新しくセッションを開始する
ウェブアプリケーションによっては、ユーザがログインする前の段階(例えばサイトの閲覧を開始した時点)でセッション ID を発行してセッションを開始し、そのセッションをログイン後も継続して使用する実装のものがあります。しかしながら、この実装はセッション ID の固定化攻撃に対して脆弱な場合があります。
ログイン前に発行したセッションIDをログイン後に破棄して、新しいセッションIDを発行する。
こうすることで悪意のある第3者が事前に手に入れたセッションIDでアクセスできなくなる。
保険的対策
・セッション ID を固定値にしない。
・セッション ID を Cookie にセットする場合、有効期限の設定に注意する。
この2つは本文を読んで。
コメント