セキュリティ規則と推奨事項

以下に記載するセキュリティガイドラインは、NTT CPaaSプラットフォーム内およびNTT CPaaS APIを通じて、認証やファイル転送など、最も一般的なユーザー操作を安全に実行する際の指針を示すことを目的としています。

アカウントのセキュリティ

NTT CPaaSアカウントを作成したら、そのNTT CPaaSアカウント (NTT CPaaS Webインターフェースとも呼ばれます) にサインインする際に、ユーザー名とパスワードが必要になります。なお、ユーザー名には特殊文字を含めることはできず、一度生成すると変更できないことにご留意ください。

パスワード管理 [#password-management-account-security]

NTT CPaaSのパスワード強度レベルは、デフォルトで「非常に高い」に設定されています。パスワードに関する一般的な要件は以下の通りです：

• 小文字
• 大文字
• 数字
• 10～50文字
• 記号
• 同じ文字を3回以上繰り返さないこと
• 使用可能な文字A～Z、a～z、0～9、および記号

パスワードを設定する際、アカウントを保護しやすくする、以下の重要なヒントをぜひ参考にしてください：

• 異なるユーザー間で同じパスワードを使用 しない こと。
• 他の場所、特に他のオンラインチャネル／サービスで既に使っているパスワードを使用 しない こと。
• パスワードは、少なくとも四半期ごとに定期的に 変更 すること。
• NTT CPaaSのスタッフを含め、第三者にパスワードやAPIキーを 絶対に 教えないこと。代わりに、NTT CPaaSのWebインターフェースにあるパスワード再設定フォームを利用するか、適切なインターフェースでAPIキーを管理すること。

アカウントユーザー [#account-users-account-security]

セキュリティを最大限に高めるには、アカウントのユーザー資格情報を以下の方法で管理するようにしてください：

1. NTT CPaaS Webインターフェイス内で、Settings (設定) → User & Teams (ユーザーとチーム) に移動します。
   • 管理者ユーザーについては「アカウントマネージャー」のロールに設定したままにし、トラフィックのブロードキャスト権限を付与されているすべてのロールを削除します。その他のユーザーについては、「アカウントマネージャー」のロールを削除し、トラフィックのブロードキャスト権限を付与するロールを割り当てます。
   • ユーザーのGSMとメールアドレスを検証します。
2. Settings (設定) → My AccountMu (マイアカウント) に移動します。以下の一覧をリファレンスとしてご利用ください。以下のリストを参考にしてください。各設定の構成方法の詳細については、「セキュリティ設定」について詳述しているページをご参照ください。
   • 2要素認証はデフォルトで有効になっており、構成可能オプションは「Remembered (記憶済み)」または「On Each Login (ログインのたびに)」です。なお、2要素認証はAPI接続に支障を来しません。
   • パスワードの有効期間をセットアップします。
   • 最大ログイン試行回数をセットアップします。
   • ユーザーの非アクティブ日数をセットアップします。

トラフィックのセキュリティ

TLSのサポート [#support-for-tls-traffic-security]

2021年7月5日現在、当社ではTLS v1.2のみをサポートしています。以前のバージョンのサポートは終了しました。TLSバージョン1.2より低いバージョンを使用している場合、当社のプラットフォームへのリクエストを送信することはできません。現在使用しているTLSバージョンが不明な場合や、新しいバージョンへのアップグレードについてサポートが必要な場合は、サポート までお問い合わせください。

エントリーポイント固有のユーザー [#entry-point-specific-users-traffic-security]

ユーザー資格情報は、WebインターフェースまたはAPIを通じてご利用いただけます。APIユーザーと、Webインターフェース経由でNTT CPaaSを利用するユーザーを混同しないようご注意ください。

API用 (IPセーフリストからのみアクセス可能な) ユーザーを1人保持し、残りのユーザーはWebインターフェース用に割り当てるようにすれば、接続の問題を回避しやくなります。接続の問題を引き起こさないようするには、APIユーザーはIPセーフリスト に登録されたURL経由でのみAPIを利用できるようにすることが望ましいです。

トラフィックのブロードキャスト [#traffic-broadcast-traffic-security]

SMPP経由でAPIを使用する場合は、トラフィックをブロードキャストするための専用ユーザーを作成し、SSL接続を介してそのユーザーの資格情報を使ってトラフィックをブロードキャストするようにしてください。 HTTP経由でAPIを使用する場合は、ユーザーの資格情報を含むトラフィックを送信しないようにし、代わりにAPIキーをお使いください。

API 接続のセキュリティを強化するには、API キーの作成について詳述しているページで推奨されているように、API キーまたはトークンによる認証方式を使用することをお勧めでします。そうすることで、ネットワーク上のデータ転送が傍受されるリスクを軽減できます。

APIキーごとに、許可するIPアドレスのIPセーフリストを、個別のIPアドレスまたはIP範囲単位でセットアップします。NTT CPaaSのWebインターフェースから設定を行う場合は、ログインして Manage API Keys (APIキーの管理) に移動します。API経由で設定を行う場合は、APIキーの作成時にPOST APIリクエストを使用します。

以下に、使用可能なIPアドレスおよびIP範囲の例を示します：

• 許可されたIPリスト：192.168.1.1;192.168.1.2;192.168.1.3
• IP範囲：192.168.1.0/24

SSLプロトコルを使用して、トラフィックを常に暗号化された接続経由でブロードキャストするようにしてください。

• SMPP SSLエンドポイントについては、SMPP仕様 について詳述しているページをご参照ください。
• HTTP SSLエンドポイントについては、ベースURL について詳述しているページをご参照ください。

IPセーフリスト [#ip-safelisting-traffic-security]

IPセーフリストを使用すると、信頼できるIPアドレスまたはIP範囲のリストを作成し、そのリストに登録されたIPアドレスまたはIP範囲から、人間ユーザーやAPIがNTT CPaaSプラットフォームにアクセスできるようにすることができます。

IPセーフリストを使用する時は、以下の規約とベストプラクティスにご留意ください：

IPセーフリストは、ユーザー単位またはAPIキー単位でセットアップできます：

• ユーザー単位

  • セーフリストに定義されたIPアドレス は、ユーザーがWebインターフェースにログインし、それぞれの資格情報を使ってトラフィックをブロードキャストしようとする時に認識されます。

• APIキー単位

  • セーフリストに定義されたIPアドレスは、APIキーを使ってトラフィックをブロードキャストしようとする時に認識されます。
  • APIキーのIPセーフリストは、Webインターフェース (Manage API keys (APIキーの管理)) から、またはAPI経由でAPIキーを作成する際にセットアップできます。

IPセーフリストは、特定のIPアドレスまたはIPアドレスの範囲に対して設定できます：

• API - 通常、静的IPアドレスまたは企業／ISPのIPアドレス範囲を使用します。
• Webインターフェース - 動的IPアドレスからのアクセスがある可能性があります (例：在宅勤務中のユーザー、モバイルネットワーク経由で接続しているユーザー、または外出中のユーザーなど)。

API関連のセキュリティ対策

このセクションでは、API接続のセキュリティを強化する方法について説明します。

ネットワーク経由のデータ転送が傍受されるリスクを軽減するには：

• セキュリティ対策が施されていないHTTPとURLパラメーターを介したSMSを組み合わせて使用すると、ネットワーク上のデータ転送が傍受されるリスクが高いため、絶対に併用しないようにしてください。
• 暗号化されていない HTTP/SMPP 接続は絶対に使用せず、以下の接続に切り替えるようにしてください：
  • 暗号化されたSSL/TLS接続 - セットアップが迅速で、より堅牢なフェイルオーバー機構を備えているため、このオプションが推奨されます。
  • IPsec VPN接続 - 手動でのセットアップが必要であり、可用性の問題が発生した場合のインシデント管理もより複雑になるため、あまり推奨されません。 これにより、お客様のプラットフォームとNTT CPaaSとの間に暗号化されたデータ通信経路が確立されます。
• メッセージの送信にGETメソッドを使用しないようにしてください

パスワードの不正使用 [#password-abuse-api-related-security-controls]

パスワードの不正使用リスクを軽減するには、有効期限のあるAPIキーまたはトークンによる認証方式を使用します。

APIセッションは、最後に正常に処理されたトークンから1時間後に失効します。また、この設定はクライアントのアカウントレベルでは変更できません。

一方、APIキーはセッションレスであり、リクエストごとに送信されます。APIキーごとに有効期間を設定することができ、その期間が過ぎると、そのAPIキーは無効または期限切れと見なされます。

対策が講じられなかった場合の潜在的なリスク

暗号化されていない HTTP/SMPP トラフィックを使用する場合のトラフィック傍受によるクレデンシャルの漏洩。これは、次の状況で発生する可能性があります。

• 安全でない HTTP を基本認証 (権限付与ヘッダーのエンコードされた形式に含まれるユーザー名とパスワード) と組み合わせて使用する場合 - これは、ネットワーク、ISP とプロキシ サービス (使用されている場合)、および NTT CPaaS Webインターフェイスの間の任意のノードで発生した可能性があります。
• クライアント ネットワークと NTT CPaaS プラットフォームの間で MITM メソッドを適用する場合。
• あらゆる種類のストレージ(デジタルおよびアナログ)で安全でない(プレーンテキスト)形式で使用される場合。NTT CPaaS は、ユーザーのパスワードを一方向のハッシュ形式で保存し、アクセス権限は少数の信頼できる従業員のみに制限されます。アクセスは第三者に許可されません。
• 交換/通信中(電子チャネル、電話、さらにはライブディスカッションを介して)安全でない(プレーンテキスト)形式で使用される場合。
• 長期間パスワードを変更していない場合。

セキュリティに関する一般的な推奨事項

• ユーザーごとに区別された、より長く複雑なパスワードを常に使用します。内部資格情報の保存と管理を強化して、将来のデータ漏洩の潜在的な原因を軽減します。
• パブリック コード リポジトリにユーザー資格情報をハードコーディングすることは避けてください。
• トークンをパスワードのように扱い、秘密にしてください。API を使用する場合は、トークンをプログラムにハードコーディングするのではなく、環境変数として使用します。

ログインページの真正性を検証してフィッシング攻撃を防ぐ

URL とサイトのコンテンツに細心の注意を払ってください。

1. ファビコンを確認してください。Webサイトは、タブに必要なアイコンを配置できます。

2. ドメイン名を見てください。ドメイン名は、正規の NTT CPaaS サイトにアクセスしていることを確認するのに役立ちます。

3. ブラウザのアドレスバーでサイトのセキュリティステータスを確認してください。ほとんどのブラウザでは、安全な Webサイトには、WebサイトのURLの左側に緑色の南京錠のアイコンが表示されます。南京錠のアイコンをクリックすると、Webサイトの詳細(使用されている暗号化の種類など)を確認できます。例えば：

   • ドメイン名に複数のダッシュまたは記号が含まれています。
   • 実際のビジネスを模倣したドメイン名(例:「inf0bip」、「infoblp」、「infob1p」)。
   • 「.biz」や「.info」などのドメイン拡張子。これらのサイトは信頼できない傾向があります。
   • 「.com」サイトは、本質的に信頼性が低いわけではありませんが、入手するのが最も簡単なドメイン拡張機能であることにも注意してください。

4. Webサイトの接続タイプを確認してください。NTT CPaaS WebインターフェイスのWebサイトにはhttpsタグがあり、より一般的なhttp指定を使用するサイトよりも安全であるため、信頼性が高くなります。これは、ほとんどの違法なサイトが、一般的なhttpsサイトが行うセキュリティ認証プロセスをわざわざ行わないためです。

5. ファイルパスを見てください。NTT CPaaS Webインターフェイスには、アクセスするWebインターフェイスの部分に応じて、単純なファイルパスがあります。パスに関して疑問がある場合は、Supportにお問い合わせください。

6. URL を評価します。WebサイトのURLは、接続タイプ(「HTTP」または「HTTPS」)、アプリケーション(「ポータル」など)、ドメイン名(「infobip」など)、拡張子(「.com」)、およびファイルパス(「/dashboard」など)で構成されます。接続が安全であることを確認した場合でも、次の危険信号に注意してください。

   • ファビコン – Webサイトは、タブに必要なアイコンを配置できます。
   • ドメイン名 –これはURLの一部であり、探しているものを知っている限り、信頼できます。
   • ファイルパス/ディレクトリ–これはURLの一部であり、探しているものを知っている限り、信頼できます。
   • Webコンテンツ領域 – これは、NTT CPaaSの正規のWebサイトの非常に説得力のあるなりすましなど、攻撃者が望むものなら何でもかまいません。

7. ウェブサイトで片言の英語を探してください。スペルが悪い(または欠落している)単語が多数あること、一般的に文法が悪い、またはぎこちない言い回しに気付いた場合は、サイトの信憑性を疑う必要があります。問題のサイトが詐欺でない限り技術的に合法であるとしても、言語の不正確さもその情報の正確性に疑問を投げかけ、それによって貧弱な情報源になります。

8. 証明書の詳細の確認: ほとんどのブラウザでは、アドレスバーの南京錠アイコンをクリックして証明書を表示できます。

   Firefoxの場合:

   1. 南京錠のアイコンを選択します。
   2. 詳細情報 を選択します。
   3. [証明書の表示] を選択します。

   Safariの場合:

   1. 南京錠のアイコンを選択します。
   2. [証明書の表示] を選択します。

   Chromeの場合:

   1. 3ドットメニュー→その他のツール →開発者ツール を選択します。
   2. [セキュリティ] タブを選択し、[証明書の表示] を選択します。

   又は

   1. 証明書 →南京錠のアイコンを選択します。
   2. 証明書情報 を選択すると、CA が証明書を発行する前に検証したすべての情報が表示されます。

NTT CPaaS 証明書は次のようになります。

機密情報の共有

このセクションは、機密情報を安全に使用および保存する方法に関するクイックガイドです。

Sパスの使い方 [#how-to-use-s-pass-sharing-confidential-information]

S-PASS は、NTT CPaaSの従業員、クライアント、およびその他の第三者と機密情報を共有するためのNTT CPaaSアプリです。共有された情報は一度だけ読み取り可能 であり、その後S-PASSから完全に消去されることに注意してください。

送信者からトークンを受け取った場合は、秘密のメモを作成して受信者に送信する か、秘密のメモにアクセスして読む ことができます。いずれの場合も、任意のWebブラウザを使用してS-PASSにアクセスする必要があります(Webブラウザによって表示が異なる場合があります)。

シークレットを保存する [#store-a-secret-sharing-confidential-information]

1. S-PASSにアクセスします。秘密のメモを書く をクリックして秘密を誰かと共有するか、秘密のメモを読むためのトークンを受け取った場合は 秘密のメモを読む をクリックします。
2. 送信したい秘密のメモ を書いて貼り付けます。秘密のメモを保存する期間を選択します。読み取られるか、選択した保存時間を超えるまで保持されます。完了したら、ストア シークレット をクリックします。

これで秘密のメモが保存されました。** ** トークンをコピーするか、直接リンクをコピーして、Secret stored! ポップアップからシークレットを共有します。

シークレットを読み取る [#read-a-secret-sharing-confidential-information]

直接アクセスリンク がある場合は、それをWebブラウザに貼り付けると、[シークレット]セクションの下に共有シークレットが表示されます。アクセストークン をお持ちの場合は、S-PASSに移動し、秘密のメモを読む をクリックし、トークンを貼り付けて、トークンの送信 をクリックします。

安全なファイル転送

NTT CPaaS Webインターフェイスを使用して、NTT CPaaS からレポートをエクスポートする方法を定義できます。この目的のために有効な方法は、FTP と SFTP です。

FTPは、暗号化されていない基本的なファイル転送機能を提供するファイル転送プロトコルです。匿名アクセスと認証済みセッションの両方が可能ですが、ユーザーの資格情報とデータペイロードはパブリックネットワークを介してクリアテキストで転送されるため、機密データへの不正アクセスや隠されたマルウェアの拡散の高いリスク が発生します。

FTPプロトコルは、より安全な代替手段(SFTP、FTPS、SCP...)に完全に置き換えられているため、非常に信頼でき分離されたシステム** ** 、または匿名FTPによるパブリックアクセスにのみ使用する必要があります。

SFTP (セキュア FTP) を使用することをお勧めします。クライアント側にSFTPサーバーを実装し、NTT CPaaS Webインターフェイスのエクスポート機能またはカスタマーケアに対してアクセスパラメータを提供するだけです。

安全な実装 プロセスは、通常、次のポインターに従います。

1. 非標準ポート (22 以外) を指定します。
2. 着信(送信者)IPアドレスをセーフリストに登録する。NTT CPaaS の場合、これらは193.105.74.4と62.140.31.104になります。
3. 各 クライアント ユーザー専用の資格情報 (つまり、NTT CPaaS 専用の資格情報) を使用します。
4. 長くて複雑なパスワード(12文字以上)を選択します。
5. パスワードは定期的に変更してください(例:3か月ごと)。

セキュリティ上の理由とは別に、暗号化されたデータ転送の使用は、世界中の多くの業界で、企業のセキュリティポリシーに含まれる規制コンプライアンス要件 です。

安全でないバージョンのFTPを選択した場合、関連するセキュリティリスク を受け入れると同時に、NTT CPaaSはそのような使用に起因する可能性のある責任を放棄します。

NTT CPaaSリソースに対してセキュリティ テスト アクティビティを実行する権限付与

NTT CPaaSは、有名な第三者企業と連携し、以下を含むベストプラクティスの方法論を使用して、定期的な外部侵入テストを実施しています。

• OSSTMM (オープンソース セキュリティ テスト手法マニュアル)
• OWASP (Open Web Application Security Project) (オープン Web アプリケーション セキュリティ プロジェクト)
• NIST ペネトレーションテストと監査の方法論(ターゲットシステムのセキュリティを評価するために設計された自動および手動の手法を含む)

NTT CPaaSは、契約したサービスの範囲に限定されたNDAに署名した上で、これらのテスト演習の詳細なレポートをクライアントおよびパートナーに提供します。当社のセキュリティチームは、レポートの内容や脆弱性管理プログラムのその他の側面に関する質問や議論に対応しています。

既存のレポートや文書を使用してサプライチェーンのセキュリティを検証することは、双方の運用上の負担とコストを削減しながら、適切な保証レベルを提供するため、有益です。

これらの議論が十分でない場合は、サービス利用規約および各サービス契約に規定されている規定に従って、環境の侵入テストまたは脆弱性スキャンを手配する場合があります。

クライアント/パートナーは、テスト結果をNTT CPaaSコーポレートセキュリティチームと共有することに同意する必要があります。NTT CPaaSの製品またはサービス内で特に重大かつ/または重大な問題が発見された場合、クライアントは遅滞なく調査結果をNTT CPaaSに報告することに同意するものとします。

すべての外部セキュリティテストアクティビティはアナウンス する必要があり、リクエスト はNTT CPaaSの担当者(アカウント/セールスマネージャーまたはサポート)に送信する必要があります。

そのようなすべての要求は、テストを実施するための現在のクライアント/パートナーの許可に照らして評価されます。要求が承認された場合、要求当事者は、NTT CPaaS Corporate Security 部門から提供される 外部侵入テスト文書 に記載されている、契約に関する定義された一連の要件に準拠する必要があります。

NDAの規定に従い、お客様は、** ** 発見された脆弱性の機密性を保護する責任を負います。そのような情報は、いかなる形式であっても、NTT CPaaS Corporate Security部門の事前の承認なしに、第三者に開示または共有してはなりません。

クライアントがこの機密保持条項に違反した場合、NTT CPaaSは契約条項に基づいてクライアントに責任を負わせ、潜在的な払い戻し請求は、これらの不正な活動から生じる損害の最大額を考慮に入れます。

実施されたペネトレーションテストでNTT CPaaSシステムの脆弱性が発見された場合、これらの調査結果はNTT CPaaSコーポレートセキュリティ部門によってトリアージされます。修正が必要とマークされた場合、特定された脆弱性の修復の証拠は、専任のアプリケーションセキュリティ専門家およびその他の関連するセキュリティ専門家によってまとめられた内部プロビジョニングレポートの形式で、要求する第三者に提供されます。

クライアントの内部プロセス

内部資格情報の保存と管理を強化して、NTT CPaaSプラットフォームへの不正アクセスとトラフィック コストにつながる可能性のある将来の内部データ漏洩の潜在的なリスクを軽減します。

パスワードを安全に保管するには、商用グレードのパスワード管理ツールの使用を検討してください。

資格情報の保存 (操作方法と使用方法)

NTT CPaaS API を使用している場合は、パスワード、トークン、シークレットなどの機密データを処理する必要があります。これは、特にサービス操作を実行するために機密データをあるサービスから別のサービスに送信する必要がある場合、非常に困難な場合があります。

機密データを保存する必要性は正当なユースケースであり、設計段階で何度も発生する可能性があります。リソースを共有して操作を開始する安全な方法に頼ることができない場合は、階層で設定された追加のセキュリティメカニズムを設定し、多層防御を強化する必要があります。

承認がハードコーディングされているシナリオ コードの例を次に示します。

これは、私たちが防ぎたいシナリオです。

これらのセキュリティメカニズムと、機密データを保護する方法をいくつか見てみましょう。

ハードウェア セキュリティ モジュール (HSM) を使用する

ハードウェアセキュリティモジュールは、通常、改ざん防止FIPS 140-2レベル3デバイスとして正式に認定された特別な物理デバイスであり、機密資料を保存および保護し、暗号化操作を安全に実行するように設計されています。HSM の背後にある考え方は、アプリケーションがデプロイされているコンピューターではなく、より安全な環境でデータを格納したり、操作を実行したりすることです。HSM には様々なプロバイダーがあり、その使用方法と運用方法はプロバイダーのドキュメントの範囲内にあります。これは、機密データの処理に使用できる最適なアプローチです。

機密データは絶対に保存しないでください

機密データを保存する代わりに、デプロイ時にアプリケーションに含めます。起動時にアプリケーションがシークレットを要求するようにします。これは、パスワードがメモリにしか含まれていないためHSMを使用できない場合にできる最善のことです。

これに関連するリスクは他にもあります。たとえば、アプリケーションがサービスとしてデプロイされている場合に、メモリから直接パスワード/キーを取得したり、サーバーの再起動などの可用性のリスクが発生したりします。この方法は、他のどの方法よりもはるかに安全です。他のすべての方法には、メモリから機密データを取得することに関連する同じリスクがあります。

これを単純なSpring Bootアプリケーションに組み込む方法の例を次に示します。

機密データを保存するときに追加のレイヤーを設定する

機密データを本当に保存する必要があるイベントでは、追加の防御層を設定します。

ここにはいくつかのオプションがあります。

1. 検証済みの暗号化ストア(キーストアなど)にシークレットを保存し、アプリケーションの起動時にそれらのシークレットをロードします。
2. シークレットを暗号化し、暗号化キーを安全に格納し、サービス上の特定のユーザーのみに制限されるようにします。
3. 環境変数にシークレットを格納し、コードで値をフェッチします。
4. 認証後にアプリケーションにシークレットを提供する別のプロセスまたはサービスを使用します。

以下は、環境変数からシークレットを取得する方法のコード例です。

SMS不正防止のためのセキュリティガイドライン

インターネット上でのサイバー攻撃の大幅な増加に伴い、Webアプリケーションは様々な方法で攻撃されています。これらの攻撃を効果的に防御するために、詐欺事件で利用される最も一般的なWebアプリケーションの問題の観点から実装できるWebアプリケーションセキュリティガイドラインを提供しています。

不正事件で利用されるWebアプリケーションの問題 [#web-application-issues-leveraged-in-fraud-cases-security-guidelines-for-sms-fraud-prevention]

1. 詐欺事件で利用されたWebアプリケーションの問題

   SMSメッセージの頻度と量を特定の数に制限して、ユーザーがサービスやプラットフォームを悪用できないようにします。このアプローチを使用すると、エンド ユーザーへの潜在的なスパムを回避し、エンド ユーザーによってリソースが使い果たされる可能性がなくなります。レート制限は、ユーザーアカウントレベルで実装する必要があります。

2. HTTPヘッダーとCookieのセキュリティメカニズムの欠如

   HTTPヘッダーには、Webアプリケーションに追加のセキュリティレイヤーを提供できる一連のセキュリティメカニズムが含まれている必要があります。アプリケーションCookieには、少なくとも「Secure」および「HttpOnly」ディレクティブが必要です。追加のオプションは、クロスオリジン情報漏洩のリスクを軽減する SameSite を含めることです。 Cookieを保護するだけでなく、アプリケーションはX-Frame-Optionsを使用してクリックジャッキング攻撃を回避し、X-XSS-Protectionを使用してXSS攻撃を軽減し、Strict-Transport-Securityを使用してHTTPSのみを使用するようにブラウザに指示する必要があります。

3. 一部の API エンドポイントで認証またはレート制限がありません

   一部のエンドポイントはデバッグモードまたはテストモードになり、テスト目的で使用されるエンドポイントでは認証またはレート制限が無効になる可能性があるため、すべてのAPIエンドポイントを適切に管理することが重要です。これは、複数のデプロイ (運用、ステージング、内部、および開発) で下位互換性を維持する状況で一般的です。

4. 安全でない直接オブジェクト参照

   アプリケーションは、データベースから特定のオブジェクトにアクセスしようとしたユーザーがそのオブジェクトへの適切なアクセス権を持っているかどうかを確認する必要があります。IDOR は通常、ユーザーが URL 内のオブジェクトの ID を 10 から 20 に変更するなどして入力を変更したときに発生します。ユーザーは、別のユーザーに関連付けられているオブジェクトにアクセスできます。アプリケーションでは、ID などの実際の識別子の公開を防ぎ、シーケンシャル ID は簡単に推測できるため、代わりにハッシュを使用する必要があります。

5. CAPTCHAメカニズムがない、または安全でない

   reCAPTCHAまたはhCAPTCHAを使用してボットに対処します。ボットと人間の相互作用の両方を使用して解決される自動化されたCAPTCHAソルバーの存在に注意してください。グラフィックパズルの解答やコンテキスト固有の質問など、従来とは異なるCAPTCHA手法の使用を検討してください。

6. CSRF対策トークンがありません

   すべての機密性の高いHTTPリクエスト内でアンチCSRFトークンを使用することをお勧めします。CSRFトークンは、セッションごとに生成されるCSRFトークンとは対照的に、エクスプロイトの時間範囲が短いため、HTTPリクエストごとに生成する必要があります。

7. 機密データを API に送信するための GET パラメーターの使用

   URL は HTTP プロキシ、ブラウザーの履歴、または Web サーバーのログにキャッシュされる可能性があるため、機密データや API キーの送信に GET パラメーターを使用することは避けてください。機密データを API に送信するには、HTTP POST メソッドを使用します。

8. Web アプリケーションは、インジェクション ペイロードなどの危険な入力をフィルター処理およびサニタイズしません

   Web アプリケーションの形式で使用できるデータの種類を定義します。入力を検証してエスケープします。たとえば、ユーザー名フィールドでは英数字の文字列のみを受け入れるため、特殊文字を受け入れる必要はなく、電話番号フィールドでは数字のみを使用する必要があります。 HTMLフォームから直接ユーザー入力を使用する代わりに、SQLインジェクションのリスクを最小限に抑えるために、基礎となるデータベースと対話するときに、パラメータ化されたクエリでストアドプロシージャまたはプリペアドステートメントを使用します。XSS は、日付や yes/no 選択などの入力選択がない各フォームで検証と入力サニタイズを使用して対処し、常により小さい (<) やより大きい (>) などの特殊文字をエンコードする必要があります。

9. HTTP 経由の安全でない接続

   HTTPを使用する代わりに、HTTPトラフィックの暗号化を提供し、トラフィックの傍受から保護するため、HTTPSに切り替えます。プレーンなHTTPプロトコルを使用すると、ユーザーが公共のWi-Fiホットスポットまたは安全でないネットワークに接続されている場合、APIキーまたはユーザー資格情報が盗聴される可能性があります。SSL 2.0/3.0 の使用を避け、TLS 1.0 を無効にし、TLS 1.2 と TLS 1.3 を使用します。ヌル暗号と匿名暗号を無効にします。

10. 不十分なログ記録と監視

    Web アプリケーションは、保存時と転送時に適切なレベルの整合性で十分な数のログを生成できる必要があります。また、アプリケーション ログは、プレーンテキストの資格情報やメッセージの内容などの機密情報からサニタイズする必要があります。これは特に、認証や、パスワード/APIキーの登録や変更、アクセスの拒否、入力検証エラーなどの機密性の高いアクションに当てはまります。ログ記録と監視は、将来のフォレンジックとユーザーのアクションの調査の要件です。