Re: Secure iFrames

[Dave Pyper <davepyper () davepyper com>]

From a high-level, your design should start with the HTTP-served index.html page that redirects to an HTTPS-served 
index2.html that calls the remote HTTPS-served iFrame-embedded page(s). There are details that will be specific to your 
implementation, like protocol restrictions on index (HTTP-only) and index2 (HTTPS-only) files, and so forth that I 
won't go into. But for the sake of old-school simplicity, that's the model I recommend and use. 


> On Nov 3, 2014, at 05:02, NightShade <avghacker () gmail com> wrote:
>
> Was hoping to get some feedback on what everyone feels are best practices around securing iFrames.  I've seen a lot 
> of payment platforms moving in this direction (ie. Gumroad, Stripe, Memberful) yet with little documentation around 
> "here is the best way to secure the iFrame our JavaScript generates".
>
> The best documentation I've seen so far recommends an HTTPS webpage with the each link pointing to an HTTPS link as 
> well.  This way when you click the link to load a modal / JS for the payment solution it is "supposedly" done over 
> HTTPS even though the browser won't present a padlock (assuming the hosting page is HTTP).  The other example I've 
> seen is a simple HTTP page that contains an HTTP link which in turns opens a secure iFrame....which is probably not a 
> good idea since you are mixing secure and non-secure content.
>
> Thoughts?
>
>
>
> This list is sponsored by Cenzic
> --------------------------------------
> Let Us Hack You. Before Hackers Do!
> It's Finally Here - The Cenzic Website HealthCheck. FREE.
> Request Yours Now! http://www.cenzic.com/2009HClaunch_Securityfocus
> --------------------------------------



This list is sponsored by Cenzic
--------------------------------------
Let Us Hack You. Before Hackers Do!
It's Finally Here - The Cenzic Website HealthCheck. FREE.
Request Yours Now!
http://www.cenzic.com/2009HClaunch_Securityfocus
--------------------------------------