OWASP トップ 10 脆弱性分析 (2) - A2: 暗号化障害暗号化メカニズムの障害

著者：gentle_zhou

元のリンク: OWASP トップ 10 脆弱性分析 (2) - A2: 暗号化の失敗暗号化メカニズムの失敗 - クラウドコミュニティ - Huawei Cloud

Web アプリケーションのセキュリティは常に重要なテーマであり、ネットワークユーザーのプライバシーと財産に関係するだけでなく、プログラムにおけるユーザーの新しいエクスペリエンスにも関係します。Web アプリケーションの機能と複雑さが増し続けるにつれて、これらのプログラムは増加するセキュリティ上の脅威や課題に直面しています。

これらのアプリケーションの開発チームとセキュリティ担当者がこれらの脅威を理解して防止し、セキュリティ意識を高め、より安全なコードを作成できるようにするために、OWASP (Open Web Application Security Project、Open Web Application Security Project) と呼ばれる標準ガイドをリリースしました。 OWASPトップ10。

これは、Web アプリケーションのセキュリティリスクに関する標準的なガイドであり、世界中のセキュリティ専門家とデータプロバイダーの合意に基づいて、現在最も深刻かつ重大な 10 の Web アプリケーションセキュリティリスクをリストし、対応する予防策と推奨事項を提供します。OWASP Top10 は数年ごとに更新されます (これまでに 2004、2007、2010、2013、2017、2021 の 6 つのバージョンがリリースされています)。最新バージョンは 2021 年にリリースされた OWASP Top10 です。:2021

解決されたOWASPの脆弱性

OWASP トップ 10 の脆弱性の分析 (1) - A1: 壊れたアクセスコントロールアクセスコントロールの失敗: OWASP トップ 10 の脆弱性の分析 (1) - A1: 壊れたアクセスコントロールアクセスコントロールの失敗 - クラウドコミュニティ - Huawei Cloud

「暗号化メカニズムの障害」不具合の詳細

今日は、2 番目の欠陥である暗号化の失敗について説明します。これは、2017 年版の 3 位から現在 2 位に順位を上げています。

画像.png

以前のバージョンでは、このタイプの欠陥は「機密データの漏洩」と呼ばれていましたが、これは欠陥の根本原因というよりは症状/結果のように聞こえます。新しいバージョンでは、暗号化関連の障害 (または暗号化メカニズムの欠如) に重点が置かれており、そのような障害は機密データの漏洩につながることがよくあります。典型的な CWE 脆弱性には、CWE-259: ハードコードされたパスワードの使用、CWE-327: 壊れた、または危険な暗号アルゴリズムの使用、および CWE-331: エントロピー (各メッセージに含まれる情報) 量が不十分です。

このような欠陥に対して、ユーザーはまず、送信を含む一連のプロセスにおけるデータの保護ニーズを判断する必要があります。たとえば、ここでいうデータとは、追加の保護が必要なパスワード、クレジットカード番号、健康記録、個人情報、企業秘密、など、簡単に言うと、EU の GDPR などのプライバシー法や金融業界に関連するデータ保護 (PCI データセキュリティ標準など) によって保護されるデータです。

一般的なタイプの暗号化メカニズム障害の欠陥

データの場合、暗号化メカニズムの障害に欠陥があるかどうかは、次の観点から検討できます。

データは HTTP、SMTP、FTP、その他のプロトコルを含むクリアテキストで送信されますか? インターネット上でデータを平文で送信することは危険です。ロードバランサー、Web サーバー、バックエンドシステムの間など、すべての内部トラフィックを検証する必要があります。
古いまたは弱い暗号化アルゴリズムまたはプロトコルがデフォルトで使用されているか、または以前に作成されたコードで使用されていますか?
デフォルトの暗号化キーが使用されているか、弱い暗号化キーが生成または再利用されているか、適切なキー管理またはローテーションが欠落していないか? 暗号化キーをソースコードリポジトリに書き込みましたか?
暗号化への取り組みは実施されていないのでしょうか? たとえば、HTTP ヘッダーからセキュリティ関連のディレクティブやヘッダー情報が欠落しているブラウザはありますか?
受信したサーバー証明書と信頼チェーンは信頼できるものとして適切に検証されていますか?
初期化ベクトルが無視されているか、再利用されているか、または暗号化操作のための十分に安全な初期化ベクトルが生成されていませんか? ECB などの安全でない動作モードが使用されていますか? 認証なしの暗号化は、認証された暗号化の方が適切なシナリオで使用されていますか?
パスワードは、暗号化基盤のないキー導出関数内で暗号キーとして使用されていますか?
暗号化要件を満たすために、暗号化に準拠していない乱数が使用されていますか? 正しい関数が選択されている場合でも、開発者はシード情報を設定する必要がありますか?そうでない場合、開発者は十分な検証/予測不可能性を欠き、元の組み込みの強力なシード関数をオーバーライドするシード置換を使用していませんか?
MD5 や SHA1 などの非推奨のハッシュ関数が使用されていますか? それとも、暗号化ハッシュ関数が必要な場合に非暗号化ハッシュ関数が使用されていますか?
PKCS 番号 1 v1.5 など、非推奨の暗号パディング方式が使用されていますか?

