自己紹介とお約束

Size: px

Start display at page:

Download "自己紹介とお約束"

なぎさいとえ
5 years ago
Views:

1 ディレクター製作者が知っておくべきセキュリティ ~ 脆弱性の事例から ~ 株式会社ビジネスアーキテクツ太田良典

2 自己紹介とお約束

3 私の所属株式会社ビジネスアーキテクツ (ba) 大規模企業サイトの構築を得意とする戦略から設計実装までお付き合いしますただ言われたとおりページを作るだけではない 3/69

4 仕事でやっていることマークアップデザインエンジニア HTML や CSS の設計ガイドライン弊社内では変な HTML を書くと私に怒られるらしい ( 都市伝説 ) Web アクセシビリティアクセシビリティ指針策定ユーザビリティサイト設計 / UI 設計 / 情報設計諸々 4/69

5 こっそりやっていること脆弱性の発見と届出経済産業省の情報セキュリティ早期警戒パートナーシップの制度を利用していろいろ届出 5/69

6 届出の内容主にクロスサイトスクリプティング脆弱性 (XSS) SQL インジェクション CSRF その他も少々高度なものはあんまりない 6/69

7 届出の例 1 それなりに報道されたりしたケースも 7/69

8 届出の例 2 複数のメールクライアントにおける mailto: URL 解釈の問題 mailto: に Bcc: などが含まれていると脆弱性ではないとされつつも修正された 8/69

9 届出の例 3 PukiWiki 他多数の Wiki エンジンに脆弱性スクリプトを含む HTML ファイルを添付するだけ 9/69

10 届出件数届出件数 : たぶん 120~130 件くらい国内の届出は 821 件なのでシェア約 15% ウェブアプリケーションの届出に絞ると全体で 564 件なのでシェア 20% 超第 2 回 IPA 賞 ( 情報セキュリティ部門 ) 受賞理由 : 届出件数最多のため受賞したりしている時点でもうこっそりではなくなっていますが 10/69

11 本題の前にお約束情報を不正アクセスから守るためには攻撃側の手法を知る必要がありますそのためこの話の中にも攻撃手法の解説が出てきますが絶対に悪用しないでください不正アクセス行為は法によって処罰されることがあります 11/69

12 本当にあったお話その 1 デザインリニューアルのはずが

13 ありがちなパターン既存の会員制サイトのデザインリニューアル情報設計 UI 設計ビジュアルデザインなどを弊社が担当 HTML クライアント側のスクリプト実装は弊社が担当バックエンドのシステムについては旧システムを実装した会社が引き続き担当 13/69

14 作業は問題なく進み HTML CSS2 で実装いわゆるフル CSS 最近は Netscape4 でのレイアウト再現が求められなくなり table レイアウトが必要なくなっている弊社は HTML とスクリプトを納品システム側の実装が完了 14/69

15 テスト開始弊社は基本的にデザイン担当なので期待される役割はデザインが正しく反映されているか崩れたりしていないか確認することクライアント側スクリプトの動作を確認すること 15/69

16 ありがちな不具合表示崩れ不自然なマージンなどが多数良く見るとソースが勝手に改変されている謎のスペーサ GIF font 要素 center 要素 ( 懐かしい ) HTML の知識が 9 年前のまま 16/69

17 ありがちな不具合 ( つづき ) リンクがことごとく javascript: スキームになっている <a href= javascript:foo() > </a> などスクリプト無効時動かない別ウィンドウが開けないなどさまざまな問題がある WCAG で名指しで禁止されているが WCAG 読んでない 17/69

18 まあここまでは良い

19 何故か大量の脆弱性が発見されるクロスサイトスクリプティングディレクトリトラバーサル OS コマンドインジェクション SQL インジェクションセッション管理の不備 etc. 中には洒落にならないものも 19/69

