問題タブ [pci-dss]

私は j2ee Web アプリケーションに取り組んでおり、次の要件があります。任意のクラスでアプリケーション パッチをインストールすることは不可能であるべきです。現在、パッチは、サーバーのクラスパスまたはアプリケーション EAR に、修正を含む jar ファイルまたは個別のクラスを手動で追加することによって行われます。後でクラスを上書きすることは不可能であるため、署名済みの jar も使用できません。これらの要件に対する解決策を提案できますか?
明確化: 要件は PCI PA-DSS 標準に由来します。
現在のパッチ適用手順は次のように機能します。たとえば、jar の 1 つがシステム クラスパスからロードされます。標準のパッチ手順中に、追加の jar が元の jar の前にクラスパスに追加されます。その結果、両方の jar に存在するすべてのクラスが新しいものからロードされます。これは、結果的にクラスが jar で検索されるためです。要件によれば、アプリケーションは、ロードされたすべてのクラスが信頼できるソースからのものであることを検証する必要がありますが、現在、少なくとも理論的には、ハッカーがアプリケーション クラスを上書きしてバックドアを開くなどの可能性があります。

重複の可能性:

1. PHP を使用してクレジット カード情報を取得および保存するためのベスト プラクティス
2. クレジットカードの詳細を保存する
3. クレジットカード情報の保存

e コマース サイト内にクレジット カード番号を保存する必要があります。クレジット カード番号全体を保存するつもりはありません。非常に危険だからです。カードを発行した金融機関を後で特定できるように、少なくとも最初の 5 桁を保存したいと考えています。理想的には、将来の相互参照などを支援するために、安全にできる限り多くのクレジット番号を保存したいと考えています.

何桁、どの桁を安全に保存できますか?

たとえば、これは十分に安全ではないと思います。

欠けている桁を計算できるからです。

同様に、これは安全ですが、それほど有用ではありません:

部分的なクレジット番号を保存するための広く受け入れられているパターンはありますか?

PCI DSSセキュリティ標準に準拠するキー管理スキームを実装するスキームの実践的な経験またはリファレンスを持っている人はいますか？

PCI DSSに準拠している企業の数を考えると、明らかにかなりの数の実装がありますが、それらの詳細を見つけるのは困難です。プライベートデータの保存に取り掛かると、通常、どの暗号化アルゴリズムを使用するかについての議論は停止します。その後、通常、秘密鍵を適切に保存することについての声明がありますが、それを行うための実際的な方法や、定期的に鍵を変更したり、アプリケーションに鍵を提供したりすることなどについての議論はありません。

特に、PCIDSS規格のセクション3.5および3.6の要件に関心があります。

3.5.2暗号化キーを可能な限り少ない場所とフォームに安全に保管します。

3.6.aカード会員データの暗号化に使用されるキーのキー管理手順の存在を確認します。注：キー管理に関する多数の業界標準は、 http：//csrc.nist.govにあるNISTを含むさまざまなリソースから入手できます。

3.6.4少なくとも年に一度、定期的な鍵の変更を要求するように鍵管理手順が実装されていることを確認します。

PCI DSS要件ドキュメントが示唆しているように、 NIST暗号化の出版物を見てきましたが、暗号化キー管理ワークショップの最近のメモを除けば、実際に実装可能なスキームや標準の点でそれほど多くはないようです。

私がやろうとしていることに関しては、そうではありません：

1. パスワードとソルトを認証用の一方向ハッシュとして保存し、
2. データ暗号化に強力なシンメティックアルゴリズムを選択し、
3. そもそも個人データを保存する必要はありません。
4. 物理的セキュリティ、データベースセキュリティ、ドラゴン、ウィザードなど、他のメカニズムによるキー管理の必要性を回避します。

これらはすべて有効な懸念事項ですが、この場合は答えではありません。私の要件の要点は、ユーザーごとの機密データを保存および取得するための別のSO質問.Netデザインパターンにありますが、それはすべてキー管理に帰着するため、このより洗練された質問です。

単一の実行可能ファイルで、ソフトウェア パッケージの更新パッチを公開します。ファイルは、当社に発行された証明書を使用して、Authenticode デジタル署名で署名されています。このファイルは、お客様が操作する Windows XP または Vista システムにダウンロードされ、そこで実行されてソフトウェアを更新します。

