過剰な「カーディング」試行への対処
現在、eコマースプラットフォームのLAMPスタックでMagentoを使用して設定されています。 1〜2か月前の時点で、私たちはWebサイトに対する多くのカーディングの試みに気づき始めました。クレジットカードが有効かどうかを確認するためだけに、すべての取引は少量で行われます。却下されると、彼らは通常、カード番号を1または2の番号で繰り返し変更して、もう一度試みます。これらの試みは非常に速く、続けて起こります。ご想像のとおり、これは当社のクレジットカードプロセッサシステムで急速に増加し、多くの場合、それ以上の試行を防ぐために短時間シャットダウンされます。
攻撃のほとんどは米国外から行われており、私たちは米国のみのビジネスであるため、国外からのすべてのトラフィックを拒否するためにmod_geoipを使用しました。これは大規模な攻撃に役立ちましたが、米国発のカードを利用する人もいます。ここで何が起こっているのかを知りたいと思っています。このような大量注文の注文にスクリプトをどのように設定しますか？これを踏みにじるために何か他にできることはありますか？これらのタイプの攻撃に関する洞察は大歓迎です！
この質問は今週のITセキュリティの質問でした。
詳細については、2012年9月14日ブログエントリをお読みください。または自分で送信今週の質問。
名前/住所などの強力な検証がある場合、サイトがさまざまなタイプのエラーに対してさまざまな値を返すことがわかっている可能性が高いです。カードのテストを阻止するためにできる最善のことは、プロセッサが拒否したと言った理由に関係なく、拒否されたトランザクションが同じ結果を提供するようにすることです。
" [〜＃〜] captcha [〜＃〜] "メカニズムを使用して、ブルートフォース攻撃を制限できます。製品によっては、試行が失敗した後にユーザーが別のトランザクションを送信するのをブロックするようにCAPTCHAを構成することができます。または、トランザクション間に時間制限（15〜20秒など）を導入します。
可能であれば、ユーザーに対して認証メカニズムを試して、特定のアカウントのみがトランザクションを実行できるようにすることもできます。
攻撃者が連続したアカウント番号を使用している場合、それは試みをフィルタリングするために使用できるプレゼントです。誰かが001、次に002、003を試行した場合、それらがカーディングしていることはかなり良い推測であり、そのIPアドレスからの試行をフィルタリングできます。
賢い攻撃者は、カード番号をランダム化することで攻撃を修正するか、数字のブロックをランダム化する可能性が高いため、他の兆候を探す必要があります。 IPアドレスとリクエストのDBを構築する場合、多数の小さな値のトランザクションのようなこれらの兆候を探すか、アルゴリズムを使用してブロックトランザクションの試行を検出できます。
またはもちろん、カーダーは適応できます。試行のために複数のサーバーの使用を開始したり、より大きなトランザクションを試行したり、1時間あたりの試行回数を減らしたりすることができます。ただし、システムはhave彼らはそうすることができないか、気にしたくないかもしれません。少なくとも彼らはそれのために働かなければならないでしょう。
この人（人）が有効な番号を取得するかどうかは気にしないと思います。あなたが言っているように、住所でも検証を行っており、彼らは順番に試行しているからです。 CCプロセッサによってブロックされることは実際には目標である可能性があります特に競合相手である場合、またはlulzのために実行している場合は特にそうです。
リストに追加できるオプションは2つあります。入力フィールドの名前をランダム化し、フィールドの名前をセッションまたは安全な場所に保存できます。PHPを使用している場合は、次のようにします。
<input type = "text" name = "ccnum" />
に：
<input type = "text" name = "<?php echo $ccFieldName; ?>" />
また、ユーザーにJavaScriptを有効にするように強制することもできます（ユーザーの約96％がJSを有効にしています）。不正使用者がwgetなどのコマンドラインツールを使用してサーバーにアクセスしようとしている可能性があります。その場合、JSを解析できません。 Javascriptを有効にしたら、ドキュメントの準備ができたら、クレジットカードの入力フィールドを上記のようなランダムな名前で追加して、自動化リクエストの現在のすべての試行が失敗するようにすることができます。
私が知っている組織でこれが起こっていたとき、彼らは彼らのプロセッサに、特定のしきい値を下回るすべての請求額を拒否するように言いました。これにより、価値の低い取引が完全に停止し、カード会社はすぐにサイトをそのままにしました。
まだ何もしていない場合は、最寄りのFBI事務所に連絡することを検討してください。彼らはその事件に興味があるかもしれない。アカウントの「試飲」プロセスは、おそらく追跡可能などこかから来ています。
検討すべき1つのオプションは、クレジットカードチェックプロセスに人為的な遅延を導入することです。正当なユーザーはプロセスのわずかな遅延を気にする必要はありませんが、カーディングスクリプトに対するサイトの有用性を大幅に阻害するはずです。
疑わしい要求のストリームを特定したら（おそらく、最近失敗したトランザクションでのリアルタイムパターンマッチによって）。まず、一定期間（少なくとも数時間）一致する後続のすべての要求を自動的に拒否します。これにより、実際のトランザクション処理システムの負荷が取り除かれ、犯人に役立つ情報がまったく提供されなくなります。実際には、有効な要求も拒否されるため、誤った情報が提供されます。応答を遅くして、新しいリクエストのレートを制限します。
ここでも同じ問題がありました。私たちは、最も速くて使いやすい方法は、最新のRecaptcha（「私はロボットではない」）拡張機能を実装することだと判断しました。 Yireo Google Recaptcha拡張機能は、実装が高速で簡単だった（ https://www.yireo.com/software/magento-extensions/recaptcha ）ため、この方法を選択しましたが、独自の拡張機能を実装することもできます。ここ（ http://www.proxiblue.com.au/blog/magento-recaptcha/ ）。
Yireoの実装では、「顧客登録」と「1ページのチェックアウト請求」の設定を「はい」として使用し、その他の設定はすべて「いいえ」に設定しました。 「One Page Checkout Login」設定を「Yes」として使用したときにYireoで気づいた問題があり、登録ユーザーがアカウントへのログインに問題を抱えていました（何らかの理由でrecapchaが表示されず、試行したときにログインすると、メッセージブロックに「無効な再キャプチャ」と表示されます）。そこで、私はその設定を「いいえ」に変更しました。これで通常のユーザーがログインできるようになり、カーディングも支払い処理業者へのpingを停止しました。みんな幸せです。
Yireo拡張機能に関するメモ。短いPHPタグ（ダム））を使用しているため、PHP 5.4未満のバージョンを使用している場合、ショートタグのサポートをオンにする必要があります。 PHP.ini。実装する前に、必ずYireo拡張機能の要件をお読みください。
編集：Recaptchaは攻撃を防ぐために何もしません。 reaptchaは最初の試行の後にキャッシュされたCookieを使用するだけなので、システムをだますのは明らかに非常に簡単です。そのため、ボットはその後、Cookieを使用するだけで実行できます。貧弱なデザインのGoogle。 Recaptchaはボットを防ぐことになっていますが、現在の状態にすることはできません。