Although I agree in principle that users will almost always click the YES button to anything that comes up, it's sometimes hard to explain that to management as they want to believe that their staff are somehow different to normal people. The arguement that often appears is that the company has conducted security awareness training, therefore the average user would never click YES blindly. We all know however, that it's a natural reaction to click through without reading the alert box.
What you could try, and I'm no expert here, is to pull up an iframe containing secure content (whatever doesn't put up the warning box), then using javascript, edit the contents of the iframe to insert your desired code directly. This should bypass the warning as you're initially loading an HTTPS page, but then you're deleting the contents (or not) and replacing it with your own code. Just out of interest, what are you putting into the iframe ? BeEF ? loading a malicous PDF etc ??? Chris [email protected]@inet wrote on 04.06.2009 15:09:27: > >I understand that - but assuming that's not an option - HTTP only on > the injected code - is there > >another wayto do this? Not necessarily through a plain iframe - are > there any javascript, encoding > >tricks, etc that would cause the browser not to recognize the mixed > content? > > I think you're talking about two different things. The browser's > response is to the protocol that the content is coming from, but you're > talking about using the content itself to modify that response. The > problem is that the content doesn't arrive until AFTER the browser > checks the protocol & prompts the user. At least that's my > understanding. > > If you can only inject into an iframe then I think you're only option is > going to be to serve the page from an HTTPS server. > > From a different perspective, what user doesn't already click ok when > they see those warning boxes? From a test perspective, it may be even > more telling to show that the exploit was successful regardless of > browser warnings. In other words you can't expect the users to protect > themselves. > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com ---------------------------------------- Raiffeisen Informatik GmbH, Firmenbuchnr. 88239p, Handelsgericht Wien, DVR 0486809, UID ATU 16351908 Der Austausch von Nachrichten mit oben angefuehrtem Absender via E-Mail dient ausschliesslich Informationszwecken. Rechtsgeschaeftliche Erklaerungen duerfen ueber dieses Medium nicht ausgetauscht werden. Correspondence with above mentioned sender via e-mail is only for information purposes. This medium may not be used for exchange of legally-binding communications. ----------------------------------------
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
