カード会員データの SQL データベース/ファイル システムなどのシステムをスキャンするために利用できる (オープン ソース) ツールはどれですか? これまでのところ、PANBuster、7sec、および PANscan を発見しましたが、他にもあるのではないかと考えています (できればオープン ソース)。

次の問題により、今四半期は PCI-DSS 準拠を満たすことが困難です。

ブラウザに次のように入力すると...

...応答し、その結果、確認できない何らかの理由で、ブラウザのアドレス バーの URL が次のように変更されます。

元の URL でエスケープされた文字の一部が、エスケープされていない文字に置き換えられていることがわかります。

その理由は、FireFox は、サーバーがどのように応答したとしても、サーバーが応答したときに、アドレス バーの URL を読みやすくするために自動的に再フォーマットするためです。私はそれについて私ができることは何もないと彼らに言いました。ただし、公平を期すために、次の URL を試してみると...

...Google サーバーが応答しても、ブラウザは URL を変更せず、同じままです。

そして、彼らにはポイントがあります。

一体何が起こっているのでしょうか？問題を絞り込みました。空のテキスト ファイルを要求するだけで、その後に意味のないクエリを追加すると...

...見よ、ローカルサーバーが応答すると書き換えられる：

http://localhost/http.mygarble.com/hello.txt?displayname=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22

私はこれを Fiddler で実行しましたが、不都合なことは何も見られず、書き換えエンジンをオフにしました。私はApacheを実行しています。

さらに混乱を招くのは、ブラウザによって応答が異なることです。タイピング...

...Chrome への変換:

http://localhost/http.mygarble.com/hello.txt?displayname=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22

IE では、URL はまったく同じままです。Opera では、アドレス バーをクリックしない限り、クエリ文字列は削除されます。これは、ブラウザーが応答時にアドレス バーの URL を読みやすくするために自動的に変更するという私の信念を裏付けるものです。Safari は、IE と同様に、URL だけを残します。

手がかりを得るために、Google の応答を確認します。応答時に URL に干渉しないようにブラウザに指示する HTTP ディレクティブはありますか。

どんな助けでも非常に感謝しています！

敬具、

ジェームズ

PCI DSSに準拠することで、開発者はPCのローカル管理者権限を持つことができますか？

ECサイトを運営しているのですが、サイトから決済処理をしたいです。つまり、ユーザーは私のサイトの支払いページでクレジット カードの詳細を入力します。

要するに、ユーザーは支払い処理のために支払いゲートウェイにリダイレクトされるべきではありません。

MasterCard MIGS を使用しています

どんな助けでも大歓迎です。ありがとうございました

バックグラウンド

この点を部分的にカバーしているスタックオーバーフローに関するいくつかの投稿を見てきましたが、包括的な質問/回答を提供する投稿をまだ見つけていません。

POS システムの開発者として、PCI DSS には私が興味を持っている 2 つのコンポーネントがあります。

• 私が開発したソフトウェアに関するPA DSS (Payment Application)
• ソフトウェアを使用するすべてのクライアントに関する PCI DSS (加盟店)

PA DSS は、最も率直に次のように指摘しているようです。

「9.1 支払いアプリケーションは、データベース サーバーと Web サーバーが同じサーバー上にある必要がないように、またデータベース サーバーが Web サーバーとの DMZ にある必要がないように開発する必要があります」

テスト手順:

9.1.a ペイメント アプリケーションがカード会員データを内部ネットワークに保存し、DMZ には決して保存しないことを確認するには、ペイメント アプリケーションが DMZ でのデータ ストレージを必要とせず、DMZ を使用してインターネットをカード会員データを保存するシステム (たとえば、支払いアプリケーションでは、データベース サーバーと Web サーバーが同じサーバー上にあること、または Web サーバーと一緒に DMZ にあることを要求してはなりません)。

