A6: セキュリティの設定ミス 2017 OWASP

セキュリティの設定ミスとは？

この名称は、OWASPトップ10の脆弱性の1つとして、できるだけ曖昧になるよう選ばれたのだと思います。設定に関するあらゆる事象を含む可能性がありますが、記述や活動に見られる共通点を整理することで、セキュリティの設定ミスの一般的なテストガイドを定義することも可能です. 

セキュリティの設定ミスの見つけ方 

システムの以下の特徴は、脆弱性の存在を示す手がかりとなります。ただし、いくつかは曖昧でテストが難しい場合もあります. 

• 十分なセキュリティ強化がなされていない。アプリ全体に関わる話で、しばしば忘れがちなAPIセキュリティも含まれます。現代の多くのアプリは複数の技術要素で構成されており、どの部分で問題が生じてもおかしくありません。正しくテストするには、テスト対象のシステム全体を把握する必要があります。
• ターゲットがクラウドサービスを利用している場合、認証や認可の設定も適切に行う必要があります。
• 不要な機能が有効になっていると、場合によっては危険な影響を及ぼすことがあります。例えば、必要のないポートが開放され、なおかつ脆弱なソフトウェアが稼働しているケースが挙げられます。
• 一部の管理者は怠慢で、パスワードを初期設定や推測しやすい（例: test/test）のままにすることがあります。これもまたセキュリティの設定ミスに該当します。
• ターゲットはシステムや依存関係を常に最新の状態に保つ必要があります。最新状態であるだけでなく、各コンポーネントが有効であり、適切な設定がされているかを確認することも重要です。
• セキュリティに関する設定が安全でない値に設定されている場合。
• サーバがセキュリティヘッダーや指令を返さない場合があります。返す際には、適切なセキュリティ値が含まれている必要があります。
  

このような脆弱性を防ぐには、いくつかの対策を講じる必要がある

これらのベストプラクティスは特定の目的を達成するためのものですが、その目的を明確にすることで、より精度の高いテストが可能となります. 

• クラウドストレージの設定ミス
• ネットワークインフラの設定テスト
• アプリプラットフォーム設定のテスト
• 代替HTTPメソッドのテスト
• HTTP Strict Transport Securityのテスト

1. ‍ネットワークインフラの設定テスト
   

公開された管理パネルの存在や有名な脆弱性の悪用まで、ネットワーク経由で行われる設定に依存するあらゆる攻撃がこのカテゴリに含まれます. 

2. ‍クラウドストレージの設定ミス
   

企業はAmazonのS3バケットなどのサービスを十分理解せずに利用していることが多く、設定ミスが発生して認証なしのアクセスが可能になる場合があります.

3. ‍代替HTTPメソッドのテスト
   

第5章（アクセス制御の不備）でも触れたように、OPTIONSメソッドを使って実行可能なHTTPメソッドを調べることができます。サーバで完全に実装されていないHTTPメソッドが含まれることもあります. 

4. ‍HTTP Strict Transport Securityのテスト
   

バグバウンティハンターにとってはあまり興味深い内容ではありませんが、ペンテスターはこれをベストプラクティスとして報告すべきです。ウェブサイトは常にhttps版に誘導するべきです. 

‍では、どうやって発見するか？

セキュリティ設定ミスを探すには、特定の設定について推測を立てるか、GitHubでソースコードを確認するなどしてシステムの仕組みへのアクセスが必要です。また、未確認の問題は脆弱性とは言えないため、調査結果の確認も求められます. 

まずは、Googleドーキングでconfファイル、yaml、xmlなど設定関連のファイルを探す方法から始められます. 

```xml
filtype:cfg or filetype:yml or filetype:xml or intitle:"Config" or ...
```

Googleドーキングに加え、GitHubでも同様の手法が使えます。通常、開発者はパスワードを環境変数で隠す傾向にあるものの、その他の設定はそのまま公開されていることが多いです. 

設定ファイルに出会った際は、各設定が何のためにあるのか、またその設定が安全でない可能性があるかを、検索や該当コンポーネントのマニュアルから調べる必要があります。

セキュリティ設定ミスの例

細部に注意を払った結果、あるハッカーはバグバウンティ中にAPIキーを発見し、300ドルを獲得しました. 

https://hackerone.com/reports/1066410

調査中、Google APIキーを含むファイルが発見されました。このAPIキーはURL短縮に利用され、攻撃者が自社のURLに見せかける手段となりました。これにより、各種フィッシングや詐欺攻撃が可能となる恐れがあります。また、攻撃時には「https://lnk.clario.co/?link=[URLHERE]」のように、URL内に「clario.co」が含まれていれば任意のURLを受け入れるオープンリダイレクトが確認されました。これらは、公開スクリプト内に秘密トークンが存在する場合や、別エンドポイントでオープンリダイレクトが発生している例として優れています。

別の例として、「yourdarkshadow」というユーザが、ヘッダーの設定不備からセキュリティ設定ミスが生じていることを発見しました。 https://hackerone.com/reports/12453 これは、いわゆるダウングレード攻撃からサイトを守るためのStrict-Transport-Securityヘッダーに関する問題です。

‍

セキュリティの設定ミスの修正方法

• セキュリティや設定が本番環境と同一の新環境を容易に展開できるよう、自動化システムを整備する必要があります。
• DTAP環境（開発、テスト、受け入れ、本番）は、認証情報を再利用しない前提で、理想的には全て同一であるべきです。
• 必要最低限の機能のみを有効にし、不要なコンポーネントは無効化する必要があります。これには、存在が知られていない影のAPIも含まれます。
• クラウドストレージ戦略（例: S3バケット）に焦点を当てた定期的なセキュリティレビューのプロセスを導入する必要があります。
• 同一ハードウェアを共有する場合、テナントの分離を含めたコンポーネントの適切な分離を行う必要があります。
• 全てのコンポーネントに対して、明確なセキュリティプロファイルを定義する必要があります。
• アプリは常にセキュリティ指令（ヘッダー等）を送信すべきです。
• セキュリティ設定の検証は可能な限り自動化し、本番環境に反映される前に問題を検出できるようにすべきです。静的コードレビューも有用です。