https://d-cube.connpass.com/event/59762/

1. 春の脆弱性祭り
〜 基本的なWebアプリの脆弱性について、
もう一度勉強し直してみた 〜
2017/06/28
HRMOSプロダクト開発部 小山 健太 (kenta koyama)
1

2. 自己紹介
• サーバサイドエンジニアで、今はScalaで開発しています
• 前職
• データ分析・管理関係のミドルウェアの構築（所謂BI・ETLや機械学習製品等）、
およびそれを使用したアプリケーション開発
• 現職
• BizReachにて戦略人事クラウドHRMOS（ハーモス）の開発
• レポート機能
• 決済機能
• データ連携機能
2

3. 宣伝 （1ページだけおつきあいくださいませ…）
• 「HRMOS 採用管理」
参考：戦略人事クラウド https://hrmos.co/ 3

4. 発表のモチベーション
• 脆弱性の仕組みについて一度理解しても
その後触れる機会がないため忘れてしまう
きちんと理解するためには、
1. 学ぶの反復（たまにWebの記事で読むだけではなく）
2. 別の観点からの学び（具体的な攻撃方法を元に学び）
3. 俯瞰的に学ぶこと（IPAがまとめたガイドラインを）
が必要だと感じた
• 常に意識をしておかなければ脆弱性は発生し得るため、
きちんと理解したほうが良いという意識
4

5. 社会背景
• 脆弱性は悪用できるバグ
• 未対策はベンダーの重過失
• 2011年4月あるECサイトからクレカ情報が漏洩し、
開発ベンダーがサイト運営企業に2000万円超の賠償金を支払う
事件があった
• 仕様書で脆弱性対策が指示されていなかったにもかかわらず
ベンダーの重過失となった
• 契約書に損害賠償責任制限を記載していたが、それを超える賠償金の
支払が命じられた
• 教訓
• ベンダーは自衛のためにも発注者からの要求はなくても
最低限のセキュリティ対策を実施する必要あり
• IPAの注意喚起を根拠とした判決なので、IPAが公開している程度の脆弱性は知るべき
事件情報 引用元：徳丸浩のWebセキュリティ教室 3-4章 5

6. 発表の構成
• 各個別の基礎的な脆弱性について以下の点を説明
• 脆弱性の概要
• 攻撃例
• 脆弱性が生まれる技術的仕組み
• 対策
• 脆弱性全般に対しての傾向や対策方針がないか考えてみる
6

7. 参考資料
• 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生ま
れる原理と対策の実践（徳丸 浩 (著) 2011）
• 徳丸浩のWebセキュリティ教室（徳丸 浩 (著) 2015）
• 安全なWebサイトの作り方 改訂第7版（IPA （情報処理推進機構））
https://www.ipa.go.jp/security/vuln/websecurity.html ）
• Web健康診断仕様 第1版（IPA （情報処理推進機構））
※資料URLは上記と同一
7

8. アンケート
• Q1. セキュリティについてどの程度ご存知でしょうか？
• XSS, CSRF, SQL Injectionと聞いて…
1. 初めて聞いた
2. 聞いたことはある
3. 3つとも仕組みを含めて説明できる
• Q2.ご職業
1. Webエンジニア
2. IT部門・ベンダー等で、セキュリティ環境構築・製品導入
3. IT部門・ベンダー等で、セキュリティポリシーなどを作成
4. セールスエンジニア等、ビジネス面でセキュリティに関与
5. その他
8

9. 最初はこちら
•SQLインジェクション
9

10. 【脆弱性1/10】 SQLインジェクション
10
危険度 高
攻撃スタイル 能動的（攻撃者が直接攻撃を行う）
想定被害
情報漏洩 ◯
改竄 ◯
妨害 ◯
IPAへの届出状況 多い。
届出受付開始から 2014 年第 4 四半期までの、
ウェブサイト脆弱性の届出件数の 11% がこれに相当。

11. 【脆弱性1/10】 SQLインジェクション
• 攻撃デモ
• https://vulnerability-attack-demos.herokuapp.com/static_pages/sql_injection
11