20 報告してみるとお返事 : システムの改修は想定していない脆弱性がこんなに発見されるとは予想していない見積にもスケジュールにも盛り込まれていないというわけでそのままリリースしかも良く考えるとリニューアル前のシステムも脆弱だったということであり結局ずいぶん経ってからひっそりと修正 20/69

21 私の経験からすると HTML が正しく書けていないサイトはけっこう危ない感じがする実装者の HTML の知識と脆弱性の多さは反比例しそうな気がするそもそも XSS の原因のほとんどは HTML を知らないことに起因する 21/69

22 教訓システム会社にもいろいろありますが HTML は正しくこれができていないとちょっと危険かも 22/69

23 本当にあったお話その 2 HTML の高度な知識が求められたケース

24 概要とあるISPのサイトで発見したクロスサイトスクリプティング脆弱性事例経緯 2005 年 3 月 1 日発見同日 IPA セキュリティセンターに届出 2005 年 3 月 7 日追加情報を届出 2005 年 10 月 26 日修正完了の連絡 24/69

25 そのサイトの仕様タグが書ける掲示板書けるタグはごくわずか <script> </script> などは書けない ( 書くと <script> などとして出力される ) <a href= ></a> は書けるおそらく想定されていたであろう仕様 : タグは書けるがスクリプトは動かない 25/69

26 いろいろ書いてみる <a href= javascript:alert() >test</a> タグ部分が削除され test と表示されるリンクにもならない javascript: スキームの URL は無効になりスクリプトは実行されない 26/69

27 もっといろいろ書いてみる <a href= ></a> やっぱりタグが削除される URL のどこかに script が含まれるとダメ不具合では? 上記は正しい URL で書けても問題ないはず JavaScript の解説をしているようなサイトにリンクできないのですがあまり深く考えていない? 27/69

28 もっともっといろいろ書いてみる <a href="javascript: "></a> これは書けた t = t しかし script という文字列はどこにもないためフィルタ処理を貫通アンカー部分をクリックするとスクリプトが動作脆弱! 28/69

29 脆弱性は何故生まれたか? javascript: がまずいというところまでは良かった数値文字参照に考えが至らなかった引用符で括られた属性値の中では数値文字参照が展開されるという HTML の知識が必要だった 29/69

30 届け出ました比較的素早く対応された script と書いてあってもタグが削除されるようになった数値文字参照を展開してからフィルタ処理するようになった模様これで一安心だと良いのですが 30/69

31 さらにいろいろ書いてみる <a href="javascrip&#116:"></a> t ではなく &#116 で末尾のセミコロンが省略されているこれは書けたそしてスクリプトが動いたやっぱり脆弱 31/69

32 脆弱性は何故生まれたか? 数値文字参照を考慮したのは良かったしかしセミコロンが省略された場合に考えが至らなかった数値文字参照の末尾のセミコロンは省略できることがあるという HTML の知識が必要だった 32/69

33 さらにマニアックな例 <input<script src= </script> これは実は正しい記述 HTML では SHORTTAG YES なので短縮タグ機構が有効タグのまとめ閉じが可能 (XHTML では不可 ) そのため最近のわりとちゃんとしたブラウザではちゃんと理解されてしまうことがある SGML の知識も必要 33/69

34 心の叫び普通そんなの知らないよ! 34/69

35 脆弱性対応の難しさ安全なタグだけが使用できるというウェブアプリケーションを作るためには HTML の知識が必要それも聞きかじりの知識ではなく HTML の仕様を正しく理解している必要があるしかも時にはかなりマニアックな知識が求められることがある今回は紹介していませんがブラウザのバグの話もあり 35/69

36 教訓その 1 HTML に詳しい者だけが指摘できる脆弱性もある 36/69

37 教訓その 2 タグが使用できるが危険なタグは使用できないアプリケーションを実装するのは非常に難しい有名な Web メールサービスは脆弱性の発覚と修正を何度も何度も繰り返して現在に至るそして最近でも指摘されているそういうシステムを安易に提案しないもしくは覚悟して提案する :-) 37/69