9.1.b 顧客がインターネットに接続されたサーバーにカード所有者データを保存できる場合は、ベンダーが作成した PA-DSS 実装ガイドを調べて、顧客と再販業者/インテグレーターが、インターネットにアクセス可能なシステム (Web サーバーなど) にカード所有者データを保存しないように指示されていることを確認します。およびデータベース サーバーは同じサーバー上にある必要はありません)。

そして加盟店の PCI DSS から:

1.3.5 カード会員データ環境からインターネットへのアウトバウンド トラフィックを制限して、アウトバウンド トラフィックが DMZ 内の IP アドレスにのみアクセスできるようにします。

質問

私の質問は非常に単純です。データベースとアプリケーション サーバーは論理的に異なる (仮想化された OS が異なる) か、物理的に異なる (物理/専用サーバーが異なる) 必要がありますか?

また、インターネットにまったく接続されていないデータベース サーバーを配置する必要があることも少し心配です。このサーバーをリモートで管理するにはどうすればよいですか? それとも、アプリケーション サーバー経由でデータベース サーバーにアクセスしても問題ないでしょうか。

PCI DSS2 ドキュメントから: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

3.4.1.b 暗号化キーが安全に保管されていることを確認します (たとえば、強力なアクセス制御で適切に保護されたリムーバブル メディアに保管されているなど)。

私たちは、クレジット カード データを 24 時間ごとに処理するバッチ処理フルフィルメント ハウスを使用しています。これにより、停電などが発生した場合、最悪の場合でも 1 週間、顧客のクレジット カード データを保存する必要があります。

この間、保存された CC 情報は可能な限り安全に保存されます。バッチ プロセスを実行するために毎晩接続されているサム ドライブにキーが保存され、データが暗号化されて保存されるセットアップを見てきましたが、これはバッチ プロセスを処理するための信じられないほど薄っぺらで手動の方法です。確かに、キーを保存するためのより良い方法がありますが、マシンにアクセスしたり、マシンにインストールされているソフトウェアを悪用したりするハッカーからキーを保護します。

この手動プロセスなしで鍵を保管する最良の方法は何ですか?

単一の「ホストされた」支払いエントリ Web アプリケーションの下で、さまざまな Web アプリケーションすべてのすべての支払いエントリを「統合」しようとしています。セキュリティを損なうことなく、さまざまな Web アプリケーションで可能な限り「柔軟」にするために、同じ第 2 レベル ドメイン上の Web アプリケーションから支払い入力/処理画面を iFrame する標準の web2.0 ウィジェットを作成することを考えました。 、しかし異なる第 3 レベル ドメイン。

IE: これらの「別個の」Web アプリケーション:

• https://www.company.com/gifts/store
• https://www.company.com/cars/store
• https://www.company.com/hotels/store

https://payments.company.com/payment-entry.phpの「ライトボックス」メタファー コンテンツの「チェックアウト」の時点で、すべて iframe になります。

[https://payments.company.com] は完全に別のサーバー上にあり、CC データに公開される唯一の Web アプリケーションであるため、PCI コンプライアンスの対象となります。目標は、CC データを参照する内部および外部アプリケーションを可能な限り排除することです。

ワイルドカード証明書を持っている場合、この iframe と同じ第 3 レベル ドメイン ソリューションでセキュリティやクロスサイト スクリプティングの問題が発生することはありますか?

ModSecurity（mod_security）の追加ルールを探しています。GotRootまたはTrustWaveの新しいオプションの2つの商用オプションがあります。

http://www.gotroot.com/mod_security+rules

https://www.trustwave.com/modsecurity-rules-support.php

TrustWaveについては聞いたことがありますが、GotRootについては聞いていません。ただし、GotRootルールはGoogleなどでより多く言及されているようです-TrustWaveのルールは約1か月ほど前にしか登場しなかったようです

eコマースサイトを保護するためにそれらを使用します

PCI に準拠する必要がある e コマース サイトがあります。私が抱えている問題は、XSS 攻撃で失敗することです。

.htaccess で悪意のあるスクリプト タグを取り除き、ユーザーを別のページにリダイレクトする方法はありますか? それとも、間違った木を吠えていますか?