iframe injection question

[christopher.riley at r-it.at (christopher.riley at r-it.at)]

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

pauldotcom-bounces at mail.pauldotcom.com@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
> Pauldotcom at mail.pauldotcom.com
> 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.
----------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pauldotcom.com/pipermail/pauldotcom/attachments/20090605/96387f98/attachment.htm