38 ほんとうにあったお話その 3 設計に起因する HTTPS の不適切な利用

39 HTTPS の不適切な利用とは? HTTPS (SSL/TLS) による暗号化通信を意図しているが使用法が適切でないために安全性が確保されないケース脆弱性なの? と疑問に思うケースもあるがちゃんと取り扱ってもらえるおそらく運営者が HTTPS を使用している意図が明白かつ HTTPS が安全に機能していないという条件で脆弱性と判断される 39/69

40 概要とある協会のサイトで発見した HTTPS の不適切な利用事例経緯 2005 年 3 月 10 日そのサイトで XSS を発見届出 2005 年 03 月 24 日残念なことが起きる 2005 年 03 月 25 日別の問題を発見したので届出これが HTTPS の不適切な利用として受理される修正完了の連絡はないが修正されている模様 40/69

41 セキュリティポリシーセキュリティポリシーに以下のような記述当サイトでは SSL を使用しています以下の方法で安全性を確認することができますブラウザのアドレスバーを確認するブラウザのステータスバーの鍵アイコンを確認するそしてそのサイトではフレームが使われていた 41/69

42 例 : とある HTTPS なフォーム 42/69

43 とあることをすると 43/69

44 フレームの差し替えフレームで構成されたサイトではフレームの中身を他のものに差し替えることができる基本的にそういう仕様しかしブラウザ側も対応してきていて最近の Firefox ではできなくなっている IE7 も対応予定 44/69

45 フレーム + HTTPS はダメフレームの中身だけ偽物に差し替えられているかもしれないアドレスバーと鍵マークの確認では外側のフレームについてしか確認することができない中身も確認するにはフレームの中で右クリックしてプロパティを出す必要がある 45/69

46 その他ありがちな事例わりとよくある HTTPS の不適切な利用例

47 HTTPS の不適切な利用例 1. 嘘のSSL 宣言 2. 確認できないSSL 宣言 3. オレオレ証明書 4. 問題ある指示 5. 信頼できないフォーム 6. 信頼できないドメイン 47/69

48 知っておいてほしいこと 1 なぜ HTTPS (SSL/TLS) を使うのか? 答え : 安全を保証するためインターネットでは任意の通信経路を通って通信が行われる通信系路上に悪い人がいると通信内容を読み取られたり改竄されたりすることがあるそれがまずい状況の場合は通信系路上に悪い人がいても問題ないように暗号化する安全を保証することが重要なので安全かもでは HTTPS の意味がない 48/69

49 1. 嘘の SSL 宣言 SSL を使っていますと言いながら実際には使っていないセキュリティポリシーに SSL を使って情報を保護していますという主旨がはっきり書いてあったしかしフォームの URL も送信先の URL も http: で特に暗号化されていなかった実は SSL / TLS が使える用意はされていた https: でフォームにアクセスすることは出来たしかしフォームへのリンクやフォームからの送信先の URL が http: で記述されていた 49/69

50 知っておいてほしいこと 2 サイトに SSLを使っていますと書いてあるだけでは暗号化されたりはしない SSL/TLS を使えるようにしていたとしてもユーザが https: な URL に誘導されないと意味がないこれはありがちなミス http: でアクセスされても何も出ないようにしておくと安心ただし SSL 非対応のブラウザではアクセスできなくなる ( 特に携帯電話 ) 50/69

51 2. 確認できない SSL 宣言 SSL を使っていますと言っている実際に使ってもいるしかしながらユーザにそれを確認する術がないため偽者だとしても区別できない 51/69

52 とあるサイトの説明アドレスバーや鍵マークは表示されないが SSL は有効と主張見た目がそっくりな偽サイトを作られたときユーザはどうやって見分けることができるのか? 52/69

53 知っておいてほしいこと 3 悪い人は本物そっくりな偽のフォームを作ってだまそうとするかもしれないそのときそれを偽物だと識別できるようになっていなければならない通常のブラウザではフォームが既知の信頼できるドメインに属しており HTTPSで保護され有効なサーバ証明書があるということをアドレスバーとステータスバーで確認できこれによって本物だと判断できる 53/69

