涉及信用卡支付信息的以明文传输的敏感数据的漏洞和潜在规模

Question

关于数据在网络上的不安全传输。

当涉及到明文信用卡信息和支付细节正以这种方式通过HTTPS传输。通过网络API向系统管理员提供哪些可能的攻击或漏洞(如果有的话)？如果是这样的话，它们是否严格地基于网络的攻击，如简单的MITM攻击，由用户使用公共代理设置？或由同一网络上的用户发起的攻击。

我主要关心的是这种情况下的风险与回报，最终，敏感的信用卡细节是否应该以明文/二进制方式在网络上传输？这是很好的做法吗。

或是否有更好的标准和方法来传输与支付细节有关的敏感数据并记录在案？例如支付处理的全球标准.

示例请求(用户浏览器表单)-通过HTTPS以Curl格式复制

curl '' \ -H 'Connection: keep-alive' \ -H 'Accept: application/json' \ -H 'User-Agent: ' \ -H 'Content-Type: application/json' \ -H 'Origin: ' \ -H 'Sec-Fetch-Site: same-site' \ -H 'Sec-Fetch-Mode: cors' \ -H 'Sec-Fetch-Dest: empty' \ -H 'Referer: ' \ -H 'Accept-Language: en-US,en; q=0.9' \ --data-binary ' ' \ --compressed

不安全的纯文本支付信息位于：

--data--binary 'PAYMENT_INFO_PLAINTEXT' \ --compressed

Answer 1

信用卡信息不应通过明文发送。这也将违反PCI。

信用卡信息只能使用加密传输发送。理想情况下，在2020年，即HSTS的HTTPS，一个由可信CA签名的证书，TLSv1.2/1.3，以及一个安全的"A“加密套件配置。要进行额外的努力，检查所有第三方脚本是否在HTML标记中使用子资源完整性，并通过HTTPS发送。

以上所有设置都用于确保从客户端到服务器的传输安全性: HSTS确保只使用HTTPS，由可信CA签名的证书确保用户可以安全地信任证书，TLSV1.2/1.3可以安全地用于交换密钥(TLSv1.0/1.1有问题)，"A“加密套件配置没有任何已知的缺陷，子资源完整性将确保用户的浏览器不会解释任何可能被黑客入侵的网站上第三方修改的恶意JS (例如，jQuery CDN上的jQuery JS文件)。

通过明文传输信用卡信息所造成的威胁是通过MITM披露信息。然而，纯文本HTTP也容易受到完整性甚至抵赖性的影响--任何中间的人都可以修改流量，也可以查看它。用户也可能不愿意在网站上发送CC信息，这些网站在URL中没有挂锁或HTTPS。