0

Regarding the insecure transmission of data over a network.

When it comes to plaintext credit card information and payment details being transferred in this manner over HTTPS. What are the possible methods of attack or vulnerabilities presented to a system administrator over the network API, if any? If so, are they strictly network-based attacks such as simple MITM attacks, by a user using a public proxy setup? Or attacks opened up by a user on the same network.

My main concern is the risk versus reward in this scenario, ultimately, should sensitive credit card details be transmitted over the network in plaintext/binary? Is this good practice.

Or are there preferable standards and methods for the transmission of sensitive data pertaining to payment details in place and documented? Such as global standards for payment processing.

Example Request (User Browser Form) - Copied in Curl Format via HTTPS

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

The insecure plaintext payment info is located:

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

Improve this question
2
  • 2
    I'm a little confused by your question. Are you asking if it is acceptable to transfer CC information over plaintext, or are you asking about the threats posed by insecure transmission?
    – Saustin
    Commented Sep 21, 2020 at 1:42
  • @Saustin Is it good practice (acceptable) or are their threats that arise when using this setup. If threats may arise, it's optional to list possible threats that may present itself. Thanks for the clarification comment, I appreciate it. +1. I added some context to the original post, based on your question also.
    – ABC
    Commented Sep 21, 2020 at 2:14

1 Answer 1

Reset to default
1

Credit card information should never be sent over plaintext. It will also violate PCI.

Credit card information should only be sent using encrypted transmissions. Ideally, in 2020, that is: HTTPS with HSTS, a certificate signed by a trusted CA, TLSv1.2/1.3, and a secure "A" ciphersuite configuration. To go the extra mile, check that all 3rd party scripts are using sub-resource integrity in their HTML tags and are also sent over HTTPS.

All of the above settings are used in tandem to ensure transport security from the client to server: HSTS ensures only HTTPS is being used, a certificate signed by a trusted CA ensures the user may safely trust the certificate, TLSV1.2/1.3 are safe to use to exchange keys (TLSv1.0/1.1 have issues), an "A" ciphersuite configuration does not have any known flaws, and sub-resource integrity will ensure that the user's browser does not interpret any malicious JS modified by a 3rd party on a potentially hacked website (for example, jQuery JS files on the jQuery CDN.)

The threats posed by transferring credit card information over plaintext is namely information disclosure via MITM. However, plaintext HTTP is also vulnerable to integrity and even repudiation -- anyone in the middle can modify traffic as well as viewing it. Users may also hesitate to send CC information over websites which do not have the padlock or HTTPS in the URL.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .