今だからこそ振り返ろう！owasp top 10

今だからこそ振り返ろう！OWASP Top 102017/3/4 YAPC::Kansai@mahoyaya

アジェンダ自己紹介 OWASPについて OWASP Top 10について OWASP Top 10の概要 OWASP Top 10の詳細 OWASP Top 10を振り返って OWASPの成果物を活用しよう

@mahoyaya

Name: 一ノ瀬太樹 Work : セキュリティエンジニア Twitter: @mahoyaya blog: http://mahoyaya.hateblo.jp GitHub: https://github.com/mahoyaya Affiliation: 　 Perl 入学式東京サポーター　　　 OWASP Japan プロモーションチーム　　　脆弱性診断研究会　　　 OWASP ZAP User Group　　　 HASH コンサルティング株式会社

http://mahoyaya.hateblo.jp/

http://mahoyaya.hateblo.jp/

https://github.com/mahoyaya

https://github.com/mahoyaya

What is OWASP?

OWASP は安全なソフトウェアの設計・開発・習得・運用と維持に関する活動を支援する、非営利の団体。OWASP のツールやドキュメントなど、すべての成果物は無料で利用可能。誰でも参加可能。

国際的なコミュニティ

日本では？ OWASP Japan 2012.3 OWASP Kansai 2014.3 OWASP Kyushu 2015.3 OWASP Sendai 2016.1 OWASP Fukushima 2016.2 OWASP Okinawa 2016.2OWASP Night や OWASP DAY といった定期的な勉強会を実施しています。

どんなプロジェクトがあるの？現時点で 100以上の成果物が公開されています

https://www.owasp.org/index.php/Category:OWASP_Project

工程別に活用可能な資料・ツールの紹介

https://speakerdeck.com/owaspjapan/owasp-contents-reference

日本独自の成果物

OWASP の成果物で最も規模が大きい !!CHEAT SHEET SERIES

概要Builder （開発）、 Breaker （テスト）、 Defender （運用・保守）を対象にセキュリティを高めるための知識／機能を実装するための方法論を紹介特徴ドラフト版を含めて 2015 年 10 月時点で 48 ものチートシートが公開され、いずれも頻繁に更新されている

OWASP の成果物で最も規模が大きい !!CHEAT SHEET SERIES設計・開発時に活用したいチートシートが多数存在機能の安全な実装手法や脆弱性への対策などを紹介

OWASP の成果物で最も規模が大きい !!CHEAT SHEET SERIES2016 年 12 月、チートシートシリーズ概要日本語版 (2016 年版 ) を公開しました !

「ＪＰＣＥＲＴの資料へのリンク付き」「ＪＰＣＥＲＴ以降に公開されたチートシートにも対応」2016 年版では全部で 60 のチートシートになっています。

短縮 URL ：https://goo.gl/fNPGwB

WEB 以外は・・・

OWASP Mobile Top 10 https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10

OWASP IOT Top 10 https://www.owasp.org/images/7/71/Internet_of_Things_Top_Ten_2014-OWASP.pdf

OWASP Embedded Application Security https://www.owasp.org/index.php/OWASP_Embedded_Application_Security

OWASP Top 10

OWASP Top 10 とは？OWASP Top 10 の主要目的は、最も重要な Web アプリケーションセキュリティ上の弱点を、開発者、デザイナー、アーキテクト、管理者およひ組織に教育すること。Top10 は、リスクの高い問題に対する基本的な保護手法、およひ次ステップへのガイダンスを提供します。OWASP Top 10 2013 日本語版

https://www.owasp.org/images/7/79/OWASP_Top_10_2013_JPN.pdf

OWASP Top 10 概要

OWASP Top 10 – 2013 概要A1 – インジェクションA2 – 認証とセッション管理の不備A3 – クロスサイトスクリプティング (XSS)A4 – 安全でないオブジェクト直接参照A5 – セキュリティ設定のミスA6 – 機密データの露出A7 – 機能レベルアクセス制御の欠落A8 – クロスサイトリクエストフォージェリ (CSRF)A9 – 既知の脆弱性を持つコンポーネントの使用A10 – 未検証のリダイレクトとフォーワード

