OWASP Japan
OWASPの日本チャプターが結成された記念という事で、初めてのMeetingが水天宮の日本橋公会堂で開催されました。
今回もいつもの勉強会レポートと同様、速報ベース、かつ聞き取れた範囲内でざっくりとレポしていきたいと思います。
---
【OWASP/OWASP Japanについて（Benny Ketelslegers）】
・OWASPとは?
・既にご存知の方も多いですが、(Web)アプリのセキュリティ向上のための活動をしているボランティア団体です
・OWASP謹製のツール、レポート等は自由に利用する事が可能
・(有償の)会員になる必要は無いけれど、なればそれなりの特典がある(Appsecへの優待割引が適用されるなど)
・最近はAndroidセキュリティに関する活動も行っているよ
・OWASP Japanとは?
・OWASPの日本チャプターの事、メンバーや各種活動への参加は随時募集中!!
(詳しくは記事頭のリンク先をご覧下さい。)
---
【Introduction of CSP（Yosuke Hasegawa）】
・scpとは?→コンテンツセキュリティポリシーの事
・Firefox出自の機能(他のブラウザでも対応しているものがある)
・XSS根絶の切り札
・指定された以外のコースが読めない、インラインスクリプトの禁止、evalやイベントの禁止
・レスポンスヘッダで許可するリソースを指定(ブラウザの種類によって指定方法が違うケースがあるので注意)
・metaでも指定できるけど、あまりオススメしない(上書き禁止だし、metaが読み込まれるまでの間が無防備である)
・リソースの種類毎に指定が可能
・ポリシー違反時にレポートを送信できる機能もある(この機能だけ有効にする事も可能)
・しっかり指定することで、第三者によるリソースの読み込みを確実にブロックする事が可能だが、まだ過渡期の技術のため、副作用もあるので注意
・Breaking CSP
・E4X(JavaScript内でXML型をサポート、Firefoxのみ)
・HTMLをJavaScriptと解釈させれば
・自分自身(HTML)は読み込み可能
・ちゃんとDoctype宣言をすれば対応可能
---
【脆弱なWebサーバを作ってみた（仮）（Yoshinori Takesako）】
・脆弱なWebサーバを突いてみた
・実は社内の勉強会(新人参加可)でやってみた事の顛末だったり
・LASDECのセキュリティ健康診断(これで検索すると仕様書が見つかるので、各位それを見ましょう)
・Badstoreを用いたハンズオンを実施(筆者補足：isoイメージをダウンロードして、CDブートさせればすぐ環境が出来上がります、お勉強には最適ですヨ)
・検索結果(エラー画面)から、内部で走っているSQL文を推測→全部のデータを表示させてみる→それを踏まえて色々とSQL Injectionしてみよう
・エラー画面にMD5っぽいハッシュ値が出た→MD5クラック用の検索エンジンというモノも併せて活用してみる
・他にも色々と面白い?仕掛けがあるので、色々と試してみると良いお勉強になります
・Badstoreの類似教材として、以下のようなモノもあります
・IPA AppGoat
・Web Security Dojo
・OWASP WebGoat
・警告：他所様が管理しているサーバにはやってはいけません!!(不ア禁法でとっ捕まりますので)
---
【ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～（Hiroshi Tokumaru）】
・OWASP Top10とは?→ワールドワイドでのWebセキュリティを脅かす脆弱性をランク付けした、年1回の風物詩
・2004年版で出た入力値検証
・CWEとは?→Common Weakness Enumeration(ココとか)
・入力値検証→CWE-20→範囲広すぎ!!
・バリデーション至上主義な解説例(某Ajaxセキュリティな本)を滅多切り（ヲ
・バリデーションでは防げない攻撃ってのもあるんだよ
・実は2007年版以降は入力値検証は出てきていません……
---
【バイナリパッチによるAndroidアプリの改ざんとセキュリティチェックのバイパス（Yoshitaka Kato）】
・Androidアプリのリバースエンジニアリングは非常に容易→改ざんも容易
・今回はバイナリパッチで改ざんを試みます
・バイナリエディタとdexdump(SDKに収録されているツールの1つ)があれば出来ます
・バイナリデータの解析には、Dalvik opecodeが参考になります
・classes.dexというファイルが実行バイナリです→これにdexdumpを当てます
・基本的にマーケット規約上では禁止されているので、その点は注意!!→なので今回は自分で作ったアプリで試しています
・アプリ内でセキュリティチェックをかけているが、それを回避するパッチを当てる
・プロセスはこんな感じ
(1)アプリを入手し必要なファイルを抜き出す→(2)dexdumpでパッチを当てる場所を特定→(3)バイナリエディタで該当箇所を修正(チェックサム修正も併せて)→(4)CRCを再計算→(5)ZIP化と署名
---
【Broken Logic: The Test Site Fallacy（Isaac Dawson）】
・Webアプリ脆弱性スキャナを使っていますか?
・テストサイトって?→スキャナの開発会社が用意したデモ用のサイトの事
・顧客はスキャナをかけた結果(脆弱性の発見具合)でスキャナの実力を測る
・テストサイトの問題点って?→基本的にクローズドソースである(完全なるブラックボックステストである)→実際にどの位仕込まれているかが分からない
・多くのサイトがPHP+MySQL or ASP/ASP.net+MS-Accessで開発されている→プラットフォーム依存の脆弱性は???
・アプリが正常に動作しているか?→この手のテストサイトは世界中の人からアクセスされるため、正常に動作していないケースが発生する場合もある
・最も厄介なのは「非現実的または『偽』の脆弱性」が仕込まれている場合がある事
・上記のような事があるため、テストサイトでスキャナの実力を測る事は、じつはあんまりよろしくない(何せテスト結果が信頼できないから)
---
【ぼくらのすすむみち featuring Rakuten-CERT（Yusuke Gunji）】
・楽天CERTの紹介
・楽天全体での開発者数は1,600名程→これらの人が楽天の各種サービスを開発しています
・楽天グループ内部に対するセキュリティサービスを提供する組織として社内CSIRTが組織された
・楽天の開発プロセス→大きくは一般的な開発プロセスとは変わりはないが、各プロセスにおいてセキュリティプロセスを設けている
・ツールはAppScanを利用
・手動監査は基本ブラックボックステスト＋実験的にグレーボックステストも取り入れている、外注だけでなく、社内でも実施(6:4)、専門のテスターは数名程度
・監査のペースは1日1件弱ペース、最も多く発見されるのはXSS、次いでエラーコードの表示も、CSRFと続きます
・今後はセキュリティ教育や、アジャイルとセキュリティの融合に力を入れていきたいと模索中
---
【Japan ChapterからWebアプリケーションセキュリティ要件定義書の提案（Sen Ueno）】
・コレのご紹介
・早めの対策の方が、かかるコストを抑えられる→ならば要求仕様・要件定義段階だ
・開発工程での脆弱性の発見の割合→多いのは「設計」と「実装」段階
・システム開発を依頼する側→素人なので良く分からない→曖昧な仕様の出来上がり→でもこれってトラブルの元だよね(お互いにとって不幸だ)
・開発を依頼する側、受ける側お互いが幸せになれる(瑕疵担保責任の範囲を明確にする)ようにするために、要件は明確化する必要がある
・攻撃の殆どはパターン化されたモノ→要件もパターン化できるのでは?→作ってみた(ライセンスはCCなので、ご自由にお使い下さい)
・今後の流れ→WG作る?、内容の精査や諸外国の要件定義との比較、英語への翻訳・公開など
OWASPの日本チャプターが結成された記念という事で、初めてのMeetingが水天宮の日本橋公会堂で開催されました。
今回もいつもの勉強会レポートと同様、速報ベース、かつ聞き取れた範囲内でざっくりとレポしていきたいと思います。
---
【OWASP/OWASP Japanについて（Benny Ketelslegers）】
・OWASPとは?
・既にご存知の方も多いですが、(Web)アプリのセキュリティ向上のための活動をしているボランティア団体です
・OWASP謹製のツール、レポート等は自由に利用する事が可能
・(有償の)会員になる必要は無いけれど、なればそれなりの特典がある(Appsecへの優待割引が適用されるなど)
・最近はAndroidセキュリティに関する活動も行っているよ
・OWASP Japanとは?
・OWASPの日本チャプターの事、メンバーや各種活動への参加は随時募集中!!
(詳しくは記事頭のリンク先をご覧下さい。)
---
【Introduction of CSP（Yosuke Hasegawa）】
・scpとは?→コンテンツセキュリティポリシーの事
・Firefox出自の機能(他のブラウザでも対応しているものがある)
・XSS根絶の切り札
・指定された以外のコースが読めない、インラインスクリプトの禁止、evalやイベントの禁止
・レスポンスヘッダで許可するリソースを指定(ブラウザの種類によって指定方法が違うケースがあるので注意)
・metaでも指定できるけど、あまりオススメしない(上書き禁止だし、metaが読み込まれるまでの間が無防備である)
・リソースの種類毎に指定が可能
・ポリシー違反時にレポートを送信できる機能もある(この機能だけ有効にする事も可能)
・しっかり指定することで、第三者によるリソースの読み込みを確実にブロックする事が可能だが、まだ過渡期の技術のため、副作用もあるので注意
・Breaking CSP
・E4X(JavaScript内でXML型をサポート、Firefoxのみ)
・HTMLをJavaScriptと解釈させれば
・自分自身(HTML)は読み込み可能
・ちゃんとDoctype宣言をすれば対応可能
---
【脆弱なWebサーバを作ってみた（仮）（Yoshinori Takesako）】
・脆弱なWebサーバを突いてみた
・実は社内の勉強会(新人参加可)でやってみた事の顛末だったり
・LASDECのセキュリティ健康診断(これで検索すると仕様書が見つかるので、各位それを見ましょう)
・Badstoreを用いたハンズオンを実施(筆者補足：isoイメージをダウンロードして、CDブートさせればすぐ環境が出来上がります、お勉強には最適ですヨ)
・検索結果(エラー画面)から、内部で走っているSQL文を推測→全部のデータを表示させてみる→それを踏まえて色々とSQL Injectionしてみよう
・エラー画面にMD5っぽいハッシュ値が出た→MD5クラック用の検索エンジンというモノも併せて活用してみる
・他にも色々と面白い?仕掛けがあるので、色々と試してみると良いお勉強になります
・Badstoreの類似教材として、以下のようなモノもあります
・IPA AppGoat
・Web Security Dojo
・OWASP WebGoat
・警告：他所様が管理しているサーバにはやってはいけません!!(不ア禁法でとっ捕まりますので)
---
【ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～（Hiroshi Tokumaru）】
・OWASP Top10とは?→ワールドワイドでのWebセキュリティを脅かす脆弱性をランク付けした、年1回の風物詩
・2004年版で出た入力値検証
・CWEとは?→Common Weakness Enumeration(ココとか)
・入力値検証→CWE-20→範囲広すぎ!!
・バリデーション至上主義な解説例(某Ajaxセキュリティな本)を滅多切り（ヲ
・バリデーションでは防げない攻撃ってのもあるんだよ
・実は2007年版以降は入力値検証は出てきていません……
---
【バイナリパッチによるAndroidアプリの改ざんとセキュリティチェックのバイパス（Yoshitaka Kato）】
・Androidアプリのリバースエンジニアリングは非常に容易→改ざんも容易
・今回はバイナリパッチで改ざんを試みます
・バイナリエディタとdexdump(SDKに収録されているツールの1つ)があれば出来ます
・バイナリデータの解析には、Dalvik opecodeが参考になります
・classes.dexというファイルが実行バイナリです→これにdexdumpを当てます
・基本的にマーケット規約上では禁止されているので、その点は注意!!→なので今回は自分で作ったアプリで試しています
・アプリ内でセキュリティチェックをかけているが、それを回避するパッチを当てる
・プロセスはこんな感じ
(1)アプリを入手し必要なファイルを抜き出す→(2)dexdumpでパッチを当てる場所を特定→(3)バイナリエディタで該当箇所を修正(チェックサム修正も併せて)→(4)CRCを再計算→(5)ZIP化と署名
---
【Broken Logic: The Test Site Fallacy（Isaac Dawson）】
・Webアプリ脆弱性スキャナを使っていますか?
・テストサイトって?→スキャナの開発会社が用意したデモ用のサイトの事
・顧客はスキャナをかけた結果(脆弱性の発見具合)でスキャナの実力を測る
・テストサイトの問題点って?→基本的にクローズドソースである(完全なるブラックボックステストである)→実際にどの位仕込まれているかが分からない
・多くのサイトがPHP+MySQL or ASP/ASP.net+MS-Accessで開発されている→プラットフォーム依存の脆弱性は???
・アプリが正常に動作しているか?→この手のテストサイトは世界中の人からアクセスされるため、正常に動作していないケースが発生する場合もある
・最も厄介なのは「非現実的または『偽』の脆弱性」が仕込まれている場合がある事
・上記のような事があるため、テストサイトでスキャナの実力を測る事は、じつはあんまりよろしくない(何せテスト結果が信頼できないから)
---
【ぼくらのすすむみち featuring Rakuten-CERT（Yusuke Gunji）】
・楽天CERTの紹介
・楽天全体での開発者数は1,600名程→これらの人が楽天の各種サービスを開発しています
・楽天グループ内部に対するセキュリティサービスを提供する組織として社内CSIRTが組織された
・楽天の開発プロセス→大きくは一般的な開発プロセスとは変わりはないが、各プロセスにおいてセキュリティプロセスを設けている
・ツールはAppScanを利用
・手動監査は基本ブラックボックステスト＋実験的にグレーボックステストも取り入れている、外注だけでなく、社内でも実施(6:4)、専門のテスターは数名程度
・監査のペースは1日1件弱ペース、最も多く発見されるのはXSS、次いでエラーコードの表示も、CSRFと続きます
・今後はセキュリティ教育や、アジャイルとセキュリティの融合に力を入れていきたいと模索中
---
【Japan ChapterからWebアプリケーションセキュリティ要件定義書の提案（Sen Ueno）】
・コレのご紹介
・早めの対策の方が、かかるコストを抑えられる→ならば要求仕様・要件定義段階だ
・開発工程での脆弱性の発見の割合→多いのは「設計」と「実装」段階
・システム開発を依頼する側→素人なので良く分からない→曖昧な仕様の出来上がり→でもこれってトラブルの元だよね(お互いにとって不幸だ)
・開発を依頼する側、受ける側お互いが幸せになれる(瑕疵担保責任の範囲を明確にする)ようにするために、要件は明確化する必要がある
・攻撃の殆どはパターン化されたモノ→要件もパターン化できるのでは?→作ってみた(ライセンスはCCなので、ご自由にお使い下さい)
・今後の流れ→WG作る?、内容の精査や諸外国の要件定義との比較、英語への翻訳・公開など