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経由でのみアクセス可能で、その他のセキュリティ測定（キャッシュ制御、ページの有効期限など）も実装されていることに注意してください。

man-in-the-middlehtmlsensitive-data-exposure
4
Tamás Somogyi

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

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

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

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

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

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

1
Hector

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

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

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

0
McMatty