OWASP Top 10 詳細

OWASP Top 10 – 2013A1 – インジェクションA2 – 認証とセッション管理の不備A3 – クロスサイトスクリプティング (XSS)A4 – 安全でないオブジェクト直接参照A5 – セキュリティ設定のミスA6 – 機密データの露出A7 – 機能レベルアクセス制御の欠落A8 – クロスサイトリクエストフォージェリ (CSRF)A9 – 既知の脆弱性を持つコンポーネントの使用A10 – 未検証のリダイレクトとフォーワード

A10-未検証のリダイレクトとフォワードWeb アプリケーションは、頻繁にユーザを他の画面やウェブサイトへリダイレクト・フォーワードしますが、信頼されていないデータを用いて、転送先画面を決定しています。適切な検証がないと、攻撃者は被害者をフィッシングサイトやマルウェアサイトへリダイレクトできたり、フォーワードで閲覧権限のない画面へアクセスできます。

OWASP Top 10 日本語版よりhttps://www.owasp.org/images/7/79/OWASP_Top_10_2013_JPN.pdf

A10-未検証のリダイレクトとフォワード• 信頼境界をこえて入ってきた外部入力値をそのまま利用

• hidden フィールドに URL を埋め込んでいるなど• 悪意のある URL に書き換えたリンクに付け替えて罠を設置できる

• 被害者はフィッシング詐欺やマルウェア感染被害の恐れがある• ユーザー入力値の転送先がパラメータ指定されており、改変によって送信先を変更できる

• 情報漏えい• 脆弱性を利用されたサイトは風評被害のリスクも

A10-未検証のリダイレクトとフォワード対策• 可能であればリダイレクトやフォワードの利用を避ける• 外部入力値を直接パラメータに利用しない

• 数値などを利用してマッピングする• URL の確実な検証

• 外部アクセスの場合はクッションページを挟む

A9-既知の脆弱性を持つコンポーネントの使用ライブラリ、フレームワーク、およひ他のソフトウェアモジュールなどのコンポーネントは、ほとんど常にフル権限で実行されます。脆弱なコンポーネントが悪用される場合、深刻なデータ損失やサーバ乗っ取りまでに至る攻撃ができます。既知の脆弱性を持つコンポーネントを使用するアプリケーションは、アプリケーションの防御を弱体化し、様々な攻撃と影響も可能になります。


A9-既知の脆弱性を持つコンポーネントの使用• 古いバージョンのソフトウェアは大体脆弱性がある• パッチは新しいものにだけ出る場合が多い• １つの脆弱なコンポーネントがあることにより、全体が侵される場合も

A9-既知の脆弱性を持つコンポーネントの使用対策• 常に最新バージョンを使う（希望）• 使用コンポーネントとバージョン、依存関係をすべて把握する（希望）• 最新のセキュリティ情報を把握（希望）• イケてるエンジニアは vuls• OWASP Dependency Check（ Perlは非対応）• 某人気 CMS なんかは特に最新バージョンを使いましょう• プラグイン系もサポート状況を確認すること

A8- クロスサイトリクエストフォージェリ（ CSRF ）CSRF攻撃は、脆弱性のある Web アプリケーションに対し、ログオンしている被害者のブラウザから、偽造されたHTTP リクエストを送信させます。そのリクエストには、被害者のセッションクッキーや他の自動的に組み込まれた認証情報が含まれています。これにより、攻撃者は脆弱性のあるアプリケーションに、ユーザからの正当なリクエストとして認識されるリクエストを被害者のブラウザに生成させることができます。


A8- クロスサイトリクエストフォージェリ（ CSRF ）• 攻撃者が被害者になりすまして機能を実行する攻撃• 偽造したリクエストを被害者のブラウザが持っている情報を利用して送信させる• 被害者のブラウザが持っている正規の情報で送信されるため、受信したサーバ側では攻撃と判断できない（しにくい）• 標的型攻撃で使われると厄介

