春の脆弱性祭り 2017/06/13

春の脆弱性祭り

〜基本的なWebアプリの脆弱性について、もう一度勉強し直してみた〜

2017/06/28

HRMOSプロダクト開発部小山健太 (kenta koyama)

1

自己紹介

•サーバサイドエンジニアで、今はScalaで開発しています• 前職

• データ分析・管理関係のミドルウェアの構築（所謂BI・ETLや機械学習製品等）、およびそれを使用したアプリケーション開発

• 現職• BizReachにて戦略人事クラウドHRMOS（ハーモス）の開発

• レポート機能

• 決済機能

• データ連携機能

2

宣伝（1ページだけおつきあいくださいませ…）

•「HRMOS採用管理」

参考：戦略人事クラウド https://hrmos.co/ 3

発表のモチベーション

•脆弱性の仕組みについて一度理解してもその後触れる機会がないため忘れてしまう

きちんと理解するためには、

1. 学ぶの反復（たまにWebの記事で読むだけではなく）

2. 別の観点からの学び（具体的な攻撃方法を元に学び）

3. 俯瞰的に学ぶこと（IPAがまとめたガイドラインを）

が必要だと感じた

•常に意識をしておかなければ脆弱性は発生し得るため、きちんと理解したほうが良いという意識

4

社会背景

• 脆弱性は悪用できるバグ• 未対策はベンダーの重過失

• 2011年4月あるECサイトからクレカ情報が漏洩し、開発ベンダーがサイト運営企業に2000万円超の賠償金を支払う事件があった• 仕様書で脆弱性対策が指示されていなかったにもかかわらずベンダーの重過失となった

• 契約書に損害賠償責任制限を記載していたが、それを超える賠償金の支払が命じられた

• 教訓• ベンダーは自衛のためにも発注者からの要求はなくても最低限のセキュリティ対策を実施する必要あり

• IPAの注意喚起を根拠とした判決なので、IPAが公開している程度の脆弱性は知るべき

事件情報引用元：徳丸浩のWebセキュリティ教室 3-4章 5

発表の構成

•各個別の基礎的な脆弱性について以下の点を説明• 脆弱性の概要

• 攻撃例

• 脆弱性が生まれる技術的仕組み

• 対策

•脆弱性全般に対しての傾向や対策方針がないか考えてみる

6

参考資料

•体系的に学ぶ安全なWebアプリケーションの作り方脆弱性が生まれる原理と対策の実践（徳丸浩 (著) 2011）

•徳丸浩のWebセキュリティ教室（徳丸浩 (著) 2015）

•安全なWebサイトの作り方改訂第7版（IPA （情報処理推進機構））https://www.ipa.go.jp/security/vuln/websecurity.html）

• Web健康診断仕様第1版（IPA （情報処理推進機構））※資料URLは上記と同一

7

https://www.ipa.go.jp/security/vuln/websecurity.html

アンケート

• Q1. セキュリティについてどの程度ご存知でしょうか？• XSS, CSRF, SQL Injectionと聞いて…

1. 初めて聞いた2. 聞いたことはある3. 3つとも仕組みを含めて説明できる

• Q2.ご職業1. Webエンジニア2. IT部門・ベンダー等で、セキュリティ環境構築・製品導入3. IT部門・ベンダー等で、セキュリティポリシーなどを作成4. セールスエンジニア等、ビジネス面でセキュリティに関与5. その他

8

最初はこちら

•SQLインジェクション

9

【脆弱性1/10】 SQLインジェクション

10

危険度高

攻撃スタイル能動的（攻撃者が直接攻撃を行う）

想定被害

情報漏洩 ◯

改竄 ◯

妨害 ◯

IPAへの届出状況多い。届出受付開始から 2014 年第 4 四半期までの、ウェブサイト脆弱性の届出件数の 11% がこれに相当。

【脆弱性1/10】 SQLインジェクション

•攻撃デモ• https://vulnerability-attack-demos.herokuapp.com/static_pages/sql_injection

11

仕組み解説