当社の PCI コンプライアンス監査人は、次の状況から保護するように当社に依頼しました。

1. 実行可能ファイルをダウンロードした後、悪意のある人物がファイルを改ざんします。観察力のある人は、ファイルのプロパティをチェックして、署名が無効になっていることを判断できます。
2. 悪意のある人物は、疑いを持たないユーザーが実行できる場所に、変更された実行可能ファイルを配置します。
3. 疑いを持たないユーザーが変更されたファイルを実行し、不特定の混乱を引き起こします。

監査人は、署名が有効でない場合にファイルがまったく実行されないようにする方法がある (またはそうあるべきである) と主張しています。

これがどのように達成できるか知っていますか？

当社のアプリケーションは認定されており、認定されたPABP準拠アプリケーションのリストに含まれています。最新のPABP1.4で認定されました。今、PA-DSSはブロックの新しい子供です。それはPABP1.4からPA-DSSへの自動アップグレードですか、それとも再監査する必要がありますか？

だから私はクレジットカードを保存するために PHP / MySQL アプリケーションを変更したいと思いますが、cvv と銀行口座情報は安全に保存しません。PCI DSS には 1024 RSA/DSA が必要です。毎月の支払い処理業者に送信するアカウント情報のバッチ ファイルを復号化するために、少数のユーザーに秘密鍵が与えられます。通常の 8 桁のパスワードでサインインしたユーザーが、自分のアカウント情報を安全に変更できるシステムを構築できるかどうかは不明です。これは不可能であり、暗号化は一方向 (つまり、各ユーザー -> 管理者。ユーザーが自分の情報を再度復号化することはできません) である必要があり、SSL 接続を介してもアカウント情報がユーザーに公開されることはありません。または、PCI DSS に準拠していることに気付いていない、これを行うための適切で簡単な方法はありますか?

次のようなショッピング カート フローがあります。

• ページ 1。製品を選択
• 2ページ目。単一ページのチェックアウトで、住所、配送先、クレジット カードの詳細を入力します。
• 3ページ目。ユーザーは注文を確認しますが、アップセルする最後の機会が必要なので、請求額を変更できる必要があります。ユーザーがこのページを放棄した場合、請求や承認は行われませんが、電話番号を再度尋ねることなく、電話して注文するよう説得できる必要があります。

• 4ページ。領収書ページ

• 金額とスケジュールが変動する繰り返し請求は、後で行うための要件です。(ユーザーは、CC 番号を再度入力しなくても、戻ってスケジュールを変更できる必要があります)。

これが私がやりたくないことです：

• ユーザーをサードパーティのページに移動します (単一ページのチェックアウトが必要で、ブランディングを保持するため)
• PCI コンプライアンス要件を最小限に抑える
• 支払いを承認し、ユーザーが確認しない場合はキャンセルします。これは多くのレベルで問題を引き起こしています!

確認ページが必要なので、 braintreepaymentsが提供するような何らかのトークン化システムを使用する必要があると思います。基本的に、クレジットカード番号をサービスに保存すると、その番号を表すトークンが返されます。その後、いつでもそのカードに対して任意の金額を請求できます。これは確かに最も柔軟なソリューションのようです。

私は、これが最善の解決策であるかどうかを判断しようとして、ぐるぐる回っています。

• BrainTree がそのようなサービスを提供する唯一の会社かどうかはわかりませんが、本当に必要かどうかもわかりません。
• ユーザーが確認するまでCCを一時的にセッションに保存すると、ほとんどすべての支払いゲートウェイを引き続き使用できます. したがって、問題は「CC を一時的にメモリに保存しても問題ないか」と、その程度です。

「最も純粋な」最も安全なアプローチは、braintree (または同様のゲートウェイを提供する他の誰か) にリダイレクトすることです。

編集（賞金を割り当てた後）：

私は、PCIのレベル A を満たすだけでよいシステムが絶対に必要であると結論付けました。PCI をより詳細に研究しており、これらのアンケートは、カードを提示しない加盟店 (つまり、電子商取引) に関連するものです。

SAQ A : (CC 番号がサーバーに接続されていない場合)。オンラインで販売している場合でも、このアンケートに記入する必要がありますが、とても簡単です。

SAQ D : (保存しない場合でも、CC 番号がサーバーに接続される場合)

