789 測定値

コードスメル 282 - 不適切なデフォルトとその修正方法

に Maximiliano Contieri4m2024/12/02

長すぎる; 読むには

不明な応答は有効なものとしてではなく、不正なものとして扱います。

featured image - コードスメル 282 - 不適切なデフォルトとその修正方法

デフォルトはあなたを沈没させる

TL;DR: 不明な応答は有効なものとしてではなく、不正なものとして扱います。

問題点

セキュリティリスク
未知のケースを無視する
エラー誤解
有効な状態をデフォルトにする
不一致の承認
イベントのログに失敗
悪用される可能性

ソリューション

すべての応答を既知のコードのクローズドセットに対して検証します。
デフォルト（および不明）を無許可にするか、デフォルトを削除します。
分析のために、不一致または予期しないケースをすべて記録します。
エッジシナリオでテストします。
コードが古くなるのを避けるために、応答プールをプロセッサと定期的に同期します。
セキュリティに重点を置き、シフトレフトのプロセスにします。
変化するシナリオに対応できるよう、変更耐性を備えたシステムを設計します。

コンテクスト

今日はコンピュータセキュリティの日であり、すべてのプログラマーは自分の責任を認識する必要があります。

トランザクションを処理するためにクレジットカードプロセッサからの応答プールに依存する販売を処理するアプリケーションを想像してください。

各クレジットカードプロセッサは、残高不足やカードの有効期限切れなど、さまざまな状況に対して事前定義された応答コードを提供します。

この問題は、プロセッサが拒否されたトランザクションに対して新しい応答コードを追加したが、プラットフォームに通知しなかった場合に発生します。

アプリケーションは新しいコードを認識せず、デフォルトで「見つからない」として扱い、購入を承認します。

ユーザーはこの欠陥に気づき、それを悪用して不正な購入を行います。

プラットフォームの収益が急落し、破産に至った。

サンプルコード

間違っている

String response = paymentProcessor.authorize(cardDetails); switch (response) { case "DECLINED_INSUFFICIENT_FUNDS": // Handle insufficient funds break; case "DECLINED_EXPIRED_CARD": // Handle expired card break; default: // Authorize purchase break; }

右

String response = paymentProcessor.authorize(cardDetails); switch (response) { case "APPROVED": // Authorize purchase break; case "DECLINED_INSUFFICIENT_FUNDS": // Handle insufficient funds break; case "DECLINED_EXPIRED_CARD": // Handle expired card break; case "DECLINED_NEW_REASON": // Handle new declined reason break; default: // Reject purchase (default case for unknown responses) break; }