セキュア・プログラミング講座（Webアプリケーション編)ブートアップセミナー
（ＮＩＩで開催）にいってきた！
その内容をメモメモ
・ＩＰＡのセキュア公開資料
脆弱性を前倒しで論点を挙げている
やさしい論点が後になる
■導入：ＨＴＴＰプロトコル
・Ｗｅｂアプリケーション
まあ、せつめいしなくてもいい
・使われるプログラミング言語の例
サーバー
ＲｏＲに刺激されＣａｋｅ，Ｄｊａｎｇｏ・・・
クライアント
Ｄａｒｔ，ＴｙｐｅＳｃｒｉｐｔ
JQuery
大きなことが抜けている
・攻撃は通信から入ってくる
ＨＴＴＰプロトコル
・ＨＴＴＰの通信を観察する
ローカルプロキシ：リクエストの監視、改変
ＤＷＡＳＰ・ＺＡＰ・Ｆｉｄｄｌｅｒなど
・ＨＴＴＰ通信の観察
ＭＩＭＥメッセージの一種
・ＰＯＳＴメソッド
・舞台裏は単純なテキストのやり取り
→いくらでも捏造、改変できる
■ＳＱＬインジェクション：シンプルな攻撃
・攻撃の流れ
入力パラメータにＳＱＬ文字列を使い、データを破壊する
・被害
ＤＢの中身を読み出される
定義も
ＲＤＢＳの種類、バージョンがわかる
情報の改ざん→データ破壊
サーバーのっとり
・やりかた
パスワードを' or 'a'='a とする
・悪さをする特殊企業
'
;
スペース ＳＱＬサーバー
-- コメント
\ 特殊記号：エスケープを乗り越える
・対策
ＳＱＬ文の発行を半自動化してくれる道具を使う
よい道具
Ｏ／Ｒマッパ
言語に統合されたクエリ（ＬＩＮＱ、ＰＬ／ＳＱＬ）
プリペアド・ステートメント
次善の策
特殊記号をエスケープする
・Ｏ／Ｒマッパー
ＲｏＲ ＡｃｔｉｖｅＲｅｃｏｒｄ
Ｇｒａｉｌｓ ＧＯＲＭ
Ｃａｋｅ Ｍｏｄｅｌ
Ｓｐｒｉｎｇ Ｓ２ＪＤＢＣ，Ｈｉｂｅｒｎｅｔａ
・ＳＱＬ注入のポイント
ＳＱＬ文を発行してデータベースへアクセス
ＳＱＬの構文を攻撃者にいじられない
■スクリプト注入
ブラウザ側を攻撃
・典型的にはＸＳＳ
ＨＴＭＬの文字列を貼り付けられると、
・偽ページ：
セッションのっとり
・攻撃方法
・攻撃パターン
スタイルタグなどもあぶない：いろいろな手口
・対策１：scriptタグを抑止
対策２：ＵＲＬ属性の無害化
・バリエーション
蓄積されたデータ内
ＤＯＭ型（ＡＪＡＸ）
■セッションメカニズムとユーザー認証について
・ＨＴＴＰはステートレス
セッションで
セッションＩＤ運び方３種類
ＵＲＬリライティング
ＰＯＳＴデータ
クッキー
■セッションハイジャック
・ＳＳＬで暗号化していても、セッションハイジャックは
起こる可能性はある
→証明書を使わない限り、なりすましはできる
・被害
なんでもできる
金銭被害
情報漏えい
業務妨害
・悪い例
ある種のフレームワーク
ログイン前とログイン後で同じセッションＩＤを使っている場合
「推測」への対応
→処理系が作ってくれるので、それを使う
ログイン、ユーザー認証成功のたびに異なる値を使う
「奪取」の対応
ＳＳＬなどを使う
Ｃｏｏｋｉｅにセキュア属性
Ｃｏｏｋｉｅの寿命を短くする
ログイン成功時のＣｏｏｋｉｅを発行しなおす
・セッションハイジャックのポイント
発行と運用にかかわる
他人が入ってくる
対策：「推測」されない「奪取」されない
■セッションフィクセーション
（セッションＩＤのお膳立て）
・攻撃の流れ
攻撃者はＣｏｏｋｉｅを取得し、
ユーザーにそのＣｏｏｋｉｅを送りつけると
攻撃者が知っているＣｏｏｋｉｅでログインすることになる
→付け替えないから
あとは、セッションハイジャックと同じ
・対策
ログインしたとき、新しいセッションＩＤにする
■アクセス認可の実装
・失敗パターン
メニューにないページにアクセスできる
ＵＲＬをたたくと画面が出てくる
他者の所有データにアクセスできる
ＩＤに連番のキーの場合
・対策
ページごとに、保護するロジック
オブジェクトのオーナーを確かめる
・より一般的：ＰＥＰ
保護すべきもの：Ｗｅｂページ
問い：今ログインしているユーザーは
その対象へアクセスする権限をもつか
■ほかの論点
・セキュア・プログラミング講座
Ｗｅｂアプリケーション編
に書いてある
要件定義で考えないといけないもの
設計でもいいもの
実装でも間に合うもの
クロスサイト リクエスト フォージェリー
正常
サーバーが送りだす→ブラウザが操作→サーバ書き込み
問題
悪さサイトが送り出す→ブラウザが操作（しなくてもいい）→サーバーＸ
ＸＳＳとの違い
クロスサイト リクエスト フォージェリーはサーバーに入ったところで悪さ
ＸＳＳは、サーバーに入った後、ブラウザで悪さする
Ｃｏｏｋｉｅを他者がみる
document.cookie
ここに代入されてしまうと、Cookieを入れられてしまう。
ところが、HTTPレスポンスにsecureをつけると、だいにゅうできない。
ところがＰＨＰは(WebSphereも)、
ブラウザからセッションＩＤを使えた（セッションあだぷしょん）。
→悪いヒトが、セッションＩＤを送りつけると・・・
（ＮＩＩで開催）にいってきた！
その内容をメモメモ
・ＩＰＡのセキュア公開資料
脆弱性を前倒しで論点を挙げている
やさしい論点が後になる
■導入：ＨＴＴＰプロトコル
・Ｗｅｂアプリケーション
まあ、せつめいしなくてもいい
・使われるプログラミング言語の例
サーバー
ＲｏＲに刺激されＣａｋｅ，Ｄｊａｎｇｏ・・・
クライアント
Ｄａｒｔ，ＴｙｐｅＳｃｒｉｐｔ
JQuery
大きなことが抜けている
・攻撃は通信から入ってくる
ＨＴＴＰプロトコル
・ＨＴＴＰの通信を観察する
ローカルプロキシ：リクエストの監視、改変
ＤＷＡＳＰ・ＺＡＰ・Ｆｉｄｄｌｅｒなど
・ＨＴＴＰ通信の観察
ＭＩＭＥメッセージの一種
・ＰＯＳＴメソッド
・舞台裏は単純なテキストのやり取り
→いくらでも捏造、改変できる
■ＳＱＬインジェクション：シンプルな攻撃
・攻撃の流れ
入力パラメータにＳＱＬ文字列を使い、データを破壊する
・被害
ＤＢの中身を読み出される
定義も
ＲＤＢＳの種類、バージョンがわかる
情報の改ざん→データ破壊
サーバーのっとり
・やりかた
パスワードを' or 'a'='a とする
・悪さをする特殊企業
'
;
スペース ＳＱＬサーバー
-- コメント
\ 特殊記号：エスケープを乗り越える
・対策
ＳＱＬ文の発行を半自動化してくれる道具を使う
よい道具
Ｏ／Ｒマッパ
言語に統合されたクエリ（ＬＩＮＱ、ＰＬ／ＳＱＬ）
プリペアド・ステートメント
次善の策
特殊記号をエスケープする
・Ｏ／Ｒマッパー
ＲｏＲ ＡｃｔｉｖｅＲｅｃｏｒｄ
Ｇｒａｉｌｓ ＧＯＲＭ
Ｃａｋｅ Ｍｏｄｅｌ
Ｓｐｒｉｎｇ Ｓ２ＪＤＢＣ，Ｈｉｂｅｒｎｅｔａ
・ＳＱＬ注入のポイント
ＳＱＬ文を発行してデータベースへアクセス
ＳＱＬの構文を攻撃者にいじられない
■スクリプト注入
ブラウザ側を攻撃
・典型的にはＸＳＳ
ＨＴＭＬの文字列を貼り付けられると、
・偽ページ：
セッションのっとり
・攻撃方法
・攻撃パターン
スタイルタグなどもあぶない：いろいろな手口
・対策１：scriptタグを抑止
対策２：ＵＲＬ属性の無害化
・バリエーション
蓄積されたデータ内
ＤＯＭ型（ＡＪＡＸ）
■セッションメカニズムとユーザー認証について
・ＨＴＴＰはステートレス
セッションで
セッションＩＤ運び方３種類
ＵＲＬリライティング
ＰＯＳＴデータ
クッキー
■セッションハイジャック
・ＳＳＬで暗号化していても、セッションハイジャックは
起こる可能性はある
→証明書を使わない限り、なりすましはできる
・被害
なんでもできる
金銭被害
情報漏えい
業務妨害
・悪い例
ある種のフレームワーク
ログイン前とログイン後で同じセッションＩＤを使っている場合
「推測」への対応
→処理系が作ってくれるので、それを使う
ログイン、ユーザー認証成功のたびに異なる値を使う
「奪取」の対応
ＳＳＬなどを使う
Ｃｏｏｋｉｅにセキュア属性
Ｃｏｏｋｉｅの寿命を短くする
ログイン成功時のＣｏｏｋｉｅを発行しなおす
・セッションハイジャックのポイント
発行と運用にかかわる
他人が入ってくる
対策：「推測」されない「奪取」されない
■セッションフィクセーション
（セッションＩＤのお膳立て）
・攻撃の流れ
攻撃者はＣｏｏｋｉｅを取得し、
ユーザーにそのＣｏｏｋｉｅを送りつけると
攻撃者が知っているＣｏｏｋｉｅでログインすることになる
→付け替えないから
あとは、セッションハイジャックと同じ
・対策
ログインしたとき、新しいセッションＩＤにする
■アクセス認可の実装
・失敗パターン
メニューにないページにアクセスできる
ＵＲＬをたたくと画面が出てくる
他者の所有データにアクセスできる
ＩＤに連番のキーの場合
・対策
ページごとに、保護するロジック
オブジェクトのオーナーを確かめる
・より一般的：ＰＥＰ
保護すべきもの：Ｗｅｂページ
問い：今ログインしているユーザーは
その対象へアクセスする権限をもつか
■ほかの論点
・セキュア・プログラミング講座
Ｗｅｂアプリケーション編
に書いてある
要件定義で考えないといけないもの
設計でもいいもの
実装でも間に合うもの
クロスサイト リクエスト フォージェリー
正常
サーバーが送りだす→ブラウザが操作→サーバ書き込み
問題
悪さサイトが送り出す→ブラウザが操作（しなくてもいい）→サーバーＸ
ＸＳＳとの違い
クロスサイト リクエスト フォージェリーはサーバーに入ったところで悪さ
ＸＳＳは、サーバーに入った後、ブラウザで悪さする
Ｃｏｏｋｉｅを他者がみる
document.cookie
ここに代入されてしまうと、Cookieを入れられてしまう。
ところが、HTTPレスポンスにsecureをつけると、だいにゅうできない。
ところがＰＨＰは(WebSphereも)、
ブラウザからセッションＩＤを使えた（セッションあだぷしょん）。
→悪いヒトが、セッションＩＤを送りつけると・・・