54 隠す心理運営者の動機フォームの送信先は別ドメインの ASP サービスしかしそのことをユーザに知られたくないので URL を隠したい悪い人の立場で考えるとフォームの送信先は自分のドメインしかしそのことをユーザに知られたくないので URL を隠したい利害一致まさに思うツボ 54/69

55 3. オレオレ証明書以下のような証明書は信用できない信頼された認証機関による署名がない発効先の名前と違うドメインで運用されている証明書の期限切れブラウザは警告を出すのだが 55/69

56 とあるサイトの主張警告は出るが保護されるはいを押せば OK ってホンマかいな? 56/69

57 知っておいてほしいこと 4 証明書の警告が出るのは何故? 答え : 通信相手が偽者の可能性があるから暗号化されていれば第三者に読み取られても問題ないが暗号化通信の相手が偽者だったら全く意味がない! だから相手が偽者ではないかどうか確認する必要があるそのための証明書相手が偽者ならサーバ証明書も偽造しているはずなので信頼できる機関による電子署名がない証明書は信用してはならない 57/69

58 4. 問題ある指示 HTTPS はちゃんと機能していて問題ないしかしユーザに対して問題のある指示が行われている指示に従うとセキュリティレベルを下げられてしまったり危険に晒されてしまったりする 58/69

59 とあるサイトの指示 59/69

60 SSL2.0 が必要? メニューから < ツール >< インターネットオプション > を選択し詳細設定のセキュリティ項目にある SSL2.0 を使用する SSL3.0 を使用するにチェックを入れてくださいこのサイトで SSL3.0 が使えるなら SSL2.0 は必要ないはず SSL2.0 は脆弱なのでオフ推奨 60/69

61 はいを押せ? セキュリティの警告が表示された時にはいボタンを押してセキュリティ証明書を受け入れてからご利用いただきますようお願い致します悪い人がいた場合この操作で偽の証明書を信頼してしまう 61/69

62 知っておいてほしいこと 5 セキュリティレベルを下げる指示はしないことどうしても必要な場合のみリスクを理解させたうえで指示するべきそもそも理解してるの? ブラウザの警告を無視させないこと指示に従ったら偽の証明書をインストールさせられてしまうケース多々あり特にルート証明書のインストールは慎重にやらないと非常に危険 62/69

63 5. 信頼できないフォームデータの送信先は HTTPS なのだが送信元のフォームが HTTPS になっていないデータは暗号化されるので大丈夫と主張されるが 63/69

64 とあるサイトの説明 64/69

65 知っておいてほしいこと 6 送信先が https: だとしてもそれをユーザが確認する方法はないソース見ますか? 悪い人はフォームを改竄し送信先を https: からhttp: に変更してしまうかもしれない送信が終わってから悪い人に届きましたでは意味がないそのためフォームの時点でサーバ証明書などを確認しておく必要がある 65/69

66 6. 信用できないドメインフォームが別ドメインにあるそしてその別ドメインにあるフォームにはこんなメッセージが 66/69

67 対抗して悪い人は当然フォームをこう書き換えて置くことができる見分けがつかない 67/69

68 知っておいてほしいこと 7 信用できるかどうか分からないところにこのサイトは信用できますと書いても全く意味がない当然悪い人も同じメッセージを書けるリンク元に書いてあればまだ分かるが 68/69

69 おしまいありがとうございました

クライアント証明書導入マニュアル

クライアント証明書導入マニュアル Windows10 用第 1.1 版 2018 年 12 月 13 日改訂履歴版改訂日区分改訂箇所改訂内容 1.0 2016/01/08 新規新規作成 1.1 2018/12/13 修正画面デザイン変更に伴う修正 2 目次 1. はじめに... 4 2. Internet Explorer のセキュリティ設定について... 5 3. Internet Explorer