web-dev-qa-db-ja.com

以前に投稿されたHTML返信の同じ機密情報

ユーザーが以前にサーバーに投稿したのと同じ機密(PCI、PII)情報をサーバーからHTML返信で返信することは問題ですか?

私たちのウェブページで、ユーザーはいくつかの重要な情報(名前/住所/カード/アカウント番号など)を入力し、それがサーバーに投稿され、重要ではない詳細(日付、アカウント残高など)を含むページが返されます。)彼/彼女が提供したばかりのキー情報と一緒に、ユーザーがさらにいくつかのキー値を変更して検索を変更できるようにします。

例:
サーバーへのPOST:...&cardNumber=1111222233334444&...
サーバーからの返信:<html> ... <input name="cardNumber" value="1111222233334444" ... /> Here are some details about your card... </html>

最近、ウェブサイトのセキュリティ評価が行われ、レビュー担当者がこの動作を優先度の高い脆弱性として報告したため、サーバーからのHTMLレスポンスでマスクされていない機密情報(value="111122223333444"上記の例では)。彼らは、誰かがHTMLデータから機密情報を盗むことができるMITM攻撃に言及しました。

開発者はMITMが両方のトラフィックの方法からデータを盗むことができるため、MITMがPOSTメッセージからデータを盗む可能性があり、サーバーが送信されたものより機密性の高いデータを送り返していないため、そして、彼らはまた、インターネット上のいくつかのよく知られているWebサイトがこのプラクティスを行っていることを示すネットワークトレースを提供しました。

誰が正しいか:セキュリティレビュー担当者または開発者、そしてその理由

WebサイトはHTTPS経由でのみアクセス可能で、その他のセキュリティ測定(キャッシュ制御、ページの有効期限など)も実装されていることに注意してください。

4
Tamás Somogyi

あなたの開発者は正しいです。リクエストを処理するクライアントからサーバーにHTTPSが使用される場合、接続は両方向で同様に安全でなければなりません。両方の通信が同じSSLセッション上にある場合、実際の暗号化に使用されるキーは同一であることが期待されます。

しかし、なぜあなたはこれをしているのかという疑問を投げかけますか?クライアントがカードの詳細を送信したばかりの場合、なぜこれらをHTMLで送り返す必要があるのですか?これはクライアント側でJavaScriptで処理できませんか?

また、PCIデータセキュリティ基準については十分に理解していませんが、これはそれらに違反している可能性があります。領収書には制限があることを知っています。

することとしないことのガイド 読み取り-

PAN表示される場合は必ずマスクしてください。最初の6桁と最後の4桁は、表示できる最大桁数です。

これをHTMLで送信することは、表示方法の1つです。クライアント上の悪意のあるコードに関連する追加のリスクもあります。

1
Hector

依存-TLSを通過する場合、リバイアの発言は正しくありません。しかし、ここでの問題(間違っている場合は修正してください)は、Webページに機密情報が埋め込まれていることです。

したがって、XXSなどの追加の欠陥が見つかった場合、この機密情報をHTML構造から抽出できます。これで、ユーザーは自分のクレジットカードの詳細のキャッシュされたコピーを自分のマシンに保存しました。これが共有マシンの場合、それらも抽出できます。

うん-あなたはこれを修正する必要があります.

0
McMatty