OWASP Top 10 – 認証の不備 in OWASP Okinawa 2018.6.8

Transcript

1. 1 OWASP Top 10 – 認証の不備 OWASP Okinawa 2018.6.8 Tadashi

   SHIROMA

2. 2 自己紹介: Who am I?  城間 政司（しろま ただし） 

   出身：沖縄県西原町、琉球大学工学部情報工学科卒  専攻・興味： デジタルアイデンティティ、ID連携（OAuth2, OpenID Connect等）、 セキュリティリスクアセスメント、リバースエンジニアリング  趣味：バランスボールチェア（2009-）  Twitter: @shiropanman Copyright 2018 Tadashi Shiroma Proprietary

3. 3 本日の内容  OWASP Top 10と認証の不備について  認証とは？ HTTPの認証の仕組み 

   認証の不備 攻撃シナリオ 対策  まとめ

4. 4 OWASP Top 10の推移 1 1 1 2 3 7

   3 2 2 4 4 5 8 6 5 6 6 9 9 7 6 3 8 7 5 4 8 10 2010 2013 2017 OWASP Top 10 2010-2017 インジェクション XSS（クロスサイトスクリプティング） 認証の不備 安全でないオブジェクト直接参照 CSRF 不適切なセキュリティ設定 既知の脆弱性のあるコンポーネントの使用 機微な情報の漏えい、安全でない暗号、保存 アクセス制御の不備 XML外部エンティティ参照（XXE) 安全でないシリアライゼーション 不十分なロギングとモニタリング

5. 5 OWASP Top 10の推移 1 1 2 2 4 4

   4 2 2 10 8 7 5 3 3 7 3 2 2 4 4 1 2 3 7 5 5 6 6 2 1 1 1 7 7 6 8 8 8 7 6 3 10 10 6 5 6 10 10 6 9 9 10 10 9 9 6 3 4 8 10 5 5 8 9 10 10 3 2003 2004 2007 2010 2013 2017 OWASP Top 10 2003-2017 許可されていない入力 安全でないオブジェクト直接参照 アクセス制御の不備 認証の不備 XSS（クロスサイトスクリプティング） バッファオーバーフロー インジェクション 不適切なエラー処理 機微な情報の漏えい、安全でない暗号、保存 不適切なセキュリティ設定 既知の脆弱性のあるコンポーネントの使用 不適切な設定管理 機微な情報の漏えい、不適切な通信、トランスポート層保護 XML外部エンティティ参照（XXE) 安全でないシリアライゼーション 不十分なロギングとモニタリング CSRF サービス妨害

6. 6 本日の対象者 – 認証の不備 一般ユーザ向け 開発者向け 例：パスワードの使い回しの是非 多要素認証使いましょう 例：セッション管理の注意点 パスワード認証の注意点

7. 7 認証とは？  認証（にんしょう）とは、何かによって、 対象の正当性を確認する行為を指す。 （出典：Wikipedia）  Webサービスでの認証とは？ 一般的には、ユーザとそのユーザが主張するアカ ウントの紐づけが正しいものか確認するプロセス

   他の例として、Web APIにアクセスするときに許 可されたWebサービスかどうかを確認する…など もある →ユーザの認証だけとは限らない サービスにログイン したいです Webサービスのユーザ認証の流れ 認証される人 IDはjohn パスワードは*******です 認証される人 IDとパスワードを 教えてください 認証する人 認証しました このあとはこのチケットを 提示してください 認証する人

8. 8 HTTPな認証の仕組み  ログイン時にIDとパスワードを入力・送信し、セッションIDを含むCookieを発行  ログイン後はセッションID(Cookie)でユーザを認識 最近では、IDとパスワードの組み合わせによる認証のほかに、SMSを利用した認証や、 OpenID Connect&OAuth（例：facebookアカウントでログイン）を利用した認証も

