第35回 脆弱性診断ええんやで(^^)
「脆弱性診断って何をどうすればいいの?」
(おかわり)
脆弱性診断研究会
株式会社トレードワークス セキュリティ事業部
Agenda
u 脆弱性診断研究会とは
u ⾃⼰紹介
u OWASPって何?
u 診断対象⾒積りの考え⽅
u 質疑応答
脆弱性診断研究会とは
株式会社トレードワークスのセキュリティ事業部にて運営
Webアプリケーションやネットワーク機器などに対するセキュリティ診断
の最新⼿法や診断ツール使⽤法の勉強や研究をするためのコミュニティ
コワーキングスペース茅場町 Co-Edo(コエド)様にて第1回セミナーを
2014年8⽉に開催して以来、2016年1⽉現在で31回のパブリックセミナー
を実施
クライアント向けプライベートセミナーは年に数回実施
⾃⼰紹介
松本 隆則 (まつもと たかのり)
u 株式会社トレードワークス セキュリティ事業部
https://security.twroks.co.jp/
u Facebook
https://www.facebook.com/nilfigo
u Twitter
https://twitter.com/DYOH2017
⾃⼰紹介
u 脆弱性診断研究会 管理⼈・セミナー講師
Ø Facebook 公開グループ
https://www.facebook.com/groups/zeijakusei.shindan.kenkyukai/
Ø Facebookコミュニティ
https://www.facebook.com/sec.testing.study.session/
Ø セミナー・イベント管理サイト
https://security-testing.doorkeeper.jp/
http://security-testing.connpass.com/
⾃⼰紹介
u OWASP JAPAN プロモーションチーム(new!)
Ø https://www.owasp.org/index.php/Japan
Ø http://blog.owaspjapan.org/
OWASPって何?
The Open Web Application Security Project
Let's know OWASP!
https://speakerdeck.com/owaspjapan/lets-know-owasp-number-bpstudy20160226
⼯程別活⽤可能な資料・ツールの紹介
https://speakerdeck.com/owaspjapan/owasp-contents-reference
OWASPの歩き⽅
https://speakerdeck.com/owaspjapan/what-is-owasp-20160319innovationegg7th
診断対象⾒積りの考え⽅
⾼いのか安いのかわからん
と評判の脆弱性診断のサー
ビス価格の根拠ってなに?
診断対象⾒積りの考え⽅
⾒積りする前に、ある程度
脆弱性診断の仕組みを把握
しておけばイロイロ捗る!
診断対象⾒積りの考え⽅
サービス価格⾒積り根拠の
⼀つである診断対象数の数
え⽅が今回のテーマです。
診断対象⾒積りの考え⽅
「診断リクエスト」
↓
パラメーターを伴うリクエスト
パラメーター送信⽅法
1. クエリー⽂字列(Query string)
2. HTTPリクエストボディ(POST)
3. ⾮同期通信
4. HTTPリクエストヘッダー
5. URLの⼀部がパラメーター
パラメーター送信⽅法
1. クエリー⽂字列(Query string)
2. HTTPリクエストボディ(POST)
3. ⾮同期通信
4. HTTPリクエストヘッダー
5. URLの⼀部がパラメーター
1. クエリー⽂字列
http://zsk.example/index.php?user=test&pswd=t
est
診断対象パラメーター
• user
• pswd
1. クエリー⽂字列 例1
a.http://zsk.example/index.php?
page=info.php&user=test&pswd=test
b.http://zsk.example/index.php?
next=info.php&user=test&pswd=test
aとbは[page]と[next]パラメーターが異なるため、⼀般的
にはそれぞれ独⽴した診断リクエストとして数えます。
1. クエリー⽂字列 例2
c.http://zsk.example/index.php?
page=info.php&user=test&pswd=test
d.http://zsk.example/index.php?
user=test&pswd=test&page=info.php
cとdは⼀⾒異なるパラメーター群に⾒えますが、並び順が異
なるだけで含まれているパラメーターは同⼀なため、ひとつ
の診断リクエストとして数えます。
パラメーター送信⽅法
1. クエリー⽂字列(Query string)
2. HTTPリクエストボディ(POST)
3. ⾮同期通信
4. HTTPリクエストヘッダー
5. URLの⼀部がパラメーター
2. HTTPリクエストボディ
画⾯上のフォーム
POST http://zsk.example/index.php?page=login.php HTTP/1.1
...
...
...
username=test&password=test&login-php-submit-button=Login
3. ⾮同期通信
裏でこっそりサーバーに接続して、HTMLやXML、
JSONなどを取得して画⾯上に反映したりこっそり
データを保存したり。
例)
• 住所⾃動⼊⼒フォーム(郵便番号で検索)
• プルダウンリスト群の項⽬を⾃動変更
パラメーター送信⽅法
1. クエリー⽂字列(Query string)
2. HTTPリクエストボディ(POST)
3. ⾮同期通信
4. HTTPリクエストヘッダー
5. URLの⼀部がパラメーター
4. HTTPリクエストヘッダー
上記の[Host]や[User-Agent]、[Cookie]といったHTTPリク
エストヘッダーも診断対象パラメーターです。
ただし、実際に診断するかどうかはヘッダーの種類やWebア
プリケーションの仕様により異なります。
GET /index.php?page=login.php HTTP/1.1
Host: zsk.example
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja
Accept-Encoding: gzip, deflateDNT: 1
Referer: http://hoge/index.php?page=home.php&popUpNotificationCode=HPH0
Cookie: showhints=0; PHPSESSID=ddor943kfutdlp0dqu73va6io3
Connection: keep-alive
4. HTTPリクエストヘッダー 例1
Cookieヘッダー
n ログイン処理が存在する
Cookieにセッション情報を管理するための⽂字列(セッ
ションID)が含まれることが多いため診断いたします。
n ログイン処理が存在しない(検索やお問い合わせなど)
Cookieが発⾏されていてもWebアプリケーション内部で
使⽤していない可能性があるため診断対象としないことが
あります。
4. HTTPリクエストヘッダー 例2
User-Agentヘッダー
サーバーへのアクセスがどのようなブラウザからであるかを
識別するために当ヘッダーを使⽤することがあります。識別
した結果、画⾯のレイアウトやメニュー構成などが変化する
場合は診断対象となります。
識別対象の例
• パソコン
• スマートフォン
• フィーチャーフォン(ガラケー)
パラメーター送信⽅法
1. クエリー⽂字列(Query string)
2. HTTPリクエストボディ(POST)
3. ⾮同期通信
4. HTTPリクエストヘッダー
5. URLの⼀部がパラメーター
5. URLの⼀部がパラメーター
ユーザーの詳細情報を表⽰するためのURLの例です。
URLの⼀部に含まれている「123456」がユーザーIDを⽰しています。
そのため、この数字をパラメーターとみなして診断します。
敢えてクエリー⽂字列で表すと下記のような感じです。
http://zsk.example/user/detail/123456/
http://zsk.example/user/detail.php?id=123456
5. URLの⼀部がパラメーター 例1
aとbは、URLとしては異なりますが、ユーザーIDが異なるだけでWeb
アプリケーション内部では同⼀の処理と推測されるため、ひとつの診
断リクエストとして数えます。
ただし、リクエストの結果、⼤幅にメニュー構成やレイアウトなどが
異なる画⾯が表⽰される場合は、別の診断リクエストと⾒なす場合が
あります。
a. http://zsk.example/user/123456/detail/
b. http://zsk.example/user/987654/detail/
5. URLの⼀部がパラメーター 例2
cとdでは、[〜user/123456/]までは同⼀のURLですが、その後に続く
URLが異なるため、それぞれ別の診断リクエストとして数えます。
c. http://zsk.example/user/123456/detail/
d. http://zsk.example/user/123456/edit/
診断リクエストとパラメーター数の関係
作業⼯数やサービス価格の⾒積りのために
仮に下記のように定義します。
1 診断リクエスト ✕ 5基本パラメーター → 1.00 基本診断ユニット
【ご注意】
上記のパラメーター数は本セミナー⽤に定義した仮の数値です。
弊社および私⾃⾝が実際にこの数値に基いて⾒積もりしているわけではありません。
また、診断対象Webアプリケーションの性質により基本パラメーター数は変動します。
診断リクエストとパラメーター数の関係
1診断リクエスト ✕ 5基本パラメーター → 1.00 基本診断
上記の定義での算出例
1診断リクエスト ✕ 3パラメーター → 0.60 診断
1診断リクエスト ✕ 2パラメーター → 0.40 診断
1診断リクエスト ✕ 15パラメーター → 3.00 診断
合計 4.00 診断
診断リクエストとパラメーター数の関係
1診断リクエスト ✕ 3パラメーター → 0.60 診断
1診断リクエスト ✕ 2パラメーター → 0.40 診断
1診断リクエスト ✕ 15パラメーター → 3.00 診断
合計 4.00 診断
仮に1診断リクエストの単価が10,000円で診断⼯数が1⽇とすると、3診断リクエストの
場合は「30,000円・3⽇」となるはずですが、実際の⾒積りは「40,000円・4⽇」とな
ります。
お客様からすると「3画⾯なのに4画⾯分の料⾦と⼯数ってどういうこと!?」と不信に思
われるかもしれませんが、決してボッタクリではありません!
次回予告
診断前の準備について
• 診断⽤環境
• 実稼働環境
• 検証⽤環境
• 事前準備
• 事前の申請が必要かどうか(AWS、Azureなど)
• 診断⽤データ
• ユーザーアカウント(権限別に複数必要)
• サイト上で閲覧および更新するデータ
お問い合わせ先
株式会社トレードワークス セキュリティ事業部
https://security.tworks.co.jp/
メールアドレス
• セキュリティ事業部 <sec-pit@tworks.co.jp>
• 松本 隆則 <t.matsumoto@tworks.co.jp>

脆弱性診断って何をどうすればいいの?(おかわり)