12. 仕組み解説
• ただの名前からユーザを検索する処理のはずが…
• ソースコード内から実行しているSQL
(nameには「田中」など、外部から入力された値が入る)
SELECT * FROM users WHERE name = '${name}';
• データ削除のSQLになる
SELECT * FROM users WHERE name = ‘田中’; DROP table users; -- ’
12
nameに「田中‘; DROP table users; -- 」を入れると…

13. 有名な事件（ジョーク??）
• 国内では色々と実被害が発生しているようです
https://ja.wikipedia.org/wiki/SQL%E3%82%A4%E3%83%B3%E3%82%B8%E3%82%A7%E3%82%AF%E3%
82%B7%E3%83%A7%E3%83%B3
13

14. 簡易診断方法
• Inputとなりうる箇所に以下のような値を入れる
1. 「’」（シングルクオート1つ）
2. 「検索キー」での結果と、 「検索キー‘and’a‘=’a」 での結果を比較
14

15. 発生し得る脅威
15
脅威 1. データベースに蓄積された非公開情報の閲覧
2. データベースに蓄積された情報の改竄・消去
3. 認証回避による不正ログイン
4. ストアド・プロシージャを利用したOSコマンドの実行
（システムの乗取り、他への攻撃用の踏み台として利用）
注意が必要な
WEBサイトの
特徴
データベースを利用するWebアプリ全てに存在しうる問題。
個人情報等の重要情報をDBに格納しているサービスは、特に注
意が必要。

16. 対策
16
根本的解決 1. SQL組み立て処理はセキュアに行う
• 静的プレースホルダー（脆弱性の可能性ゼロ）
• 動的プレースホルダー（ライブラリにバグが無ければ大
丈夫）
• SQL文のエスケープ
2. InputとなるパラメータにSQL文を直接指定しない
保険的対策 3. エラーメッセージをそのままブラウザに表示しない
4. DBアカウントに適切な権限を与える

17. 2番手は…
•XSS（クロスサイト・スクリプティング）
17

18. 【脆弱性2/10】 XSS（クロスサイト・スクリプティング）
18
危険度 中
攻撃スタイル 受動的（攻撃には被害者ユーザの関与が必要）
想定被害
情報漏洩 ◯
改竄 △
妨害 ー
IPAへの届出状況 多い。
届出受付開始から 2014 年第 4 四半期までの
ウェブサイトの届出件数の約 5 割がこれに相当。

19. 【脆弱性2/10】 XSS（クロスサイト・スクリプティング）
• 攻撃デモ
• https://vulnerability-attack-demos.herokuapp.com/static_pages/xss
19

20. 仕組み解説
• URL/入力フォーム等のInput値を画面上でそのまま表示することで
発生
• 任意のJavascriptがページ内に差し込まれ実行される
• 任意のHTMLがページ内に差し込まれ表示される
• ⇒ データ表示時のエスケープ漏れが問題！！
20

21. 全体的な攻撃の流れ
引用元：IPA安全なWebサイトの作り方 https://www.ipa.go.jp/files/000017316.pdf 21

22. 有名な事件??
https://togetter.com/li/1106226 22

23. 簡易診断方法
• Inputとなりうる箇所に以下のような値を入れる
1. ’>”><hr>
2. '>"><script>alert(document.cookie) </script>
3. <script>alert(document.cookie) </script>
4. javascript:alert(document.cookie);
23

24. 発生し得る脅威
24
脅威 1. 本物サイト上に偽のページが表示される
1. 偽情報の流布による混乱
2. フィッシング詐欺による重要情報の漏えい
2. ブラウザが保存している Cookie を取得される
1. Cookie にセッション ID が格納されている場合
さらに利用者へのなりすましにつながる
2. Cookie に個人情報等が格納されている場合
その情報が漏えいする
3. 任意の Cookie をブラウザに保存させられる（セッション固
定化攻撃）
注意が必要な
WEBサイトの
特徴
あらゆるサイト。

25. 対策
本当はもっと色々あります！ 詳細は、 https://www.ipa.go.jp/files/000017316.pdf 25
根本的解決 1. ウェブページに出力する全ての要素に対して
エスケープ処理を施す。
2. URLを画面出力するときは、URL形式の値のみを許可
3. <script>…</script>要素の内容を動的に生成しない
4. レスポンスヘッダの Content-Typeフィールドに
文字コード指定
保険的対策 5. 入力値の内容チェック
6. Cookie情報の漏えい対策として、CookieにHttpOnly属性
7. レスポンスヘッダにX-XSS-ProtectionやContent-Security-Policyを
追加。

