2

I was going to apply for a Student ID card through ISIC, but noticed that the form where they ask for payment (such as credit card number) details is not available through HTTPS.

The URL to their purchase form is http://www.myisic.com/get-a-new-card/

I asked ISIC about this and they replied with that the form submission is encrypted.

Is it possible to encrypt a form submission reliably when the form is accessed through the HTTP protocol?

How can a user in this kind of case confirm that the form submission is encrypted, since the browser (in my case Firefox) does not indicate encryption by highlighting the URL in green?

7

To expand on Thebluefish's answer, the form submission process appears to use HTTPS (an encrypted protocol) for the credit card element to https://connect.firstdataglobalgateway.com/IPGConnect/gateway/processing when I am looking at the page. But this does not mean this setup is safe to use.

The overall setup is very vulnerable and needs to be fixed. I would not submit any credit card details through this service and would recommend that you do not use it. If you absolutely need to use it, you should get a prepaid credit card with just the amount necessary for this service and then use that credit card to minimize the damage if it is stolen. Or if your credit card offers one time use credit card numbers, you could possibly use that (though again, would be at some risk of the one time use credit card being captured and used for a different purchase).

The problem with the page is that everything but the form submission is being sent over unencrypted HTTP, that any network attacker can trivially alter. E.g., an attacker could buy a domain and then change the domain where the HTTPS form is sent to one they control (that may even look similar).

They could keep the form sending the data to the correct domain via HTTPS, but insert malicious javascript anywhere on the page or in one of the libraries to bind an action to additionally send the form data to some attacker controlled URL.

Again, we could look at the page as it renders right now for us and determine it doesn't do any malicious actions. But any router/ISP/computer between you and the server www.myisic.com could change the current content of the unencrypted http page to something malicious allowing your credit card details to be stolen.

3

If you look at the source code regarding the credit card form, you can see the following:

<form name="form" method="post" action="https://connect.firstdataglobalgateway.com/IPGConnect/gateway/processing" id="payForm">

Therefore the form submission is over HTTPS. This should be fine in ensuring your credit card details are not stolen, though your personal information (Name, address, etc...) is transmitted over HTTP.

  • 2
    I would add there is some risk here. The original page could be altered via a MiTM attack since it's served in plaintext, redirecting the user to a malicious site. – theterribletrivium Nov 26 '14 at 19:19
  • 1
    @theterribletrivium Good point. Yeah, without the site being secured via HTTPS as well, there's no guarantee that your information won't be stolen unless you check the source every single time. – Thebluefish Nov 26 '14 at 19:22
  • 1
    Good answer and comments. Indeed any page that has a form with information that needs to remain private should be exclusively from a page that is completely HTTPS protected to protect from MitM manipulating the DOM. Even without redirecting to a malicious site, the form action could be rewritten to use http instead of https. – Andrew Hoffman Nov 26 '14 at 19:41
-1

Encryption could have been done with javascript before the form is posted. To do so, the encryption algorithm and public key has to be sent to the client if using asymmetric encryption. For symmetric encryption, both algorithm and key must be sent.

However, I have not found any javascript encryption library or function used in the page. An example of such a library would be CryptoJS. Therefore your personal particulars are not being encrypted.

  • 1
    Well that's not true for information sent from the user to the server. The server can send a public key to the user for encryption. Once encrypted the content can only be decrypted with the private key held on the server. This is common practise for PGP/GPG email encryption. When information is sent to the user, then the user needs a private key, and then security can be compromised. – SPRBRN Nov 27 '14 at 12:54
  • agreed. will modify my answer to mention that only encryption algorithm will have to be sent to client. Encryption key can remain secret if using asymmetric encryption. Thanks for pointing that out. – limbenjamin Nov 27 '14 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.