この不具合の発生を防ぐ方法

少なくとも次のことを行う必要があります。

APP アプリケーションを使用して、データが処理、保存、送信されたかどうかを分類します。プライバシー法、規制要件、またはビジネスニーズに基づいて、どのデータが機密であるかを判断します
機密データを不必要に保存しないでください。重要でないデータは、PCI DSS 準拠の標準を使用してできるだけ早く破棄するか、トークン化するか、さらには切り詰める必要があります。保持されていないデータは盗まれないことを明確にする必要があります
すべての機密データが暗号化されていることを確認する
最新かつ最強の標準アルゴリズム、プロトコル、キーが必要に応じて使用されていることを確認し、適切なキー管理メカニズムを使用します。
転送中のすべてのデータを、安全なプロトコル (TLS など)、Forward Secrecy (FS) による暗号、サーバー優先暗号、およびセキュリティパラメーターを使用して暗号化します。HTTP Strict Transport Security (HSTS) などのディレクティブを使用して暗号化を強制する
機密データを含む応答のキャッシュを無効にする
データ分類に基づいて必要なセキュリティ制御を適用する
機密データの転送に従来のプロトコル (FTP、SMTP など) を使用しないでください。
Argon2、scrypt、bcrypt、PBKDF2 などのパスワードを保存するには、作業係数 (レイテンシ係数) を備えた、適応性の高いソルト付きハッシュ関数を使用します。
初期化ベクトルは、動作モードに基づいて適切に選択する必要があります。多くのモードでは、これは CSPRNG (暗号的に安全な擬似乱数生成器) を使用することを意味します。nonce を必要とするモードの場合、初期化ベクトル (IV) は CSPRNG を必要としません。どのような場合でも、固定キーの場合、IV は再利用しないでください。
暗号化だけでなく常に認証暗号化を使用する
秘密キーは暗号的にランダムな方法で生成され、バイト配列としてメモリに保存される必要があります。パスワードを使用する場合は、適切なパスワードベースのキー導出関数を介してパスワードをキーに変換する必要があります。
適切な場合は暗号のランダム性を使用し、予測可能な方法または低エントロピーでシード設定を使用しないようにしてください。最新の API のほとんどでは、開発者がセキュリティのために CSPRNG をシードする必要はありません。
MD5、SHA1、PKCS 番号 1 v1.5 などの非推奨の暗号化関数やパディングスキームの使用は避けてください。
構成と設定の有効性を独立して検証します。

栗をあげる

シーン1

アプリケーションは自動データベース暗号化を使用して、データベース内のクレジットカード番号を暗号化します。ただし、このデータが取得されると自動的に復号化されるため、SQL インジェクションの脆弱性によりクリアテキストのクレジットカード番号が悪用される可能性があります。

シーン2

Web サイトがすべてのページで TLS を使用または強制していないか、弱い暗号化を使用しています。
攻撃者は、ネットワークトラフィック (セキュリティで保護されていないワイヤレスネットワークなど) を監視し、接続を HTTPS から HTTP にダウングレードし、リクエストを傍受し、ユーザーのセッション Cookie を盗む可能性があります。その後、攻撃者はこの Cookie を再利用してユーザーの (認証された) セッションをハイジャックし、ユーザーの個人データにアクセスしたり、個人データを変更したりする可能性があります。上記に加えて、攻撃者は、転送されたすべてのデータ (転送の受取人など) を変更することもできます。

シーン3

パスワードデータベースは、ソルトなしのハッシュまたは単純なハッシュを使用して全員のパスワードを保存します。
ファイルのアップロードプロセスの脆弱性により、攻撃者がパスワードデータベースを取得できる可能性があります。すべてのソルトされていないハッシュは、事前計算されたハッシュのレインボーテーブルを介して公開できます。単純なハッシュ関数または高速なハッシュ関数によって生成されたハッシュは、ソルト処理されている場合でも GPU によって解読される可能性があります。

参考リンク

1、https://owasp.org/Top10/A02_2021-Cryptographic_Failures/

Huawei Cloud CodeArts Checkコード検査サービスを体験してください: Code Check CodeArts Check_Precise Positioning_Code Defects_Security Check_HUAWEI Cloud