26. お次は…
•CSRF（クロスサイト・リクエストフォージェリ）
26

27. 【脆弱性3/10】 CSRF（クロスサイト・リクエストフォージェリ）
27
危険度 中
攻撃スタイル 受動的（攻撃には被害者ユーザの関与が必要）
想定被害
情報漏洩 △
改竄 ◯
妨害 ◯
IPAへの届出状況 ウェブサイトの届出全体に占める割合は１パーセント未満。
但し2006 年頃から継続的に届出を受けている。

28. 【脆弱性3/10】 CSRF（クロスサイト・リクエストフォージェリ）
• 攻撃デモ
• https://vulnerability-attack-demos.herokuapp.com/static_pages/csrf
28

29. 仕組み解説
• 正規サイトAにログインする
• ログインセッションがある状態になる
• そのままブラウザの別タブで罠サイトにアクセス
• 罠サイト上の処理で、正規サイトAへ重要な処理を行うアクセスを
送信される
• 例：決済処理、パスワード変更処理、メール送信
29

30. 全体的な攻撃の流れ
引用元：IPA安全なWebサイトの作り方 https://www.ipa.go.jp/files/000017316.pdf 30
XSSとの違いは、
5の後があるかどうか
（XSSの場合、5の後に返る
HTMLファイルによりユーザ
に攻撃を行う）

31. 有名な事件
• ぼくはまちちゃん！事件
• 2005年ごろ、ソーシャル・ネットワーキングサイトの「mixi」で
URLをクリックすると勝手に「ぼくはまちちゃん！ 」という
タイトルで日記がアップされてしまうという現象が多発した。
http://www.itmedia.co.jp/enterprise/articles/0504/23/news005.html 31

32. 簡易診断方法
• ログイン状態において、特定副作用を持つ画面に対して
外部からパラメータ を強制する
（この際に、Referer が送 出されないように抑止する）
32

33. 発生し得る脅威
33
脅威 • 不正な送金
• 商品購入
• 退会処理
• 掲示板への書き込み
• ユーザ設定変更（パスワード等）
注意が必要な
WEBサイトの
特徴
Cookie, Basic認証, SSLクライアント認証等でセッション管理を実
装しているサイト。
特に金銭処理が発生するサイトは注意が必要。

34. 対策
https://www.ipa.go.jp/files/000017316.pdf 34
根本的解決 1. 処理実行ページを POST メソッドでアクセスするようにし、
その「hidden パ ラメータ」に秘密情報（セッションID・トー
クン等）が挿入されるよう前のページを自動生成。
実行ページで はその値が正しい場合のみ処理を実行。
2. 処理実行直前のページでパスワードの再入力を求める
3. Refererが正しいリンク元か確認し、正しい場合のみ処理実行
（注：但しブラウザやパーソナルファイアウォール等の設定
で Referer を送信しないユーザがアクセスできなくなる）
保険的対策 4. 重要な操作を行った際に、その旨を登録済みのメールアドレ
スに自動送信する

35. 一息入れて簡単なものを…
•Click Jacking
35

36. 【脆弱性4/10】 Click Jacking（クリック・ジャッキング）
注：危険度、攻撃スタイル、想定被害については発表者本人の意見。
IPAへの届け出状況は https://www.ipa.go.jp/files/000017316.pdf より引用。
36
危険度 中
攻撃スタイル 受動的（攻撃には被害者ユーザの関与が必要）
想定被害
情報漏洩 △
改竄 ◯
妨害 ◯
IPAへの届出状況 2011 年に初めて受け付け。
ウェ ブサイトの届出全体に占める割合は、1 パーセント未
満と多くはない。
しかし2011 年から継続して届出を受けている。

37. 【脆弱性4/10】 Click Jacking（クリック・ジャッキング）
• 攻撃デモ
• https://vulnerability-attack-demos.herokuapp.com/static_pages/click-jacking
• TODO: デモサイトでも攻撃可能にする
37