9. 9 認証の不備  不十分なパスワードポリシー 数字だけのパスワードを許可 例：12345678 よくあるパスワードを許可 例：password123  非暗号化な通信上でのパスワード送受信

   http通信上のログイン  認証システムの不備 無限にログイン試行が可能  セッション管理の不備 ログアウト時にセッションIDが無効化されない URLにセッションIDが含まれる 例：jsessionid…

10. 10 攻撃シナリオの例  攻撃シナリオ1 – アカウントリスト攻撃 攻撃シナリオ1.5 – ブルートフォース攻撃 攻撃シナリオ1.5

    – パスワードスプレー攻撃  攻撃シナリオ2 – セッションハイジャック攻撃 攻撃シナリオ2.5 – セッションフィクセーション攻撃  攻撃シナリオ3 – データベースへのアクセス  攻撃シナリオ4 – プロトコルの実装不備

11. 11 攻撃シナリオ1 – アカウントリスト攻撃  任意の方法で入手したアカウント情報を基に、不正ログインを試みる攻撃 サイトA サイトB サイトC アカウント情報

    id: trump pw: donald123 か… id: trump pw: donald123 id: trump pw: donald123 id: trump pw: donald321

12. 12 攻撃シナリオ1.5 – ブルートフォース攻撃  よくあるパスワードを使ってログイン試行する攻撃  アカウントリスト攻撃のようにアカウント情報は必要ない  総当たり攻撃とも呼ばれる

    出典：github - danielmiessler/SecLists

13. 13 攻撃シナリオ1.5 – パスワードスプレー攻撃  パスワードを固定してログインを試行する攻撃  リバースブルートフォース 出典：https://japan.zdnet.com/article/35117214/ 出典：http://tech.nikkeibp.co.jp/it/atcl/column/14/346926/090100042/

14. 14 攻撃シナリオ2 – セッションハイジャック攻撃  任意の方法でセッションIDを盗み、攻撃者がユーザになりすます攻撃  セッションIDの入手方法例 http通信を盗聴 XSSを利用してセッションIDのCookieを送信

    セッションIDの生成パターンから推測 セッションフィクセーション攻撃（後述）

15. 15 攻撃シナリオ2.5 – セッションフィクセーション攻撃  ユーザのセッションIDを攻撃者が指定したもので Webサービスを利用させ、攻撃者自身も同じセッ ションIDを使うことでアカウントを乗っ取る攻撃  URLでCookieを指定できるサイトや、

    .co.jpドメインのCookieを受け入れるなど 任意のCookieを指定できる脆弱性を悪用

16. 16 攻撃シナリオ3 – データベースへのアクセス  脆弱性などを突かれるなどして、内外部の攻撃者にデータベースへアクセスされる  パスワードをハッシュ化していない場合は容易にパスワードを入手できる ID Password

    User1 Aiueo User2 Pass1234 User3 qwerty User4 abc123

17. 17 攻撃シナリオ4 – プロトコルの実装不備  facebookやtwitterのアカウントを使ったログインなどで使われている OAuthやOpenID Connectのプロトコルの実装の不備を突いた攻撃  トークン置き換え攻撃やCSRFによる攻撃などがある

    トークン置き換え攻撃の内容 出典：http://www.atmarkit.co.jp/ait/articles/1710/24/news011_2.html

18. 18 対策 – OWASP Top 10 2017より  自動化された攻撃、アカウントリスト攻撃、総当たり攻撃、盗まれたユーザ名/パスワード を再利用した攻撃を防ぐために、できる限り多要素認証を実装する。

     初期アカウント(特に管理者ユーザ)を残したまま出荷およびリリースしない。  新しいパスワードまたは変更後のパスワードがTop 10000 worst passwordsのリストにな いか照合するようなパスワード検証を実装する。  NIST SP 800-63 B's guidelines in section 5.1.1 for Memorized Secretsや最近の調査に 基づくパスワードの方針に、パスワードの長さ、複雑性、定期変更に関するポリシーを適合 させる。  アカウント列挙攻撃への対策としてユーザ登録、パスワード復旧、APIを強化するため、す べての結果表示において同じメッセージを用いる。  パスワード入力の失敗に対して回数に制限するか、段階的に遅延察せる。すべてのログイン 失敗を記録するとともに、アカウントリスト攻撃、総当たり攻撃、または他の攻撃を検知し たときにアプリケーション管理者に通知する。  サーバサイドで、セキュアな、ビルトインのセッション管理機構を使い、ログイン後には新 たに高エントロピーのランダムなセッションIDを生成する。セッションIDはURLに含める べきではなく、セキュアに保存する。また、ログアウト後や、アイドル状態、タイムアウト したセッションを無効にする。

