水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > OWASP Japan 1st Chapter Meeting

OWASP Japan 1st Chapter Meeting

2012年3月27日(火曜日)

OWASP Japan 1st Chapter Meeting

公開: 2012年3月30日2時10分頃

「OWASP Japan 1st Chapter Meeting (www.owasp.org)」というイベントがあったので参加してみました。

以下、ざっくりしたメモを箇条書きに。

OWASP / OWASP Japanについて

最初はOWASPとOWASP Japanの紹介。

OWASPは "The Open Web Application Security Project" ですが、最近はモバイルのセキュリティも扱っているというような話も。

5分でわかるCSP

ここからプレゼンテーション。各自持ち時間10分なのでライトニングトークに近いです。

一発目は、はせがわようすけさんの「5分でわかるCSP」。プレゼン資料が以下で公開されています。

資料を見た方が良いと思いますが、以下私のメモ。

5分でわかるCSP
  • CSP = Content Security Policy
  • Firefox4以降、Chrome18以降で実装
  • 指定された以外のリソースが読めなくなったり、インラインのスクリプトが禁止されたりする
  • evalやイベント属性を禁止することもできる
  • HTTP応答ヘッダで Content-Security-Policy: default-src 'self' のように指定する (これはFirefoxの場合。仕様は揺れている) と、同一ドメイン、同一ポートのリソースのみ読めるようになる。
  • meta要素での指定もいちおう可能だが、推奨されない。meta要素が読み込まれるまで指定が有効にならないので、metaの前に何かをインジェクションされると突破されてしまう。
  • ほかの指定の例
    • default-src 'self'; img-src *.example.com
    • script-src: 'unsafe-inline'
  • ポリシー違反があった時にレポートを送信するような指定もできる。 report-uri http://example.com/cspreport.cgi のように指定
  • 動作は禁止せずにレポートのみ送信する指定もある
5分で破るCSP
  • XSSがあるのにCSPのおかげでPoCが動かないというのは悔しい
  • CSPで最も厳しい指定をしても、自身と同一のオリジン (スキーム、ドメイン、ポートが同じ) であれば読める
  • ということは、自身は読める
  • src属性で自身を指定するようなscript要素をインジェクションすると、自身のHTMLをスクリプトとして解釈して実行しようとする
  • HTMLをJavaScriptとして実行しようとしても普通は文法エラーになるだけだが、E4Xを解釈するブラウザ (Firefox) の場合、HTMLをJavaScriptとして妥当なものにすることができる
  • XMLリテラルを二つ持ち、間にスクリプトが書いてあるような構造にする
  • ただしXML宣言や文書型宣言はE4Xとして解釈できないので、これらがあるとうまく行かない。文書型宣言をきちんと書いておくとこの攻撃を防げる
脆弱なWebサーバを作ってみた(仮)

続いて竹迫さんのお話。

  • サイボウズ社では「サイボウズ・ユニバーシティ」という活動があり、社内の勉強会を一元管理しようとしている
  • サイボウズ・ユニバーシティの企画として、セキュリティホール発見大会を実施
  • Badstore.net (www.badstore.net)という脆弱なWebアプリケーションのサンプルがあり、ISOイメージが配布されている。
  • SQLインジェクションやCSRFなど、ひととおりの脆弱性が実装されている
  • パスワードはMD5で保存されているが、MD5値をGoogleで検索すると答えが分かる場合がある。また、md5crack.com (md5crack.com)で解読可能
  • robots.txtからの情報漏洩もあり。検索エンジンよけディレクトリに機密データが置いてある
  • 課題を出して一通りの攻撃をしてもらったが、そのアクセスログを見ると非常に面白い
  • Badstore.com以外にも、IPAのAppGoat、Web Security Dojo、OWASP Web Goat Projectなどがある
ここが変だよ、グローバルスタンダードの脆弱性対策 ～入力値の考え方～

そして徳丸さん。

以下、私のメモ。