•ただの名前からユーザを検索する処理のはずが…

• ソースコード内から実行しているSQL(nameには「田中」など、外部から入力された値が入る)SELECT * FROM users WHERE name = '${name}';

• データ削除のSQLになるSELECT * FROM users WHERE name = ‘田中’; DROP table users; -- ’

12

nameに「田中‘; DROP table users; --」を入れると…

有名な事件（ジョーク??）

•国内では色々と実被害が発生しているようです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

簡易診断方法

• Inputとなりうる箇所に以下のような値を入れる

1. 「’」（シングルクオート1つ）

2. 「検索キー」での結果と、「検索キー‘and’a‘=’a」での結果を比較

14

発生し得る脅威

15

脅威 1. データベースに蓄積された非公開情報の閲覧2. データベースに蓄積された情報の改竄・消去3. 認証回避による不正ログイン4. ストアド・プロシージャを利用したOSコマンドの実行（システムの乗取り、他への攻撃用の踏み台として利用）

注意が必要なWEBサイトの特徴

データベースを利用するWebアプリ全てに存在しうる問題。個人情報等の重要情報をDBに格納しているサービスは、特に注意が必要。

対策

16

根本的解決 1. SQL組み立て処理はセキュアに行う• 静的プレースホルダー（脆弱性の可能性ゼロ）• 動的プレースホルダー（ライブラリにバグが無ければ大丈夫）

• SQL文のエスケープ

2. InputとなるパラメータにSQL文を直接指定しない

保険的対策 3.エラーメッセージをそのままブラウザに表示しない

4. DBアカウントに適切な権限を与える

2番手は…

•XSS（クロスサイト・スクリプティング）

17

【脆弱性2/10】 XSS（クロスサイト・スクリプティング）

18

危険度中

攻撃スタイル受動的（攻撃には被害者ユーザの関与が必要）

想定被害

情報漏洩 ◯

改竄 △

妨害ー

IPAへの届出状況多い。届出受付開始から 2014 年第 4 四半期までのウェブサイトの届出件数の約 5 割がこれに相当。

【脆弱性2/10】 XSS（クロスサイト・スクリプティング）

•攻撃デモ• https://vulnerability-attack-demos.herokuapp.com/static_pages/xss

19

仕組み解説

• URL/入力フォーム等のInput値を画面上でそのまま表示することで発生• 任意のJavascriptがページ内に差し込まれ実行される

• 任意のHTMLがページ内に差し込まれ表示される

• ⇒データ表示時のエスケープ漏れが問題！！

20

全体的な攻撃の流れ

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

有名な事件??

https://togetter.com/li/1106226 22

簡易診断方法

• Inputとなりうる箇所に以下のような値を入れる

1. ’>”><hr>

2. '>"><script>alert(document.cookie) </script>

3. <script>alert(document.cookie) </script>

4. javascript:alert(document.cookie);

23


24

脅威 1. 本物サイト上に偽のページが表示される1. 偽情報の流布による混乱2. フィッシング詐欺による重要情報の漏えい

2. ブラウザが保存している Cookie を取得される1. Cookie にセッション ID が格納されている場合さらに利用者へのなりすましにつながる

2. Cookie に個人情報等が格納されている場合その情報が漏えいする

3. 任意の Cookie をブラウザに保存させられる（セッション固定化攻撃）


あらゆるサイト。

対策

本当はもっと色々あります！詳細は、 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を追加。

お次は…

•CSRF（クロスサイト・リクエストフォージェリ）

26

【脆弱性3/10】 CSRF（クロスサイト・リクエストフォージェリ）

27

危険度中


想定被害

情報漏洩 △

改竄 ◯

妨害 ◯

IPAへの届出状況ウェブサイトの届出全体に占める割合は１パーセント未満。但し2006 年頃から継続的に届出を受けている。

【脆弱性3/10】 CSRF（クロスサイト・リクエストフォージェリ）

•攻撃デモ• https://vulnerability-attack-demos.herokuapp.com/static_pages/csrf

28

仕組み解説

