Home page logo

pauldotcom logo PaulDotCom mailing list archives

iframe injection question
From: christopher.riley at r-it.at (christopher.riley at r-it.at)
Date: Fri, 5 Jun 2009 12:11:33 +0200

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 ???


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

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

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
Pauldotcom mailing list
Pauldotcom at mail.pauldotcom.com
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 

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]