38. 仕組み解説
画像は https://www.ipa.go.jp/files/000017316.pdf より引用 38

39. 全体的な攻撃の流れ
引用元：IPA安全なWebサイトの作り方 https://www.ipa.go.jp/files/000017316.pdf 39

40. 発生し得る脅威
40
脅威 • ログイン後の利用者がマウス操作のみで実行可能な処理
• 例
• Facebookの記事シェア
• 退会処理
• プロフィール公開範囲の変更
注意が必要な
WEBサイトの
特徴
• マウス操作のみで実行可能な重要な処理があるサイト

41. 対策
https://www.ipa.go.jp/files/000017316.pdf 41
根本的解決 1. HTTPレスポンスヘッダに、X-Frame-Options ヘッダフィール
ドを出力し、他ドメ インのサイトからの frame 要素や iframe
要素による読み込みを制限する。
2. 重要処理を実行する直前のページでパスワードの再入力を求
める
保険的対策 3. 重要な処理は一連の操作をマウスのみで実行できないように
する

42. ここから先は似たもの同士をまとめ
さらっと流していきます
•外部からのInputパラメータにより
引き起こされる攻撃群
•OSコマンドインジェクション
•ディレクトリトラバーサル
•オープンリダイレクタ
42

43. 【脆弱性5/10】 OSコマンドインジェクション
43
危険度 高
攻撃スタイル 能動的
想定被害
情報漏洩 ◯
改竄 ◯
妨害 ◯
IPAへの届出状況 Perl で開発されたウェブアプリケーションや、組み込み製
品 の管理画面で使用される CGI プログラム等のソフトウェ
ア製品の届け出が多い模様。

44. 仕組み解説
• URL、Form等の外部からのInputパラメータにOSコマンドを指定
• ⇒それがサーバ側で実行される
44

45. 発生し得る脅威
45
脅威 • サーバ内ファイルの閲覧、改ざん、削除
• 意図しない OS のシャットダウン、ユーザアカウントの追加、
変更
• ウイルス、ワーム、ボット等への感染、バックドアの設置
• 他のシステムへの攻撃の踏み台
注意が必要な
WEBサイトの
特徴
シェルを起動できる言語機能が利用できるサイト。

46. 対策
https://www.ipa.go.jp/files/000017316.pdf 46
根本的解決 1. シェルを起動できる言語機能の利用を避ける。
保険的対策 2. シェルを起動できる言語機能を利用する場合は、その引数を
構成する全ての変数に 対してチェックを行い、あらかじめ許可
した処理のみを実行する。

47. 【脆弱性5/10】 OSコマンドインジェクション
47
危険度 高
攻撃スタイル 能動的
想定被害
情報漏洩 ◯
改竄 ◯
妨害 ◯
IPAへの届出状況 Perl で開発されたウェブアプリケーションや、組み込み製
品 の管理画面で使用される CGI プログラム等のソフトウェ
ア製品の届け出が多い模様。

48. 仕組み解説
• URL、Form等の外部からのInputパラメータにOSコマンドを指定
• ⇒それがサーバ側で実行される
48

49. 発生し得る脅威
49
脅威 • サーバ内ファイルの閲覧、改ざん、削除
• 意図しない OS のシャットダウン、ユーザアカウントの追加、
変更
• ウイルス、ワーム、ボット等への感染、バックドアの設置
• 他のシステムへの攻撃の踏み台
注意が必要な
WEBサイトの
特徴
シェルを起動できる言語機能が利用できるサイト。

50. 対策
https://www.ipa.go.jp/files/000017316.pdf 50
根本的解決 1. シェルを起動できる言語機能の利用を避ける。
保険的対策 2. シェルを起動できる言語機能を利用する場合は、その引数を
構成する全ての変数に 対してチェックを行い、あらかじめ許可
した処理のみを実行する。

51. 【脆弱性6/10】 ディレクトリトラバーサル
51
危険度 低〜高
攻撃スタイル 能動的
想定被害
情報漏洩 ◯
改竄 ー
妨害 ー
IPAへの届出状況 ウェブサイトの届出全体に占める割合は、数パーセントと
多くはないが、受付開始当初から継続して届け出がある。