OWASP TOP 10の黒歴史
  • OWASPといえば「OWASP TOP 10」 → また上野宣か
  • PCIDSSでもOWASPのガイドラインを参照している
  • OWASP TOP 10 2004のトップに出てくるのが「入力データの未検証」
  • CWEでは「CWE-20 不適切な入力確認」として分類されているが、階層を見ると下層にインジェクション系の脆弱性、書式文字列の脆弱性などが大量にあり、範囲がやたら広い
  • そもそも入力値検証で良いのか、「バリデーション至上主義」ではないか
バリデーション至上主義の例
  • 書籍「Ajaxセキュリティ (www.amazon.co.jp)」の例
  • プリペアードステートメントよりもバリデーションを推奨している
  • ホワイトリストを作り、改良を続けることを薦めているが……。
  • そもそもホワイトリストなど作れるのか? メールアドレス「'or'1'='1'--@tokumaru.org」はRFC5322に適合する妥当なメールアドレス
  • アポストロフィをどうするのかについては著者も困ったようで、「アポストロフィの数を制限する」という方法を挙げている。しかし、アポストロフィは1つでも攻撃には十分
海外ではバリデーション重視?
  • アメリカや海外ではバリデーションが重要視されているらしい?
  • 確かにいくつかの脆弱性に効き目があるが、効き目のないものもあり、根本的な解決ではない
  • バリデーションに頼りきると、「セカンドオーダーSQLインジェクション」などという本質的でないものも出てくる → また上野宣か
  • しかし OWASP TOP10 2007や2010 からは、validationはなくなっている。CWE-20にも根本的でないという注釈があり、これを書いた人とはうまい酒が飲めそう
まとめ
  • バリデーションは普通にやりましょう
  • 「バリデーション」の「万能性」に惑わされずに、きちんと対策をすることが重要
バイナリパッチによるAndroidアプリの改竄とセキュリティチェックのバイパス

Webアプリの話ではないのですが、と前置きしつつの加藤さんのお話。

  • 会場から5分のとこに会社がある
  • OWASPにもモバイルのプロジェクトがある
  • バイナリエディタとdexdump (AndroidのSDKに入っているツール) でバイナリの解析が可能
  • AndroidアプリのAndroid.apkファイルはZIPファイルになっていて、中のclasses.dexというバイナリファイルが本体
  • ちなみにAndroidマーケットのアプリのリバースエンジニアリングは規約で禁止されている。今回は自作のAndroidアプリを解析する
  • 何かをチェックしてアプリが起動しないようにする、というルーチンを迂回する例を紹介
  • dexdumpで解析。onCreateがエントリポイントになるので、そこから辿ってチェックしているルーチンを探す
  • 戻り値のfalseをtrueに書き換える。場合によってはルーチンを全部NOPで埋めてしまうというテクニックもある
  • バイナリエディタでclasses.dexを書き換える
  • そのままではチェックサムのエラーが出るので、CRCを再計算して書き直す。先頭の0x08から4バイトがチェックサムになっている (リトルエンディアン)
  • Webでは非常識なことが、Androidアプリでは行われてしまっている事が多い (クライアントサイドのみのチェックなど) ので、Webアプリのセキュリティの知識は役に立つ

※ちなみに、「Web専門の方はリトルエンディアンという言葉に触れる機会もないと思いますが……」というようなお話がありましたが、そうでもないと思います。UTF-16を扱おうとすると避けて通れませんし、BOMというものもありますし。

ブロークンロジック: テストサイトの誤謬

Isaac Dawsonさんのお話。スライドは以下にあります。

