私はこの銀行のクライアントであるため、顧客データの安全な保管に十分な注意を払っているかどうか疑問に思っていました。 私はウクライナ支社のクライアントであるため、ウクライナのお客様向けのモバイルアプリケーションの部分のみを確認する機会があったことを明確にします。
準備する
モバイルアプリケーションからサーバーに送信されたトラフィックを追跡するには、 Fiddlerをインストールします。
このプログラムは非常に使いやすく、指示に従って簡単にインストールおよび構成できます。 さらに、プログラム設定で、 httpsトラフィックの復号化を有効にする必要があります
電話のwi-fi設定で、このアプリケーションによって解除されたプロキシアドレスを指定する必要があり、プログラムがモバイルHTTPSトラフィックを復号化できるようにするには、証明書（ IOS 、 Android ）を追加インストールする必要があります。
これらすべてのステップの後、FiddlerとAlfa-Bankモバイルアプリケーションを起動します。 これで、携帯電話から送信されたすべてのリクエストがFiddlerに表示されます。 私たちの場合、それはXMLリクエストを伴うSOAPプロトコルであることが判明しました。
脆弱性検索プロセスについて少し説明します
開発者による典型的な間違いを探していました。 これらの最も一般的なのは、識別子を使用して要求するときのアクセス制御の欠如です。 次のようにエラーを検索します。 Fiddlerによってライセンスされたモバイルアプリケーションのリクエストを受け取り、「Postman」プラグインを使用してGoogle Chromeブラウザーで再生します。
このリクエストでは、整数識別子をより大きな値またはより小さな値に置き換え、サーバーの応答を確認します。 サーバーがエラーまたは空のリクエストを返した場合、すべてが正常であり、クライアントデータがあれば、脆弱性があります。 長く探す必要はありませんでした。 ステートメントを要求する際、アクセス権の確認はありませんでした。 cardContractIdなどの識別子がデータへのアクセスに使用されました。 その値を増減することにより、他のユーザーからステートメントを受け取ることができました。
同じ日に、Alfa-Bankウェブサイトで見つかった脆弱性に関するメッセージを送信しましたが、数日以内に応答を受け取らず、カスタマーサービスに電話してセキュリティサービスに連絡するように依頼しました。 私は敬意を払わなければなりません、SBの役員は同じ日に私に電話をかけ、1週間以上たってからこの脆弱性は取り除かれました。
ただし、ソフトウェア製品の開発を担当する銀行の部門の経営者に話を戻したいと思います。 銀行サービスは、必要に応じて脆弱性が現れる機能を積極的に開発し、獲得しています。 電子形式でリクエストを送信する場合、既存の通信チャネルは実際には応答しません。 たとえば、数か月前に提出された、Alfa-Bankの他のリソースのXSS脆弱性に関する私のレポートのうち2つは未回答のままでした。
見つかった脆弱性を申請するための個別のコミュニケーションチャネルを編成し、インセンティブプログラムを作成します。 このようなプログラムは、Google、Amazon、Yandex、Privatbankにも存在し、セキュリティホールを迅速に塞ぐのに非常に効果的に役立ちます。 攻撃者が発見された脆弱性を悪用し始めると、顧客はすでに実際に問題についてあなたに通知するまで待たないでください。