52. 仕組み解説
• URL、Form等の外部からのInputパラメータに
ウェブサーバ内のファイル名を直接指定
52

53. 発生し得る脅威
53
脅威 • サーバ内ファイルの閲覧、改ざん、削除
• 重要情報の漏えい
• 設定ファイル、データファイル、プログラムのソース
コード等の改ざん、削除
注意が必要な
WEBサイトの
特徴
• 外部からのパラメータにウェブサーバ内のファイル名を直
接指定しているウェブアプリケーション
• 例：
• ウェブページのデザインテンプレートをファイルから
読み込む
• 利用者からの入力内容を指定のファイルへ書き込む

54. 対策
https://www.ipa.go.jp/files/000017316.pdf 54
根本的解決 1. 外部からのパラメータでウェブサーバ内のファイル名を直接
指定する実装を避ける
2. ファイルを開く際は、固定のディレクトリを指定し、かつ
ファイル名にディレクトリ名が含 まれないようにする
保険的対策 3. ウェブサーバ内のファイルへのアクセス権限の設定を正しく
管理する
4. ファイル名のチェックを行う

55. 【脆弱性7/10】 オープンリダイレクタ
• IPA資料内に情報が少なかったため、
個人で調査した結果をメインに記載します
55

56. 仕組み解説
• URL等のパラメータに別のサイト内URLを直接指定し、
リダイレクトさせる処理において発生する脆弱性
• ⇒ 外部サイトのURLを指定され、外部サイトにリダイレクトさせる攻撃
フィッシング手法により個人情報が盗まれる危険性。
56

57. 具体的な攻撃方法
• ログイン後に、サイト内の別ページに飛ばす処理などが危ない
57
https://example.com/login.php?url=/contents.php
ID
PASS
Login

58. 具体的な攻撃方法
• Step1: 罠として「https://example.com/login.php?url=https://trap.com/」などのリ
ンクを踏ませる
• あくまでアクセスするサイトはexample.comなので、ユーザは安心してアクセスする
58
https://example.com/login.php?url=https://trap.com/
ID
PASS
Login

59. 具体的な攻撃方法
• Step2: ログイン成功するとリダイレクトされる。それを利用し
見た目がログイン画面と同じフィッシングサイトに誘導
• 見た目が同じだとユーザは気づかない
59
https://trap.com/
ID
PASS
Login
エラー：IDかパスワードのいずれかが誤っています。再度ログインください。

60. 具体的な攻撃方法
• Step3: ID/PASSが入力される
60

61. 対策
体系的に学ぶ 安全なWebアプリケーションの作り方 4.7.3 リダイレクト処理にまつわる脆弱性のまとめ 61
1.リダイレクト先は固定にする（例：決まった番号で指定）
2.外部から指定されたURLの文字種とドメイン名をチェック

62. 似たもの2つを本当に簡単に流して
説明します
•外部からのInputパラメータがリクエスト
ヘッダに挿入されることにより
引き起こされる攻撃群
•HTTPヘッダーインジェクション
•メールヘッダインジェクション
62

63. 【脆弱性8 & 9 / 10】概要
• 画面からの入力値をHTTPレスポンスヘッダーやMailヘッダーに入れ
たいケースがある
• HTTPレスポンスヘッダー
• リダイレクトの実装として、ジャンプ先の URL 情報をLocation ヘッダに入れる
• 名前情報等をSet-Cookieヘッダーに入れる
• Mailヘッダー
• 画面上で、To, From, CCなどを指定する
• 改行コードを入れることで、レスポンスを分割・改竄できる
• 任意のHTTPレスポンス、Mailを作成
• （HTTPレスポンスのキャッシュ制御関連のヘッダを利用して）
キャッシュサーバにキャッシュさせ、コンテンツ汚染
63

64. ちょっと毛色が違う、少し広い話になります
•認証
•認可
64

65. 認証と認可の違い
• 認証（Authentication）
• 通信相手が誰であるか確認すること
例）Googleへのログイン処理
• 認可（Authorization）
• 通信相手に対し、リソースアクセスの権限を与えること
例）GoogleDocumentの参照権限
65

