iframe an SSL secured form on a non SSL site

I开发者_如何学编程 have a request in from a client that would like one of their existing forms present on another website.

They would like to have a payment form present in an iframe.

What, if any, implications are there when iframing in an SSL website into a non-SSL website when payment processing is concerned?

---

Modern web browsers will not give any security warnings because the parent window is running insecurely over HTTP. The downfall though is that your web browser will not show a secure lock icon in the address bar since the secure content is inside of a child window (iframe), so your users may shy away in fear that the form may be insecure.

A man-in-the-middle attack is unlikely since all web browsers, classic & modern, denies any access to the iframe content via Javascript since the iframe is using a different protocol and/or domain name. The only way to communicate to the iframe at this point is through the postMessage function implemented in modern web browsers, which allows cross-domain communication via Javascript. Even if you are using postMessage, the iframe would need to include code that listens for postMessage events coming from the parent window, which in the case of developing a payment form in an iframe, only the parent window will need to listen for the event after the payment is processed. Thus, it is highly unlikely that a man-in-the-middle attack would happen if you keep the communication via postMessage one-sided (iframe executes postMessage only, and parent listens for messages).

Of course, anyone could override the event listener and execute code on the parent window, tricking the server into believing that a payment was processed. That is when you will need to take precautions in your server-side code that checks to make sure a transaction indeed happened legitimately. In my case, my payment form (iframe) creates a temporary key in the database and sends that key to the parent window via postMessage. Then, the parent window makes an AJAX call to the server, checks the database to see if the key matches, and quickly deletes the key before creating a record that a transaction did in fact happen.

---

Your users' browser will give them security warnings that basically say this is an unsafe scenario. For example, a man-in-the-middle attack could inject javascript into your non-SSL page and now you are potentially compromised.

In this scenario, a popup or flat-out page redirect is the appropriate way to do this. As you are probably well-aware, you want 100% of content in your browser to be hosted via SSL in this sort of scenario. Otherwise, you simply are not guaranteed to be protected. That's the reason for those warnings.