• CSRF 脆弱性のあるパスワード変更機能など• 間接的な攻撃でわかりにくく理解できていない人も多い• 被害者の操作が必要になるため、危険度は低くなりがち

A8- クロスサイトリクエストフォージェリ（ CSRF ）

http://www.ipa.go.jp/security/vuln/websecurity.html より引用

A8- クロスサイトリクエストフォージェリ（ CSRF ）対策• 機能を実行する前のページでトークン（予測できないランダムな文字列）を hidden フィールドに発行！• 機能実行時にトークンチェック！• トークンは最低でもユーザセッション毎にユニークに！• 機密情報を扱う場合は某超巨大 EC サイトのように再認証処理• 環境的に問題ないことがわかっていれば Referer の確認もよいが、正規表現で m/^www.example.com.*/ みたいな判定は NG

A7- 機能レベルアクセス制御の欠落ほとんどの Web アプリケーションは、機能を UI で表示する前に、機能レベルのアクセス権限を検証しています。但し、各機能がアクセスされる際に、アプリケーションはサーバ上で、同じアクセス制御チェックを実行しないといけません。リクエストが検証されていない場合、適切な承認もされていないため、攻撃者はリクエストを偽造して、狙った機能にアクセスできます。


A7- 機能レベルアクセス制御の欠落• リクエストに対する適切なアクセス制御処理を実施していない

• ログインしていなくても、 URL を直打ちすれば機能が利用できる• ログインさえしていれば、 URL を直打ちしてロールの制限を超えた機能が利用できる

• ゲストや一般ログインユーザーの不正行為• 機微情報の閲覧・改ざん、チート行為、不正送金

A7- 機能レベルアクセス制御の欠落対策• 全ての機能で認可制御のテストを実施• 統一された利用しやすい認可制御モジュールの設計• 全ての機能で認可制御を行う• 制御メカニズムはデフォルトですべてを拒否し、相応しいロールを要求• 機能を表示しない設計は緩和策であり、対策ではない

A6- 機密データの露出多くの Web アプリケーションは、クレジットカードや納税者番号、認証情報などの機密データを適切に保護していません。攻撃者は、これらの脆弱に保護されているデータを窃取・改変して、クレジットカード詐欺や個人情報盗難などの犯罪を犯します。機密データは、保存時や転送時に関わらず、特別な保護をされるべきです。また、ブラウザとの間で取り交わされる際に、特別な注意も払うべきです。


A6- 機密データの露出• 機密情報の平文保存• 危殆化した暗号化術の利用• 不適切なヘッダ情報• キャッシュ制御の不備• バックアップファイル

• wp-config.php.bak, wp-config.php~

A6- 機密データの露出対策• 不要な機密情報を持たない• 保護する機密情報の把握と暗号化• 強いアルゴリズムと鍵の利用

• FIPS 140 validated cryptographic modules• 扱うデータに対して適切なヘッダ情報を付与する

• キャッシュ対象を正しく見極める• 機密情報は含まれていませんか？

• バックアップファイルの保存ルールを策定• 公開ディレクトリには保存しない

A5- セキュリティ設定のミス認証とセッション管理に関連するアプリケーション機能は、しばしば正しく実装されていません。そのため、攻撃者はパスワード又は鍵、セッショントークンを漏洩させたり、他の実装の不備を悪用してなりすますことができます。


A5- セキュリティ設定のミス • 脆弱なソフトウェア利用• HSTS の利用不備

• HTTP アクセス時にリダイレクトしていない• 不要な機能の有効化

• SSH での root ログイン、管理画面のアクセス制限• httpd のディレクトリスティング

• デフォルトのログインアカウント• フレームワークやライブラリのセキュリティ

• スタックトレースなどエラー情報が表示設定のまま• サンプルアプリケーションの脆弱性• セッション ID の URLパラメータ化

A5- セキュリティ設定のミス対策 • ソフトウェアの適時更新• HSTS は https に 301 リダイレクトをお忘れなく• OpenVAS などの診断ツール利用• フレームワークやライブラリのセキュリティ設定についてよく確認