66. 認可に関連する脆弱性
• URL直指定でアクセスできてしまう
• 例：https://example.com/public にしかアクセスできない人が、
https://example.com/secret を指定して直アクセス
• パラメータの変更によりアクセス不可能なデータにアクセス可能
• 例：https://example.com/user/1 にアクセスできる人が、
https://example.com/user/2 を指定して直アクセス
• hiddenパラメータやCookieに権限情報を入れている
• 例：Cookie: userKind=admin
66

67. 認証に関連する脆弱性
• ログイン情報に関して
• 総当たり攻撃でID/PASSなどのログイン情報の組み合わせを当てられる
• 辞書攻撃（使用頻度が高いパスワードを順に試す）
• ジョーアカウント探索（アカウント名・パスワードが同一の組み合わせを試す）
• 逆総当たり攻撃（パスワードを固定し、ユーザIDを入れ替えて試す）
• セッションに関して
• セッションIDを盗聴され、使用される（セッション・ハイジャック）
• 指定のセッションIDを使用させられる（セッション固定化攻撃）
67

68. ログイン処理において気をつけること(1/2)
• 総当たり攻撃などでログイン突破されないようにするため
Webサービス事業者側は以下の事項に気をつける
• 文字数下限を設ける（例：8文字以上）
• 使用できる文字種の幅を広くとる（例：英数記号）
• 入力後の応答メッセージがヒントとならないようにする
（例：「IDまたはPASSWORDが誤っています」）
• アカウントロック機能を設ける（例：10回間違えると30分ログイン不可）
• ログインIDの秘匿（例：非公開情報であるメアドをIDとして使用）
• ログインフォームページからHTTPSを使用
68

69. ログイン処理において気をつけること(2/2)
• パスワードの保存に関しては以下の点に注意
• 平文ではなく、ハッシュ値を保存
• 但し、ハッシュ値がバレた場合もオフラインの総当たり攻撃で元文がバレる
• ⇒ソルトをつける
＜ソルトの要件＞
• ある程度の長さを確保（20文字程度）
• ユーザごとに異なるものにする
• 例：乱数やユーザIDを使用
• ⇒総当たり攻撃への対処として、ハッシュの計算時間を長くするため、
ストレッチングも実行（例：1000回）
69

70. セッション・ハイジャック
• 以下の不備があった場合はセッションが盗まれる可能性がある
• セッションIDが予測可能
• 例：Cookie: sessId=1357
• セッションIDを保持するCookieがsecure=true でない
• HTTPSではなくHTTPの画面があった場合、Cookieが送信されてしまう
• セッションIDをURLやhiddenパラメータに埋め込む
• URLの場合はReferrerから流出する可能性あり
• hiddenパラメータの場合はXSSにより流出する可能性あり
⇒保険的対策として、CookieのhttpOnly=trueだった場合はjavascriptからCookieにアクセ
スできなくなるため、XSSがあってもセッションが盗まれるのだけは防げる！
70

71. セッション固定化攻撃
• 以下の不備があった場合は、セッション固定化攻撃が成立し得る
• クッキーモンスター問題
• XSS脆弱性
• HTTPヘッダインジェクション脆弱性
71

72. セッションに関する攻撃の保険的対策
• ログイン時にはセッションを再生成
• ログアウト時にはセッションを破棄
• 重要な処理の前にはパスワードを入力させる
72

73. 最後に小話
•こんなのも脆弱性として認められてるみた
いです
•クローラへの耐性
IPA ウェブ健康診断 https://www.ipa.go.jp/files/000017319.pdf 73

74. 総括
• 外部からのInputパラメータが、システムが使用する変数
（SQL、URL、HTTP Header、Mail Header、OSコマンド等々）
となるときは必ず何かしらの脆弱性が発生し得ると考える
• とはいえ、実装時は気付かずに脆弱性を入れてしまうものですが…
• フレームワークの推奨機能になるべく乗っかり、独自実装をできるだけ避ける
• ごくごく普通の結論になってしまいました…
• スキルが一様でない大人数の開発だと脆弱性ゼロは難しい気もするので、
もう外部業者にセキュリティ調査依頼したほうが良いのでは？
• 注：超個人的意見です
74

75. •ご清聴ありがとうございました。
75