•正規サイトAにログインする• ログインセッションがある状態になる

•そのままブラウザの別タブで罠サイトにアクセス• 罠サイト上の処理で、正規サイトAへ重要な処理を行うアクセスを送信される• 例：決済処理、パスワード変更処理、メール送信

29



XSSとの違いは、5の後があるかどうか

（XSSの場合、5の後に返るHTMLファイルによりユーザ

に攻撃を行う）

有名な事件

•ぼくはまちちゃん！事件• 2005年ごろ、ソーシャル・ネットワーキングサイトの「mixi」で

URLをクリックすると勝手に「ぼくはまちちゃん！」というタイトルで日記がアップされてしまうという現象が多発した。

http://www.itmedia.co.jp/enterprise/articles/0504/23/news005.html 31

簡易診断方法

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

32


33

脅威 • 不正な送金• 商品購入• 退会処理• 掲示板への書き込み• ユーザ設定変更（パスワード等）


Cookie, Basic認証, SSLクライアント認証等でセッション管理を実装しているサイト。特に金銭処理が発生するサイトは注意が必要。

対策

https://www.ipa.go.jp/files/000017316.pdf 34

根本的解決 1. 処理実行ページを POST メソッドでアクセスするようにし、その「hidden パラメータ」に秘密情報（セッションID・トークン等）が挿入されるよう前のページを自動生成。実行ページではその値が正しい場合のみ処理を実行。

2. 処理実行直前のページでパスワードの再入力を求める3. Refererが正しいリンク元か確認し、正しい場合のみ処理実行（注：但しブラウザやパーソナルファイアウォール等の設定で Refererを送信しないユーザがアクセスできなくなる）

保険的対策 4.重要な操作を行った際に、その旨を登録済みのメールアドレスに自動送信する

一息入れて簡単なものを…

•Click Jacking

35

【脆弱性4/10】 Click Jacking（クリック・ジャッキング）

注：危険度、攻撃スタイル、想定被害については発表者本人の意見。IPAへの届け出状況は https://www.ipa.go.jp/files/000017316.pdfより引用。

36

危険度中


想定被害

情報漏洩 △

改竄 ◯

妨害 ◯

IPAへの届出状況 2011 年に初めて受け付け。ウェブサイトの届出全体に占める割合は、1 パーセント未満と多くはない。しかし2011 年から継続して届出を受けている。

https://www.ipa.go.jp/files/000017316.pdf

【脆弱性4/10】 Click Jacking（クリック・ジャッキング）

•攻撃デモ• https://vulnerability-attack-demos.herokuapp.com/static_pages/click-jacking

• TODO: デモサイトでも攻撃可能にする

37

https://vulnerability-attack-demos.herokuapp.com/static_pages/click-jacking

仕組み解説

画像は https://www.ipa.go.jp/files/000017316.pdfより引用 38

https://www.ipa.go.jp/files/000017316.pdf




40

脅威 • ログイン後の利用者がマウス操作のみで実行可能な処理• 例

• Facebookの記事シェア• 退会処理• プロフィール公開範囲の変更


• マウス操作のみで実行可能な重要な処理があるサイト

対策


根本的解決 1. HTTPレスポンスヘッダに、X-Frame-Options ヘッダフィールドを出力し、他ドメインのサイトからの frame 要素や iframe 要素による読み込みを制限する。

2. 重要処理を実行する直前のページでパスワードの再入力を求める

保険的対策 3.重要な処理は一連の操作をマウスのみで実行できないようにする

ここから先は似たもの同士をまとめさらっと流していきます

•外部からのInputパラメータにより引き起こされる攻撃群

•OSコマンドインジェクション•ディレクトリトラバーサル•オープンリダイレクタ

42

【脆弱性5/10】 OSコマンドインジェクション

43

危険度高

攻撃スタイル能動的

想定被害

情報漏洩 ◯

改竄 ◯

妨害 ◯

IPAへの届出状況 Perl で開発されたウェブアプリケーションや、組み込み製品の管理画面で使用される CGI プログラム等のソフトウェア製品の届け出が多い模様。

