Dreamweaver使いが 知っておきたいセキュリティ 株式会社ビジネス･アーキテクツ 太田 良典 かんたんな自己紹介 私の所属 • 株式会社ビジネス･アーキテクツ (bA) • 大規模企業サイトの構築を得意とする – 戦略から設計、実装までお付き合いします – 「ただ言われたとおりページを作るだけ」ではない 3 仕事でやっていること • マークアップデザインエンジニア – HTML や CSS の設計、ガイドライン • 弊社内では、変な HTML を書くと私に怒られるという 都市伝説がある – Webアクセシビリティ • 企業の「アクセシビリティ指針」策定 – ユーザビリティ • サイト設計 / UI 設計 /情報設計諸々 4 こっそりやっていること • 脆弱性の発見と届出 – 経済産業省の「情報セキュリティ早期警戒パート ナーシップ」の制度を利用していろいろ届出 5 届出の例 • それなりに報道された りしたケースも 6 届出件数 • 届出件数 : たぶん150件くらい – 国内の届出は約1000件なので、シェア約15% – ウェブアプリケーションの届出に絞るとシェア20% 超 • 第2回IPA賞 (情報セキュリティ部門) 受賞 – 理由 : 届出件数日本一 受賞したりしている時点で、もう「こっそり」で はなくなっていますが……。 7 本題の前に おねがい • 情報を不正アクセスから守るためには、攻撃 側の手法を知る必要があります • そのため、この話の中にも攻撃手法の解説 が出てきますが、絶対に悪用しないでください • 不正アクセス行為は、法令によって処罰され ることがあります 9 本題 お話の流れ • • • • DreamweaverのPHPサンプル 脆弱性とは? 脆弱性事例の紹介 おわりに 11 DreamweaverのPHPサンプル 13 できました! 14 入力してみると…… 15 表示されました 16 サンプルフォームの問題 その1 もっとコメントしてみる 18 拡大 19 表示されましたが…… 20 何かがおかしい 21 そのときのソース 22 拡大 • <table> がそのままソース中に出力されている • これが table要素の開始タグとして解釈された • 本当は <table> という文字を表示してほしかった 23 サンプルフォームの問題 その2 こんなことを書いてみる 25 拡大 26 異変が!! 27 そのときのソース • 今度は <script …… と書き込まれている • script要素として解釈されてしまい、alert() がスクリ プトとして実行された • 任意のスクリプトを書き込むことが出来てしまう 28 alert() が出るだけなら害はない? • alert() が 10000回実行されたらどうか – ダイアログが出ているとブラウザを閉じることもで きない – 俗に言う「ブラクラ」 • 利用者の Cookie を読み取って別のサイトに 送ることもできる – Cookie にセッションID が含まれていた場合、漏 洩するとセッションハイジャックの危険がある 29 サンプルフォームの問題 その3 今度はこう書いてみる 31 拡大 32 そのときのソース • 今度は <iframe …… と書き込まれている • 属性によって、幅・高さ共に100%に設定 • すると…… 33 その結果 34 結論 • Dreamweaver のチュートリアルで作られるサンプ ルフォームは、悪用される危険がある – サンプルフォームをそのまま公開する人はいないと思い ますが…… – 同じような作り方をしてしまうと危険 これは クロスサイトスクリプティング脆弱性 と呼ばれる問題 35 修正する 原因 • 入力された文字をそのまま出力している • 「<」が入力されてもそのまま出力 – 「<」はタグの開始区切り子として使用される文字 • 「<……」が入力されると、HTMLのマークアッ プとして解釈されてしまう 37 対策 • HTML のマークアップとして解釈されるおそ れがある文字を出力しない • 3つの方法 – 文字を削除する – 文字を置き換える – エスケープする 38 文字を削除する • 「<」を削除してしまう方法 • 「<table>が……」→table>が…… • 利用者が意図した表示にならないことがある – コメントに < が含まれることはあり得る。 – たとえばプログラムの話題。「if (a <= 0)」と書くと、 「if(a = 0)」と表示されてしまう – HTML の話題にも支障が出る 39 文字を置き換える • 「<」を別な文字に置き換えてしまう方法 – たとえば全角の「＜」 • 「<table>が……」→＜table＞が…… • いちおう表示されるが、やはり利用者が意図 した表示にならないことがある • かっこ悪い 40 文字をエスケープする • 文字参照を使用すると、「<」をマークと認識さ れないように表示することができる – 文字実体参照 < – 数値文字参照 < もしくは > – 文字実体参照を使用するのが一般的 • 利用者の入力したままが表示される 41 修正対応 • 文字をエスケープするのが望ましい • PHP の場合、エスケープのための関数 htmlspecialchars() が用意されている • 以下を変換 – 「<」→< – 「>」→> – 「”」→" – 「&」→& 42 コードの修正 44 修正箇所 • echo で値をそのまま出力している 45 修正後 • htmlspecialchars() を追加 46 使用前・使用後 47 脆弱性とは? ぜいじゃくせい ×きじゃくせい (危ではありません) ×だじゃくせい (惰? あまり似ていませんが) ×もうじゃくせい (もはや誤読の原因不明) 49 経済産業省告示第二百三十五号 「ソフトウエア等脆弱性関連情報取扱基準」 １．脆弱性 ソフトウエア等において、コンピュータウイル ス、コンピュータ不正アクセス等の攻撃により その機能や性能を損なう原因となり得る安全 性上の問題箇所。ウェブアプリケーションに あっては、ウェブサイト運営者がアクセス制御 機能により保護すべき情報等に誰もがアクセ スできるような、安全性が欠如している状態 を含む。 50 「脆弱性」まとめ • 読みは「ぜいじゃくせい」 • 情報セキュリティの分野では、ソフトウェアな どのセキュリティ上の問題点を指す – 「セキュリティホール」も同義 • 「ソフトウェアの脆弱性」のほか、 「Webアプリケーションの脆弱性」というものも ある 51 ソフトウェアの例 : OS 52 ソフトウェアの例 : ワープロソフト 53 Webアプリケーションの例 54 届出件数 出典： 独立行政法人 情報処理推進機構 セキュリティセンター (IPA/ISEC) 有限責任中間法人JPCERTコーディネーションセンター(http://www.jpcert.or.jp/) 55 脆弱性の印象と実際 • ニュース等で目にするのはソフトウェアの脆 弱性の方が多い • しかし、実際にはWebアプリケーションの脆 弱性の方がたくさん発見されている 56 脆弱性事例の紹介 事例1 : TBCのケース ∼フォースフル・ブラウジング∼ 59 事件の概要 61 アクセスしてみると • 書き込みにある URL http://www.tbc.co.jp/cgi/ にアクセスすると、ファイル一覧が表示された 62 ファイル一覧の例 (別のサイト) 63 そして • 一覧を見ていくと、多数のCSV ファイルを発 見 • CSVファイルにアクセス制限などはなく、誰で もアクセスできた • さまざまなデータが格納されていた – アンケートのデータ – 求人応募のデータ etc. 64 手法の解説 「フォースフル・ブラウジング」 「フォースフル・ブラウジング」とは • 無理やり(forceful) 閲覧 (browsing)。 • 閲覧されることを意図していないものを、強制 的に閲覧する手法 66 具体的な方法 • ブラウザのアドレスバーに URL を入れる 以上。 67 フォースフル・ブラウジングの原理 • ブラウザのアドレスバーに URL を入れれば、 その URL にアクセスできる – あたりまえですが…… • どこからもリンクされていない URL であって も、管理者がアクセスされることを想定してい ない URL であっても、自由にアクセスできる 「リンクされていないから見られないはず」 という判断は NG 68 注意点 注意点 • 公開ディレクトリに重要なデータファイルを置 かないこと!! – 特に CGI プログラムの設計時に注意 • サーバ移行時の罠にも要注意 – 今までは見られなかったディレクトリが…… – cgi-bin にも置かないほうが良い 70 Dreamweaver の場合 71 事例2 : カカクコムのケース ∼ SQLインジェクション∼ 73 事件の概要 75 事件の経緯(1) • アンチウイルスソフト NOD32 のユーザがサ イトにアクセスすると、ウイルス警告が表示さ れた • サイトトップページがひそかに改竄され、ウイ ルスが仕込まれていたことが判明 • のちに、ユーザのメールアドレス約25000件 が漏洩していたことも判明 76 事件の経緯(2) • 中国からの留学生が逮捕され、カカクコムへの不正 アクセスを認める • ただし、この留学生は閉鎖の直接原因ではない – 閉鎖の原因となった攻撃の犯人は不明 • 以前から大量の不正アクセスが行われていた模様 – 「実際には単一の犯人ではなく、入れ替わり立ち代わり異 なる犯人による小規模のハッキングを受けてきたことが 明らかになってきた」 • 「備える心」が大事――カカクコムのインシデントから得られた教訓 http://www.itmedia.co.jp/enterprise/articles/0507/27/news020.html 77 その後 • カカクコムは事件の詳細を 公表していない • 報道、インタビューその他 の情報によれば、 「SQLインジェクション」 によるものだったと言われ ている 78 手法の解説 「SQLインジェクション」 SQLインジェクションとは • SQL = Structured Query Language – データベースに問い合わせを行うための言語 • Injection = 注射、注入 • SQL文の中に悪意あるデータを「注入」するこ とで、SQL文の内容を改竄する手法 80 起きることの例 • • • • • 不正なログイン 本来は取得できないはずのデータを取得 データの消去 データの改竄 サーバ上で任意のコマンドを実行 – xp_cmdshell 拡張ストアドプロシージャ 何でもあり、とてつもなく危険 81 SQLインジェクションの原理 SQL文の例 SELECT * FROM user WHERE user=‘admin’ AND pass=‘root’ • SELECT * FROM user – 「user」という名前のテーブルから全データを取得 • WHERE user=‘admin’ AND pass=‘root’ – user, pass の値が特定の条件を満たすものに絞り込む • 結果、 user が admin で pass が root になってい るレコードのデータだけが得られる 83 ところで…… SELECT * FROM user WHERE user=‘admin’ AND pass=‘root’ • ユーザがフォームから入力した値は、 「’」(単引用符、シングルクォート) で括られた状態で SQL文に入ってくる 84 単引用符を入れてみると…… SELECT * FROM user WHERE user=‘Let’s Note’ AND pass=‘’ • 入力されたのが引用符だったため、引用符の 対応関係がおかしくなっている – ちなみに「’Let’’s Note’」とする必要があります • 結果、不正な SQL 文となってエラー 85 さらに…… SELECT * FROM user WHERE user=‘’ OR 1==1--’ AND pass=‘’ • 「--」の後ろはコメントとみなされて無視される ため、以下の SQL 文と等価になる SELECT * FROM user WHERE user=‘’ OR 1==1 86 その結果 SELECT * FROM user WHERE user=‘’ OR 1==1 • これは、user=‘’ が成立するか、あるいは 1==1 が成立するレコードを取ってくる • 1==1 は常に成立するので、全てのレコード が取得できる 非常にまずい感じの誤動作 87 注意点 注意点 • プログラム中で SQL 文を組み立てたりしな いのがベスト – Prepared Statement によるバインドメカニズム を使用する • それが無理なら、確実にエスケープする – 「’」→「’’」 「¥」→「¥¥」 – DB に応じてさまざまな変換関数がある • たとえば mysql_real_escape_string() • しかし、いろいろ難しい…… 89 Dreamweaverの場合 90 事例3 : Yahoo! メールのケース ∼クロスサイトスクリプティング∼ 92 ログイン後 • Web上でメールを読ん だり書いたりできる • HTMLメールも表示で きる 93 事件の概要 事件1 : フィッシング • 普通は、アドレスバーを 見たりすれば偽サイト を識別できる • しかし、本物サイト上で フィッシングを行う「巧 妙」な手口が出現 95 事件2 : ウイルスメール • Yahoo! メールを狙った ウイルスメールが発生 96 手法の解説 クロスサイトスクリプティング フィッシングの手口 • 攻撃者は、スクリプトを含む HTML メールを 送信 • メールを表示すると、攻撃者のスクリプトが実 行され、ページの内容がひそかに改竄される – iframe要素が挿入され、yahoo!メールの本物サ イトの中に攻撃者の用意したコンテンツが表示さ れた – ブラウザのアドレスバーの URL は本物のまま 98 ウイルスメールの手口 • メールを開くと、やはりスクリプトが実行される • そして、自動的に他のユーザにメールを送信 してしまう • そのメールにもやはりスクリプトが……。 増殖 99 何故スクリプトが動いた? • 通常、HTMLメールに含まれるスクリプトは実 行されないようにする必要がある • Yahoo!メールでも、原則としてスクリプトは実 行されないような処理をしていた • しかし、その処理に欠陥があり、スクリプトが 実行されてしまった 100 クロスサイトスクリプティングとは • Cross Site Scripting / XSS – 「CSS」と略すと Cascading Style Sheet と混同 されるので「XSS」と呼ぶ • ウェブサイト上に外部からスクリプトを挿入さ れ、そのスクリプトが動作してしまうこと – 攻撃者の用意したスクリプトが、ターゲットのドメ イン上で実行される – 広義には、スクリプトを含んでいない HTML の改 竄も含む 101 何がまずいのか • 普通、スクリプトで別ドメインのコンテンツを操 作することはできない • XSS脆弱性があるとターゲットのドメイン上で スクリプトが動くので、さまざまな攻撃ができ てしまう – フィッシング – 不正な操作 (ウイルスメール送信) – Cookie読み出しによるセッションハイジャック 102 注意点 注意点 • 外部から入力された値をそのまま HTML に 出力しないこと! • 文字参照に変換すればだいたい OK – 「<」→「<」 「>」→「>」 「”」→「"」 「&」→「&」 • PHP の場合、htmlspecialchars() – addslashes() では駄目! (というか意味が無い) • 文脈によってはさらに難しい場合も…… 104 特に難しい場合 • HTMLメールを「安全に」表示するのは非常 に難しい!! • スクリプトが動作するような記述は無数にあ るが、その全てを考慮する必要がある – イベントハンドラ、javascript: スキーム、url() • ブラウザの挙動まで考慮する必要がある – expression() 、全角の ｅｘｐｒｅｓｓｉｏｎ() 105 Dreamweaverの場合 106 おわりに 知っておいてほしいこと • Dreamweaver を使うと、PHP のアプリケー ションがとても簡単に作れる • しかし安全に動くものを作るとなると、 必ずしも簡単ではない • 脆弱性のあるアプリケーションを公開し、 悪用されると大変なことが起きる • 公開するアプリケーションは、 安全性に注意して実装するべき 108 おすすめサイト (技術情報) • 安全なウェブサイトの作り方 改訂第2版 – http://www.ipa.go.jp/security/vuln/websecurity. html • IPA ISEC セキュア・プログラミング講座 – http://www.ipa.go.jp/security/awareness/vend or/programming/ • SecurIT 産業技術総合研究所 グリッド研究 センター セキュアプログラミングチーム – http://securit.gtrc.aist.go.jp/ 109 昨日の常識は今日の非常識 • 次々に発覚する脆弱性 • どんどん出現する新手法 • 時代の変遷、手法の変遷 常に最新情報を追う必要がある 110 どうやって情報を集めるか • 主に Webサイト – やはり Web サイトの方が情報が早い – Webのセキュリティに関しては、そもそも Web サ イトが一次情報源であることが多い • セキュリティ系、ITニュース系のサイトをこま めにチェックするのが吉 111 おすすめサイト (最新情報) セキュリティホール memo http://www.st.ryukoku.ac.jp/~kjm/security/ memo/ • いろいろな情報を網羅、他サイトへのリンクが 中心 • 興味が出てきたら、少しずつリンク先のサイト をチェックするようにすると良い 112 ありがとうございました
© Copyright 2024 ExpyDoc
