メインコンテンツまでスキップ

6. Security Considerations (セキュリティに関する考慮事項)

6. Security Considerations (セキュリティに関する考慮事項)​

HTTP を使用するアプリケーションはセキュリティを慎重に考慮する必要があります。このセクションでは主要なセキュリティに関する考慮事項を強調しています; [HTTP] セクション 17 も参照してください。

アプリケーションはすべての通信に TLS [RFC8446] を使用すべきです (SHOULD)。特に, アプリケーションは認証資格情報や個人データなどの機密情報を送信するときは TLS を使用しなければなりません (MUST)。遍在する暗号化の必要性については [RFC7258] を参照してください。

アプリケーションは TLS が使用されることを保証するために "http" ではなく "https" URI スキームを使用すべきです (SHOULD)。TLS を使用する場合, アプリケーションは次を含む現在のベストプラクティスに従うべきです (SHOULD):

  • TLS 1.3 [RFC8446] 以降を使用する。

  • サーバー証明書を検証する。

  • 適切な暗号スイートを使用する。

  • ブラウザが常に HTTPS を使用することを保証するために HTTP Strict Transport Security (HSTS) [RFC6797] の使用を検討する。

アプリケーションはさまざまな Web ベースの攻撃とそれらを緩和する方法を認識する必要があります:

  • クロスサイトスクリプティング (XSS): アプリケーションがブラウザによって HTML または JavaScript として解釈できるコンテンツを返す場合, XSS 攻撃を防ぐためにそのコンテンツを適切にエスケープまたはサニタイズする必要があります。Content-Type を適切に使用し, Content-Security-Policy [CSP] ヘッダーを設定することが役立ちます。

  • クロスサイトリクエストフォージェリ (CSRF): 状態を維持する (例えば, Cookie を使用する) アプリケーションは CSRF 攻撃から保護する必要があります。悪意のあるサイトがユーザーのブラウザをだましてアプリケーションにリクエストを行わせる攻撃です。一般的な緩和策には CSRF トークンの使用や Origin または Referer ヘッダーフィールドのチェックが含まれます。

  • インジェクション攻撃: ユーザー入力をクエリ, コマンド, またはその他の構造化データに組み込むアプリケーションは, インジェクション攻撃 (例えば, SQL インジェクション) を防ぐためにその入力を適切に検証およびサニタイズする必要があります。

  • 情報開示: アプリケーションはエラーメッセージ, ヘッダーフィールド, およびその他のレスポンスに含める情報について注意する必要があります。詳細なエラーメッセージは攻撃者がアプリケーションの内部を理解するのに役立つ可能性があります。

アプリケーションはキャッシングのセキュリティへの影響を考慮すべきです (SHOULD)。特に:

  • 機密情報はキャッシュすべきではありません。またはキャッシュする必要がある場合は, プライベートにのみキャッシュすべきです (Cache-Control: private を使用)。

  • 認証資格情報は URL に含めるべきではありません。ログに記録されたり, キャッシュされたりする可能性があるためです。

認証を使用するアプリケーションは次のことを考慮する必要があります:

  • 認証資格情報がどのように送信されるか (TLS によって保護されるべきです)。

  • 認証セッションがどのくらい続くか, どのように取り消すことができるか。

  • 認証に対するブルートフォース攻撃からどのように保護するか。

  • 多要素認証が適切かどうか。

アプリケーションはクライアントとサーバーがアプリケーションの設計者の制御下にない可能性があることを認識すべきです (SHOULD)。特に:

  • 中間者 (プロキシ, CDN など) がリクエストとレスポンスをキャッシュ, ログ, または変更する可能性があります。

  • クライアントは悪意を持っているか侵害されている可能性があります。

  • サーバーは侵害されている可能性があります。

したがって, アプリケーションは次のことを行うべきです (SHOULD):

  • 適切な場合にエンドツーエンドの暗号化と認証を使用する。

  • 機密操作のためにトランスポート層のセキュリティのみに依存しない。

  • クライアントからのすべての入力を検証する。

  • 最小権限の原則を認識し, クライアントやサーバーに必要以上のアクセスを与えない。

ユーザーがコンテンツをアップロードしたりコードを実行したりできるアプリケーションは, サンドボックス化と分離について非常に慎重である必要があります。一見無害な機能でも悪用される可能性があります:

  • ファイルのアップロードには, パーサーやビューアの脆弱性を悪用する可能性のある悪意のあるコンテンツが含まれている可能性があります。

  • ユーザー制御の URL は Server-Side Request Forgery (SSRF) 攻撃に使用される可能性があります。

  • ユーザー提供のコードを実行する機能 (例えば, ブラウザコンテキストでの JavaScript) には強力な分離が必要です。

Web ブラウザからアクセス可能なアプリケーションは, ブラウザには多くの潜在的な落とし穴を伴う複雑なセキュリティモデルがあるため, 特に注意する必要があります。アプリケーションは次のことを行うべきです (SHOULD):

  • ブラウザができることを制限するために適切な Content-Security-Policy ヘッダー [CSP] を使用する。

  • クロスオリジンアクセスを制御するために適切な CORS ポリシー [FETCH] を使用する。

  • 適切なフラグ (Secure, HttpOnly, SameSite) を使用して Cookie を設定する。

  • クリックジャッキングを防ぐために X-Frame-Options または CSP の frame-ancestors ディレクティブを使用することを検討する。

  • プリフェッチ, DNS プリフェッチ, プリコネクトなどのブラウザ固有の動作を認識する。

  • 外部でホストされるリソースが改ざんされていないことを保証するために Subresource Integrity (SRI) を使用することを検討する。

アプリケーションは HTTP 機能が悪用される可能性があることを認識すべきです (SHOULD):

  • リダイレクトはフィッシングやセキュリティ制御を迂回するために使用される可能性があります。

  • 大きなリクエストやレスポンスはサービス拒否攻撃に使用される可能性があります。

  • ヘッダーフィールドやコンテンツの複雑な解析は脆弱性につながる可能性があります。

最後に, アプリケーションは明確なセキュリティポリシーを持つべきであり (SHOULD), 最初からセキュリティを考慮して設計されるべきです。セキュリティは後付けであるべきではありません。

に最終更新