仕組み解説

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

44


45

脅威 • サーバ内ファイルの閲覧、改ざん、削除• 意図しない OS のシャットダウン、ユーザアカウントの追加、変更

• ウイルス、ワーム、ボット等への感染、バックドアの設置• 他のシステムへの攻撃の踏み台


シェルを起動できる言語機能が利用できるサイト。

対策


根本的解決 1. シェルを起動できる言語機能の利用を避ける。

保険的対策 2.シェルを起動できる言語機能を利用する場合は、その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可した処理のみを実行する。

【脆弱性5/10】 OSコマンドインジェクション

47

危険度高


想定被害

情報漏洩 ◯

改竄 ◯

妨害 ◯

IPAへの届出状況 Perl で開発されたウェブアプリケーションや、組み込み製品の管理画面で使用される CGI プログラム等のソフトウェア製品の届け出が多い模様。

仕組み解説

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

48


49

脅威 • サーバ内ファイルの閲覧、改ざん、削除• 意図しない OS のシャットダウン、ユーザアカウントの追加、変更

• ウイルス、ワーム、ボット等への感染、バックドアの設置• 他のシステムへの攻撃の踏み台


シェルを起動できる言語機能が利用できるサイト。

対策


根本的解決 1. シェルを起動できる言語機能の利用を避ける。

保険的対策 2.シェルを起動できる言語機能を利用する場合は、その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可した処理のみを実行する。

【脆弱性6/10】ディレクトリトラバーサル

51

危険度低〜高


想定被害

情報漏洩 ◯

改竄ー

妨害ー

IPAへの届出状況ウェブサイトの届出全体に占める割合は、数パーセントと多くはないが、受付開始当初から継続して届け出がある。

仕組み解説

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

52


53

脅威 • サーバ内ファイルの閲覧、改ざん、削除• 重要情報の漏えい• 設定ファイル、データファイル、プログラムのソースコード等の改ざん、削除


• 外部からのパラメータにウェブサーバ内のファイル名を直接指定しているウェブアプリケーション• 例：

• ウェブページのデザインテンプレートをファイルから読み込む

• 利用者からの入力内容を指定のファイルへ書き込む

対策


根本的解決 1. 外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避ける

2. ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする

保険的対策 3.ウェブサーバ内のファイルへのアクセス権限の設定を正しく管理する4. ファイル名のチェックを行う

【脆弱性7/10】オープンリダイレクタ

• IPA資料内に情報が少なかったため、個人で調査した結果をメインに記載します

55

仕組み解説

• URL等のパラメータに別のサイト内URLを直接指定し、リダイレクトさせる処理において発生する脆弱性

• ⇒外部サイトのURLを指定され、外部サイトにリダイレクトさせる攻撃

フィッシング手法により個人情報が盗まれる危険性。

56

具体的な攻撃方法

•ログイン後に、サイト内の別ページに飛ばす処理などが危ない

57

https://example.com/login.php?url=/contents.php

ID

PASS

Login


• 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


• Step2: ログイン成功するとリダイレクトされる。それを利用し見た目がログイン画面と同じフィッシングサイトに誘導• 見た目が同じだとユーザは気づかない

59

https://trap.com/

ID

PASS

Login

エラー：IDかパスワードのいずれかが誤っています。再度ログインください。


• Step3: ID/PASSが入力される

60

対策

体系的に学ぶ安全なWebアプリケーションの作り方 4.7.3 リダイレクト処理にまつわる脆弱性のまとめ 61

1.リダイレクト先は固定にする（例：決まった番号で指定）2.外部から指定されたURLの文字種とドメイン名をチェック

似たもの2つを本当に簡単に流して説明します

•外部からのInputパラメータがリクエストヘッダに挿入されることにより引き起こされる攻撃群

•HTTPヘッダーインジェクション•メールヘッダインジェクション

62

【脆弱性8 & 9 / 10】概要

•画面からの入力値をHTTPレスポンスヘッダーやMailヘッダーに入れたいケースがある• HTTPレスポンスヘッダー