A4- 安全でないオブジェクトの直接参照オブジェクトの直接参照は、開発者がファイル又はディレクトリ、データベースのキーなど、内部に実装されているオブジェクトへの参照を公開する際に発生します。アクセス制御チェックや他の保護が無ければ、攻撃者はこれらの参照を用い、アクセス権限のないデータへアクセスすることができます。


A4- 安全でないオブジェクトの直接参照• いわゆる認可制御の不備• 権限を持たないユーザーが情報を参照したり、機能を実行したりできる状態• ユーザーが入力するパラメータを改変することにより、利用できないはずの機能が利用できてしまうなど

A4- 安全でないオブジェクトの直接参照対策• ユーザーが改変可能なパラメータをオブジェクトの呼ひ出しに直接利用しない• ユーザーがパラメータを改変しても意味がないようにホワイトリストにする

• ドロップダウンリストで番号選択させ、 DB で機能とマッピングする• ユーザーが機能を利用する際は、必ず認可状態を確認する

A3- クロスサイトスクリプティング（ XSS ）XSS欠陥は、アプリケーションが信頼されていないデータを受け取る時、適切な検証やエスケープをせずに、ウェブブラウザに送信する際に発生します。 XSS により、攻撃者は被害者のブラウザでスクリプトを実行でき、ユーザセッションのハイジャックやウェブサイトの改竄、またユーザを悪意のあるサイトにリダイレクトすることが可能です。


A3- クロスサイトスクリプティング（ XSS ）• セキュリティエンジニアが大好きな脆弱性（誤• 信頼境界を越えて入力された値を適切に検証していない、入力データの中身をエスケープせずにブラウザに送るとおこる • 反射型、蓄積型、 DOM ベースの 3種類• 内部ソースを含め、ほぼ全てのデータソースに攻撃可能 • セッション ID の窃取、コンテンツ改ざん、リダイレクト、マルウェア感染• 正規サイトのドメインを利用したフィッシング• DOM ベースはサーバ通信を介さない

A3- クロスサイトスクリプティング（ XSS ）対策• 全ての外部入力データは出力するタイミングで適切にエスケープする必要がある• 具体的には実体参照や URL エンコード、 HEX エンコード、 Unicode エンコードなど目的に合わせて利用• XHR のブラウザ直接参照にも対策を！

• 適切な Content-Type• X-Content-Type-Options: nosniff• JSON の場合は念のため <> もエスケープ

• 可能であれば Content Security Policy(CSP) を利用する

A3- クロスサイトスクリプティング（ XSS ）対策• HTML の実体参照

エスケープ対象実体参照& &< <> >“ "‘ '/ /

A3- クロスサイトスクリプティング（ XSS ）対策• 主なパターンごとの対策

エスケープ対象対策HTML HTML Entity EncodingGET Param URL EncodingCSS HEX EncodingJavaScript HEX Encoding

Unicode EncodingBackslash Encoding

DOM Based XSS はこちらを参照https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

A2- 認証とセッション管理の不備認証とセッション管理に関連するアプリケーション機能は、しばしば正しく実装されていません。そのため、攻撃者はパスワード又は鍵、セッショントークンを漏洩させたり、他の実装の不備を悪用してなりすますことができます。


A2- 認証とセッション管理の不備• EC サイトなどセッション管理が必要なアプリケーションでおこる• ログイン情報の平文送信• 手作りのセッション管理機能• セッション ID の漏洩• アプリケーション機能を利用時の認証状態確認不備• ログアウト機能の実装不備• パスワード関連機能の実装不備

A2- 認証とセッション管理の不備対策（？）OWASP の Application Security Verification Standard (ASVS) エリア V2 ( 認証 ) と V3 ( セッション管理 ) において定義されたすべての認証とセッション管理の要件を満たす


A2- 認証とセッション管理の不備対策（？）OWASP の Application Security Verification Standard (ASVS) エリア V2 ( 認証 ) と V3 ( セッション管理 ) において定義されたすべての認証とセッション管理の要件を満たす


なるほど！

A2- 認証とセッション管理の不備（脱線）OWASP Application Security Verification Standard (ASVS)

