【13-A-7】Webセキュリティ攻守攻防パネルディスカッション「Webアプリケーション／Ajaxセキュリティ徹底バトル」
Webを取り巻く脆弱性問題(XSSやクリックジャッキング、JSONハイジャック)などを
題材に、攻撃側/防御側双方の観点で意見が聞けて大変有意義でした。
セキュリティが大切なのは理解できますが、
それによってソフトウェア開発の敷居が高くなるのは開発者として、とても重たい。
強固なセキュリティを内包するような言語か、
フレームワークが欲しいという下りは全く同感です。
パネルディスカッション後には普段何気なくとらえてたWebセキュリティについて
当事者意識が持てるようになりました。
日曜プログラマ程度では出力エスケープやってないよね？
# 脆弱性を探したくなる衝動に駆られましたが、やめときます。
13-A-7 Webセキュリティ攻守攻防パネルディスカッション「Webアプリケーション/Ajaxセキュリティ徹底バトル」 ◆概要 はまちちゃんがインフルエンザにかかって3日目らしいです。 パネラー自己紹介 はまちちゃん 業務系の人が多いのでご存じないかたが多いのでは? はてなダイアリーでブログ書いてます Seshop.comでのXSS脆弱性のデモつき はせがわようすけ XSS脆弱性の発見が大好き 大垣 靖男 オープンソースすき。 徳丸浩 HASHコンサルティング セキュリティの追及、あるべき論 モデレータ 竹迫良範 Namazuの半角パッチ、モジュール開発など ◆ケーススタディ NumaZu Project XSS脆弱性を報告受ける ⇒ 二日後に修復 翌日さらにバグが→ バージョンアップ 3週間後にさらに。特定の環境でさらにさらに。 落ち着いた後、 1年後にJPCERT/CCからメール。 IPAが受けつけてJVNで公開 脆弱性の修正は頻繁にある。 そこで調整機関が必要な理由は？★ オープンな脆弱性指摘 ＝ 中の人が対応に追われてしまう。 ※mixiのぼくはまちちゃん！ こんにちはこんにちは!!事件 ◆1 XSSってなに? クロスサイトスクリプティング 利用者 ← ?攻撃者はスクリプトをくっつけたURLを利用者へぶち込む ｜アクセス ↓ ショッピングサイト ?情報漏えい、盗用、クレジットカード、フォーム送信先が変わる プレスリリースを偽物をだされてしまう 犯罪のふみ台にもなってしまう。 ◆どんな個人的なサイトでもXSSを直すべき？ 信頼できないWebサイトではXSSはそもそも無意味 (ユーザが個人情報を入力しないし、警戒している) ⇒ 逆説的には、信頼してほしいならXSSを直すべき。 手法によってはセッションを永久的に盗み取ったりできる 防御の視点ではIEをつかわない、ということも考えられる。 例：FirefoxだとNoScriptオプションがある。 → これは全部信頼しないサイトとして扱う。 信用できるサイトであってもXSSによる被害あり。 例:PaypalにログインページにXSSが仕掛けられている。 ※Paypal:送金サイト → 穴があったらすぐなおそうよ。 ◆イントラだったら関係ないの? 企業内のサーバーでSQLインジェクションで内部情報を取得できてしまうので イントラは関係ないどころか狙い目。 たとえば ・保護ルーター：某B社のルーターはNAT内に侵入できてしまっていた ・VOIP電話 ：自分はお金はらわずにただ乗り。 → 社員が信用できたとしても直す必要がある ◆JSONによる秘密情報の漏えい ※JSON（ジェイソン、JavaScript Object Notation）は、 JavaScriptにおけるオブジェクトの表記法をベースとした軽量なデータ記述言語である。 JavaScriptによるデータ交換方法みたいなもの。 → 以前に、JSONでの脆弱性を突かれてGmailのアドレス帳が漏れた。 JSONのデータ通信でリモートから読み込みすることは可能? → 動的にJavascriptで値を返す。XHRで読み込むのでクロスドメインは不可 ※XHR：XMLHttpRequest。JavaScriptを使用してサーバーにHTTPリクエストを行うためのAPIの一種。 JSON Hijacking(JSONハイジャッキング) 攻撃者の用意した関数内にJSONが読み込まれる まもる側は対応が必要 守りは基本的にサーバー側で行うべき。(クライアントでやるべきではない) たとえばJavascriptとして読み込めないようにする 大手がやってる防御方法だから大丈夫、というわけではない★ ◆オープンな脆弱性の指摘は犯罪？ 「あ、XSS脆弱性を見つけた！」と思って直ぐにWebなどで公開すると悪用される恐れ！★ LAC(セキュリティ監視・診断サービス)のJSOCでは多数の攻撃を把握している★ ・XSSは国内発、いたずら目的ばかり。 ・中国、韓国からはSQLインジェクションが多い。金銭目的 運営者の立場： ・少しでも違法性があれば訴えたい 現実： ・セキュリティでは訴えるのは無意味。根本的な対策を考える。 ・なぜなら訴えても回収できる見込みがない。ほとんど海外のだれが攻撃したのかわからない。 指摘者： ・脆弱性をみけたときに直接企業にいうと訴えられるかも。 IPA経由だとお互いメリットがある。 指摘者：訴えられない 運営者：対策するまでに猶予が与えられる ◆オープンソースWebアプリの虚弱性は? オープンソースだから安全と信じていいわけではない これはクローズドソースも同様。 オープンだからレビューをきちんとしてるわけじゃないし、 防御側としてはどっちも安全ではないと考えるべき。 ちなみに攻撃側はどっちでもいっしょ。 ◆IPAいわくPHPを避けろ。これって本当？ 攻撃側：避け切れてない現状があるので気にしない 防御側：PHPの問題点ってなんだろう？ ・言語処理系としてマルチバイト文字列処理をいていない。 いっそマルチバイト対応やめてくれ。 ・ドキュメントが少ない。 ・サポートサイクルが短い。 PHPを使うにはバージョンアップをし続ける覚悟が必要。 → バージョン間でちゃんと動かないところもある バージョン差分のチェックにはコストがかかり、あまり現実的ではない。 PHPのセキュリティポリシーは、あまり良くない。 独自の拡張モジュールには危ない物が多い 例：DBモジュールの脆弱性を放置したままメンテナーが直さないこともあり得た ◆ブラウザのバグと仕様の境界点は? ・いっぱいあるよ! ・ブラウザベンダの感覚で仕様 仕様なら仕様で良いけど、それだったら変更しよう。 → 開発者も仕様に不満があるならちゃんと声をあげようよ ・指摘は窓口を通すべき ブログに書いても取り合ってもらえる可能性は低い たとえば、もじらにリモート実行できるバグを報告すると、お金がもらえる。 ◆UTF7誤認識を利用したXSSはまだ有効? すべてのレスポンスヘッダでCharasetをつければ大丈夫。 ブラウザの自動エンコーディング判断 ⇒ Charasetを送っても無視される! ブラウザの設定によって守れない。 ・UTF-7で攻撃する変態は、はせがわさん一人では →日本には、もう一人いるらしい。これで変態は2人に。 ◆WAF Webアプリケーションファイヤーウォール ※WAFとは、外部ネットワークからの不正アクセスを防ぐためのソフトウェア Webアプリケーションのやり取りを把握・管理することによって 不正侵入を防御することのできるファイアウォールのことである。 http://www.sophia-it.com/content/WAF リバースプロキシ方式で入力をみて、攻撃らしいものを弾く。 画面遷移の検証、入力値の検証、値の保護など ホワイトリストによる防御 ・使える場所が限定される ・誤入力のあとのフォローがない。ユーザビリティが下がる → ブラックリストによる防御を考えるべき。 ・ブラックリストではじかれてもユーザーは違和感ない ・ブラックリストの管理が面倒なのはベンダー側 WAFは保険的な対策と割り切る。有効性が高いこともあるが完全ではない。 ◆デモ(あぶないので省略) ◆質疑応答 Q.AP開発基盤はソースコードを自動生成している、脆弱性についてはどうだろう? A.開発ツールでコードを自動生成するロジックでは考えているはずだが 入力パラメータの扱い方が問題 昔のマイクロソフトのミドルウェアでECサイトが簡単にできます、といったプロダクトでは .ASPを20個ぐらい静的生成していた。基本はこれらを修正してカスタマイズ。 修正するほうに脆弱性があった場合、カスタマイズしているやつも直さないといけない。 最近のはディスパッチャをつかって動的に修正して修正がきっちりできるようになっている 開発者側が手を入れた瞬間に問題が出てくる、こちらが問題。 カスタマイズの部分で潜在的に脆弱性が出てきそう★ 立場によって考え方を変えるべき。 ・開発者側はWAFを考えない。セキュアな状態を自分で保つ ・管理者側はソースコードをすでに触れない前提。防御策としてWAFを検討する