以下メモ。話が力強く英語だったので、正直あんまり分かっていない部分があります。

  • テストサイト = Webアプリスキャナーのテストのためのサイト。スキャナーの実力をテストすることができる
  • 問題点がいくつかある
  • クローズドソース: ソースがオープンでないため検証ができない
  • 不完全な技術: ASP + MS Access か PHP + MySQLがほとんど。ほかの言語やDBがない。
  • 非現実的なフォーム検証: フォームの入力欄を全て埋めないとSQLインジェクションが発動しないなど
  • ブロークンサイト: 普通にダウンしていたり、動作が変だったり。なぜかContent-Length: 0が返る、Set-CookieのExpiresがおかしい、など。
  • 非現実的または偽の欠陥: ひどい、まぎらわしい
    • ディレクトリ・トラバーサルの検査に対して D:\boot.ini へのアクセスを許すが、そこはシステムディレクトリではなく、システムファイルでもない。さらに、Vista以降にはboot.iniは存在しない (この脆弱性は現実的ではない)
    • システムエラーが出ているように見えるが実は静的ページ
    • root / test でログインすると何故か /etc/passwd のようなファイルが見える。意味不明
  • テストサイトがきちんと正しく動作していないと、そこでテストした結果も信頼できなくなる。このようなテストサイトで検証したスキャナーの実力も信頼できない
Rakuten-CERT ぼくらのすすむみち

楽天の軍司さんのお話。さすが楽天、資料が英語だらけでした……。

  • 楽天の利用者は1100万 / 四半期
  • 毎日88億円の取引、うち楽天市場が39億円
  • 社員数7000人、12カ国に拠点を持つ
  • English-nizationに本気で取り組んでいる。苦労している人もいるようだ
  • 開発者は約1600名
  • セキュリティの組織は外・内に分かれる
  • 楽天の各サービスのセキュリティを見る
  • ボス + ペンテスタ4名 + SOC3名 + Appscanオペレータ4名 + アシスタント3名
  • 開発プロセスは Requirement → Design Dev. → QA → Audit。"Audit" の部分は珍しいかもしれない
  • Audit のプロセスでは、Appscanによるチェックと Manual Audit の両方を実施
  • Manual Auditは原則Blackbox、Grayboxについても取組中
  • 外注以外に社内でもペンテスト実施。外・内6:4くらい。社内ペンテスタは4名 (2名は外国人)
  • 年間約250件のAuditを実施、脆弱性の発見数は公表できないが結構ある
  • 1位: XSS(6～7割)、2位: エラーコード (意図しないエラー表示)、3位: CSRF
  • アジャイルとセキュリティの融合が今後の課題
Webアプリケーションセキュリティ要件定義書の提案

「また上野宣か」でおなじみの上野さんのお話。

  • 設計以前のプロセスが最も重要。最初の不備は後のすべてに影響する。早い段階で対応する方がコストが少ない
  • 対応のコスト比は、要求仕様・設計 : 実装 : テスト : 運用開始後 = 1 : 6.5 : 15 : 60
  • 問題の発生率は、要件20%、設計38%、実装37%、配備4%、運用1%
  • 問題は、発注側が要件定義をどう書いて良いか分からないこと。「SQLインジェクションがないこと」「セキュリティに配慮して作ること」のような記述も多い
  • 要件定義の目的は、安全なものを開発することと、責任分界点を明確にすること。「●●がないこと」のような規定では責任分界点も不明瞭。
  • 攻撃の大半は対策が明確になっている。マニアックな攻撃はきわめて希なうえ、「この攻撃ははせがわさんだ」とすぐに分かる。
  • つまり、要件は明確になっている
  • Webアプリケーションセキュリティ要件定義書をクリエイティブ・コモンズのライセンスで配布しているので、活用してもらえると嬉しい
お楽しみコーナー

一通り終了後、お楽しみコーナーということでジャンパーとOWASPバッグのプレゼント。

それぞれじゃんけんで勝った人に与えられる形になりました。ジャンパーはサイズがMということでMサイズの人のみが参加するというルール。バッグの方は全員参加だったのですが、何故か勝ち続けてしまい、まさかの優勝……! 私がバッグを獲得することになりました。ありがとうございます。

関連する話題: セキュリティ

最近の日記

関わった本など