これらのアンケートを見ると、要件間に大きな差があることがわかります。PCI 要件は、「ファイアウォールを維持する」、「セキュリティ ポリシー」、「物理アクセスを制限する」などの単純なリストであると誤解されることがよくありますが、実際にアンケート D を読むと、非常に多くの質問と要件があることがわかります。 . たとえば、サーバーがビデオカメラで保護されているかどうか、およびサーバーでどのような種類のデータ暗号化が行われているかを回答する必要があります。

私がやりたいことを容易にする実際の製品やプロバイダーを知っていただければ幸いです。私にこれをさせてくれる会社が本当に1つか2つしかないのなら、私は知る必要があります.

Braintree とは何の関係もありませんが、彼らの電子メール マーケティング リストに参加することができました。彼らは、これを行うことができた唯一の会社です。同じことをしている別の会社を経営している場合は、ぜひ自分のラッパを吹いてください。PCI の要件は時間の経過とともに厳しくなる一方です。私の質問をここまで読んだことがある人なら、おそらくすでにそのことに気付いているでしょう。

クライアントの1人から渡されたWebサイトの1つでPCIスキャンを実行しました。次のような脆弱性の報告がいくつかあります。

ネットワークサービス：80/443アプリケーションURL： http ://www.oursite.com/signup.php 応答にSQLServerエラーが含まれています。これは、テストによって挿入された危険な文字がアプリケーションに侵入し、SQLクエリ自体に到達したことを示しています（つまり、アプリケーションはSQLインジェクションに対して脆弱です）。

要約テスト情報：ヘッダー：ヘッダーX-Forwarded-For =％2527

ここにコードを挿入したと彼らがどのように言っているのかわかりませんか？

彼らが別のURLを提供する別の例では、おそらく同じ問題がエクスプロイトと同じです。

要約テスト情報：ヘッダー：ヘッダーX-Forwarded-For = '

編集
私はこのヘッダーを調べましたが、プロキシまたはロードバランサー（とにかく使用していません）によってのみ設定されているようです。いずれにせよ、私はそれを自分で偽装しましたが、私たちの側には脆弱性がまったくないので、彼らが何を強調しているのかわかりません。このヘッダーを使用しないので、とにかく想定される攻撃ポイントが何であるかわかりませんか？

いわゆる脆弱性のもう1つの例は、次のとおりです。

ネットワークサービス：80/443アプリケーションURL： http ://www.oursite.com/products/product-na-here/370 テストは応答にスクリプトを正常に埋め込み、ページがに読み込まれると実行されます。ユーザーのブラウザ。これは、アプリケーションがクロスサイトスクリプティングに対して脆弱であることを意味します。

要約テスト情報：

パス：パス/ products / product-na-here / 370-> / products / product-na-here / 370、parameter：header>'"> alert（957652）

繰り返しますが、ここで何がフラグ付けされているのかまったくわかりませんか？

ありがとう。

Magento を実行している専用サーバー (Red Hat Enterprise Linux) の PCI コンプライアンスを取得しようとしています。最初にサーバーに Magento をインストールしたとき、RHEL には Magento には古すぎる PHP バージョン (5.1.6) が付属していることに気付きました。そこで、PHP バージョン 5.2.11 の別のレポを見つけました。これですべて正常に動作しましたが、今は行き詰っています。私の PCI コンプライアンス テストでは、PHP バージョンが 5.3.1 未満であるため、セキュリティ上の問題があるとのことです。5.3.1 にアップデートしようとすると、Magento が壊れます。これらの問題を修正するために Magento コアを編集したくないので、必要なのは PHP 5.2.11 のレポだと思いますが、PCI の問題を修正するためにバックポートしたと自信を持って言えます/証明できます。コンプライアンス スキャンが識別します。

これが非常に複雑であることは承知していますが、提案やヒントがあれば喜んで聞いてください。

ありがとう。

カードの詳細がPaypalなどのサードパーティによって処理される場合、PCI-DSSなどのeコマースコンプライアンスのどのような形式が適用されますか？

Paypal Expressを使用する特注のショッピングカートシステムを構築しているので、カードの詳細がサーバーに届くことはありません。ただし、私は顧客の詳細を保持しているので、コードレベルとハードウェアレベルの両方で、どのようなコンプライアンスを遵守する必要がありますか、または遵守する必要がありますか？