• リダイレクトの実装として、ジャンプ先の URL 情報をLocation ヘッダに入れる

• 名前情報等をSet-Cookieヘッダーに入れる

• Mailヘッダー• 画面上で、To, From, CCなどを指定する

•改行コードを入れることで、レスポンスを分割・改竄できる• 任意のHTTPレスポンス、Mailを作成

• （HTTPレスポンスのキャッシュ制御関連のヘッダを利用して）キャッシュサーバにキャッシュさせ、コンテンツ汚染

63

ちょっと毛色が違う、少し広い話になります

•認証

•認可

64

認証と認可の違い

•認証（Authentication）• 通信相手が誰であるか確認すること

例）Googleへのログイン処理

•認可（Authorization）• 通信相手に対し、リソースアクセスの権限を与えること

例）GoogleDocumentの参照権限

65

認可に関連する脆弱性

• 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

https://example.com/user/1




認証に関連する脆弱性

•ログイン情報に関して• 総当たり攻撃でID/PASSなどのログイン情報の組み合わせを当てられる

• 辞書攻撃（使用頻度が高いパスワードを順に試す）

• ジョーアカウント探索（アカウント名・パスワードが同一の組み合わせを試す）

• 逆総当たり攻撃（パスワードを固定し、ユーザIDを入れ替えて試す）

•セッションに関して• セッションIDを盗聴され、使用される（セッション・ハイジャック）

• 指定のセッションIDを使用させられる（セッション固定化攻撃）

67

ログイン処理において気をつけること(1/2)

•総当たり攻撃などでログイン突破されないようにするためWebサービス事業者側は以下の事項に気をつける

• 文字数下限を設ける（例：8文字以上）

• 使用できる文字種の幅を広くとる（例：英数記号）

• 入力後の応答メッセージがヒントとならないようにする（例：「IDまたはPASSWORDが誤っています」）

• アカウントロック機能を設ける（例：10回間違えると30分ログイン不可）

• ログインIDの秘匿（例：非公開情報であるメアドをIDとして使用）

• ログインフォームページからHTTPSを使用

68

ログイン処理において気をつけること(2/2)

•パスワードの保存に関しては以下の点に注意• 平文ではなく、ハッシュ値を保存

• 但し、ハッシュ値がバレた場合もオフラインの総当たり攻撃で元文がバレる

• ⇒ソルトをつける＜ソルトの要件＞• ある程度の長さを確保（20文字程度）

• ユーザごとに異なるものにする

• 例：乱数やユーザIDを使用

• ⇒総当たり攻撃への対処として、ハッシュの計算時間を長くするため、ストレッチングも実行（例：1000回）

69

セッション・ハイジャック

•以下の不備があった場合はセッションが盗まれる可能性がある• セッション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

セッション固定化攻撃

•以下の不備があった場合は、セッション固定化攻撃が成立し得る

• クッキーモンスター問題

• XSS脆弱性

• HTTPヘッダインジェクション脆弱性

71

セッションに関する攻撃の保険的対策

•ログイン時にはセッションを再生成

•ログアウト時にはセッションを破棄

•重要な処理の前にはパスワードを入力させる

72

最後に小話

•こんなのも脆弱性として認められてるみたいです•クローラへの耐性

IPAウェブ健康診断 https://www.ipa.go.jp/files/000017319.pdf 73

総括

• 外部からのInputパラメータが、システムが使用する変数（SQL、URL、HTTP Header、Mail Header、OSコマンド等々）となるときは必ず何かしらの脆弱性が発生し得ると考える

• とはいえ、実装時は気付かずに脆弱性を入れてしまうものですが…

• フレームワークの推奨機能になるべく乗っかり、独自実装をできるだけ避ける

• ごくごく普通の結論になってしまいました…

• スキルが一様でない大人数の開発だと脆弱性ゼロは難しい気もするので、もう外部業者にセキュリティ調査依頼したほうが良いのでは？

• 注：超個人的意見です

74

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

75

Software

春の脆弱性祭り 2017/06/13