OWASP アプリケーションセキュリティ検証標準 3.0.1https://www.jpcert.or.jp/securecoding/OWASP_ASVS_20160623.pdf

A2- 認証とセッション管理の不備対策• セッションマネージャーを自作しない• セッション ID を URL 、エラーメッセージ、ログから漏洩させない• ログイン前後で必ずセッション ID を変更する• HSTS を利用し、クッキーに HttpOnly と secure を設定する• 機能を実行する前には認証状態を確認（現実には認可状態も）• ログアウトを実装し、ログアウト処理ではセッションクッキーの削除とセッション情報の削除を確実に実施する• パスワードリマインダ機能でパスワード設定 URL をメール送信する際は予め登録された宛先に限定する• パスワード変更には旧パスワードを求める• アカウントロック機能

A1- インジェクションSQL と OS 、 LDAP などのインジェクション欠陥は、信頼されていないデータがコマンド又はクエリの一部としてインタプリタに送信される際に発生します。攻撃者の悪意のあるデータは、意図しないコマンドの実行や適切な権限のないデータアクセスをさせるように、インタプリタを騙すことができます。


A1- インジェクション• 不動の 1位である危険な脆弱性• 多くの場合、信頼境界を越えて送信されるデータをアプリケーションがそのまま利用することで起こる• インジェクションの問題は、 SQLクエリ、 LDAPクエリ、

XPathクエリ、 NoSQLクエリ、 OS コマンド、プログラム引数などで発見される

• インジェクションの欠陥は、コードを検査すれば検出が容易な場合が多い

• memcachedなど外部公開不要なサービスを公開した結果、直接値を入力されることもあるので注意

A1- インジェクション対策• 信頼境界を越えて入力されるデータとは、サービス利用者が書き換え可能な全てのデータ（クッキー、ヘッダ、フォーム入力値など）• SQLインジェクションは必ずプレースホルダを使う（可能であれば静的にする）

• OSコマンドは極力利用しないもしくは、シェルから起動しない方法を利用

• 各言語やフレームワークで定められたエスケープ構文を利用

• 外部に公開しなくてよいサービスは公開しない• サーバ実装では予期せぬパラメータがきたら切断

OWASP Top 10 を振り返って

OWASP Top 10 を振り返って　今回紹介した内容を一気にこなすのはなかなか難しいものの、セキュリティ需要は増加の一途です。そこで、まず開発者がまず何をするべきかという部分に重点を置いたOWASP Proactive Controls 2016 というものがあります。OWASP Proactive Controls 2016 では「早期に、繰り返しセキュリティを検証する」を一番大切なこととしています。本来はテストシナリオやテストコードを準備している段階からセキュリティを考慮する必要があるということです。また、さまざまなセキュリティ機能を十分に活用するためには、要件定義の時点でセキュリティ要件を整理することが重要です。セキュリティ要件については OWASP ASVS がガイドラインとして役に立ちます。

OWASP の成果物を活用しよう• 反復可能なセキュリティプロセスと標準セキュリティ制御の確立が重要

• 要件定義に OWASP ASVS の活用• 設計に OWASP Cheat Sheet• フレームワークのセキュリティ機能を最大限に活用• セキュアな開発ライフサイクルのスコアリングフレームワークに OpenSAMM• ペネトレに OWASP Testing Guide

さいごに

OWASP Proactive Controls 2016 https://www.owasp.org/images/a/a8/OWASPTop10ProactiveControls2016-Japanese.pdf

　今回は OWASP Top 10 2016 が待ちきれなかったので、私見と診断あるあるを含めて OWASP Top 10 2013 を振り返りました。そして、どのような脆弱性が潜んでいるのか、どのような対策が効果的なのか紹介しました。また、 OWASP Top 10 に加えて簡単に紹介した OWASP ASVS v3 やOWASP Proactive Controls 2016 は OWASP Japan によって日本語化されていますので、是非活用してください。OWASP ASVS 3.0.1https://www.jpcert.or.jp/securecoding/OWASP_ASVS_20160623.pdf

ありがとうございましたWEB をたしかなものに

今だからこそ振り返ろう！owasp top 10

Engineering