19. 19 対策(1/5) – 多要素認証の導入  簡単なパスワードや使い回しの禁止、パスワード管理ソフトの使用などの ユーザ側の対策には限界がある  IDとパスワードの組み合わせ以外の認証要素を用いた多要素認証で対策

20. 20 対策(2/5) – 初期パスワード/簡単なパスワードの禁止  新しいパスワードまたは変更後のパスワード がTop 10000 worst passwordsのリストに

    ないか照合するようなパスワード検証を実装 する。  初期アカウント(特に管理者ユーザ)を 残したまま出荷およびリリースしない 出典：#mkmk_nmatayoshi 出典：github - danielmiessler/SecLists

21. 21 対策(3/5) – 公的ガイドラインへの準拠  NIST SP 800-63 B's guidelines

    in section 5.1.1 for Memorized Secretsや最近の調査に 基づくパスワードの方針に、パスワードの長さ、複雑性、定期変更に関するポリシーを適合 させる。

22. 22 対策(4/5) – その他  アカウント列挙攻撃への対策としてユーザ登録、パスワード復旧、APIを強化するため、す べての結果表示において同じメッセージを用いる。 →ダメな例：ユーザのIDが存在するかしないかでログイン失敗時のメッセージが変わる  パスワード入力の失敗に対して回数に制限するか、段階的に遅延させる。すべてのログイン

    失敗を記録するとともに、アカウントリスト攻撃、総当たり攻撃、または他の攻撃を検知し たときにアプリケーション管理者に通知する。  サーバサイドで、セキュアな、ビルトインのセッション管理機構を使い、ログイン後には新 たに高エントロピーのランダムなセッションIDを生成する。セッションIDはURLに含める べきではなく、セキュアに保存する。また、ログアウト後や、アイドル状態、タイムアウト したセッションを無効にする。 →認証や暗号に関するシステムは独自に開発するよりも、 ライブラリやフレームワークの利用を推奨

23. 23 対策(5/5) – リスクベース認証  ログイン場所や時間など、ユーザの普段のログイン情報/行動と異なる場合に、 多要素認証を要求したり、アラートメールをユーザに送信する  例えば… 日本国内からサービスを利用していたアカウントに、海外からのログインがあった

    →「海外からログインがありました！」とユーザにメールで注意喚起 アクセス記録がない端末から初めてログインがあった →ID&パスワードによる認証に加えて、CAPTCHAによる認証を追加

24. 24 対策 – 詳しくはOWASPの各種ガイドラインで！  ASVS V2 Authentication Verification Requirements

    https://www.owasp.org/index.php/ASVS_V2_Authentication  ASVS V3 Session Management https://www.owasp.org/index.php/ASVS_V3_Session_Management  Authentication Cheat Sheet https://www.owasp.org/index.php/Authentication_Cheat_Sheet  Forgot Password Cheat Sheet https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet  Session Management Cheat Sheet https://www.owasp.org/index.php/Session_Management_Cheat_Sheet  OWASP Development Guide https://www.owasp.org/index.php/Projects/OWASP_Development_Guide  Testing for authentication https://www.owasp.org/index.php/Testing_for_authentication

25. 25 まとめ  認証の不備について 攻撃シナリオや対策の紹介  IDとパスワードによる認証やセッション管理などの不備が攻撃に利用される 多要素認証の提供や弱いパスワードの禁止、適切なセッション管理などの対策が必要  OWASPの各種ガイドラインを参考にして、不備がないかチェック