「決済は正常なのに、金額が合わない最悪の事故」

決済・料金・ポイントAPI改ざん

「決済システムは正常なのに……なぜ金額が合わないのでしょうか？」

最初に異常を発見したのは精算チームでした。

売上グラフは確実に上昇しているにもかかわらず、実際の入金額が少しずつ不足していました。

最初は、

• カード手数料の問題なのか？
• 決済代行会社の精算遅延なのか？
• 社内会計エラーなのか？

あらゆる可能性を確認しました。

しかし、サーバーログも決済承認記録も「正常」でした。

ところが1か月後、その「小さな差額」は数千万円規模になっていました。

これが決済・料金・ポイントAPI改ざん事故の始まりです。

なぜこの事故は非常に危険なのか

決済関連の事故は多く存在します。

しかし、このタイプが特に危険な理由はひとつです。

サーバーは最後まで「正常なリクエスト」と信じ続けることです。

• 決済承認は正常
• APIレスポンスも正常
• 異常ログも存在しない

そのため、検知が遅れます。

そして攻撃者は、

• 一度に大量には盗まない
• 少額を長期間、静かに取得する

➡ 金銭被害 + 検知難易度最高
そのため、この攻撃は TOP 2 に位置します。

実際に発生したAPI改ざんシナリオ

対象となったライフスタイルアプリは、ポイント決済とアプリ内決済を同時に提供していました。

攻撃の流れは以下でした。

1. ネットワークフッキング

o 改ざんアプリ環境でAPI通信を取得

2. APIパラメータの微細な変更

o 決済金額やポイント減算値を調整

3. 決済承認後の減算処理を改変

o 決済代行側の承認は正常
o 実際のユーザー減算額だけ変更

ユーザー画面には「決済完了」と表示され、サーバーにも「正常承認」の記録が残ります。

しかし、数字だけが少し変更された状態で処理されます。

セキュリティ問題の本質は何だったのか

この事故の本質はサーバーセキュリティではありませんでした。

クライアントを信頼しすぎたことでした。

具体的な問題点

• 改ざんアプリ・フッキング環境からのAPI呼び出しを許可
• クライアントから送られる金額をそのまま信頼
• 正常ユーザーと操作ユーザーを区別できない
• 少額繰り返し攻撃への検知基準が存在しない

つまり、

「正常なAPI呼び出し = 正常ユーザー」という思い込みが最大のセキュリティホールでした。

LIAPPはどのように防御したのか

事故後、このサービスは決済構造を変更する前に、まずアプリ実行環境を再確認しました。

LIAPP – 改ざん・フッキング環境遮断

• ネットワークフッキング・プロキシ利用検知
• アプリ整合性検証（リパッケージ・改ざん防止）
• メモリ操作・APIフッキング検知時の実行遮断
• 自動化・スクリプトによる呼び出し検知
• 不審ユーザー自動遮断

改ざんされた環境では決済API自体を呼び出せない構造へ。

「少額を少しずつ盗む攻撃」を行動データで検知。

アカウントが存在していても、危険な環境では資金を動かせません。

セキュリティ適用後の変化

適用後、

• 決済金額不一致を完全防止
• ポイント悪用事例が大幅減少
• 精算・監査リスクを解消
• 外部監査対応時間を短縮

最も重要な変化は、

「決済はサーバーだけ守ればよい」という考え方が完全に変わったことです。

この事例が示す教訓

決済事故の始まりは、いつも小さな数字です。

• 100ウォン
• 200ウォン
• 500ウォン

しかし放置すれば、その数字は企業の信頼とサービス継続性を脅かします。

決済セキュリティの本質は金額ではありません。

「リクエストの信頼性」です。

その信頼は、

• アプリが正常なのか
• 環境が安全なのか
• 人間が直接利用しているのか

を同時に確認しなければ守れません。

決済APIはサーバーではなく、アプリから守る必要があります。

#ライフスタイルアプリ #決済セキュリティ #API改ざん #ポイント悪用 #アプリ内決済 #金融事故 #モバイルセキュリティ #アプリセキュリティ #精算リスク #監査対応 #セキュリティ事故事例 #フッキング攻撃 #LIAPP #LISS #LIKEY