It's a bad design and the entire page should use HTTPS, as this trains users to the unsafe practice of trusting and submitting private information over HTTP. It would be trivial for a man-in-the-middle attacker to alter the outer HTTP page to not use the correct HTTPS iframe, but instead an attacker controlled iframe (possibly HTTPS to an attacker ...
The best way to protect your application from clickjacking attacks, for modern browsers, is configuring your web server to send the X-Frame-Options in the response header.
Configuring this is quite easy:
First thing to note is that iframes (by default) don't act like they're part of the same origin, unless they are. If the iframe origin (in the src attribute) and the parent origin differ, the iframe will always be sandboxed from the parent. This imposes a bunch of restrictions, like being just unable to access most properties of the window.parent object.
Since the iframe is over HTTPS but the main web page is HTTP; this would be mixed content but browsers would only give a warning if HTTP content is embedded in an SSL protected page, not the other way around as it is in this case.
Its still an unsafe combination as the main page would be able to communicate with the iframe's contents via HTML postMessage ...
Use the following to embed URLs from different/untrusted ...
The HTTP header Content-Security-Policy can be used to protect from loading the page in an iframe.
In this case, its value is set to default-src 'self' *.xyz.com which means that only the current domain, and *.xyz.com can load this page in an iframe.
That HTTP header has other uses like protecting from XSS attacks. You can find more information on the ...
It's from including a Google+ button. You're sort of right though - it's Google seeing if you have a Google+ account in order to let you share the page on Google+, or potentially show a different button if you've already shared it.
However, only Google gets to see the data.
The entire frame is generated by Google, including the positioning. It is placed ...
No. A malicious site cannot interact with its iframes which point to other domains. It can only issue GET and POST requests without reading the corresponding responses, like any other web page opened in the same browser. A feasible attack would instead be clickjacking.
Is my website hacked by iframe injection?
No. Iframe injection means that an attacker has altered your site to load a malicious site's content into your page, carefully hidden. The injection refers to the malicious content being loaded into the browser that goes to your site, not how the malicious code was put onto your site.
When you say
Assuming your site is not "example.com" (i.e. that this is a cross-origin iframe) and that there isn't a separate security vulnerability on example.com (such as cross-site scripting), you can't do this. It would violate the same-origin policy, which is a very major security boundary for browsers.
You could try attacking the network, but HTTPS is in the way. ...
TL;DR iframe cannot replace sanitization completely, but is a great feature to use as security in-depth. Unfortunately, it does get in the way of some user-friendliness features.
I would be interesting in hearing a more informed answer, but I'm going to post some points I'm aware of.
Same Origin Policy works both ways. It's great that it keeps the iframe ...
Cross-frame scripting allows an attacker to embed your website within their own, as a frame/iframe and then spy on the users of your website.
This requires some social engineering. An attacker would trick someone into visiting their web page, with an iframe containing (say) the login to your website. The parent website would also need to have some malicious ...
You can set a Content-Security-Policy header with the child-src directive.
E.g., this will only allow frame content from the same domain:
Content-Security-Policy: child-src 'self'
Instead of 'self' you can also specificy a particular origin.
Here is a simple demo (the meta tag is used to simulate the header). Only the first frame should load:
Is it possible to read information entered into an iframe like this through a keylogger or invisible divs floating on top of the iframe?
Technically, the parent document can't capture a user's interactions with the iframe.1 But your main problem here is that the user has no way of verifying that the box they are interacting with is actually an iframe that ...
MDN - Content Security Policy (CSP) - Browser Compatibility shows what is supported in MSIE and what not. To summarize:
MSIE only supports the sandbox flag
MSIE only supports the old X-Content-Security-Policy header. It does not matter if it is deprecated - MSIE by itself is deprecated too.
Is there any alternative to CSP
There is no general ...
No, it is not safe.
If the parent page is not secured with https then there is no guarantee that the user will see the correct https iframe url.
An attacker may perform a man-in-the-middle attack on the parent page and cause it to render an iframe to the attacker's website. Since browsers do not indicate the url or https status of iframes the user would ...
It's called XSS (Cross-Site Scripting).
Quoted from here:
Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs ...
Does that mean that if I have a "secret image" on Facebook (or any other resource with cookie session auth) any malicious site that I accidentally visit will be able to load that image in a hidden tag e.g. and read it?
You are correct until the last two words. Yes, any site you visit can load the secret image into your browser. But it can not read it (...
A browser that supports frames but not the X-Frame-Options header (or the corresponding CSP policies) will simply render any frame content, regardless of the origin. It can't implement a security mechanism that it doesn't know about.
X-Frame-Options was implemented by most major browser around 2010 (and only later specified in RFC 7034 in year 2013) - at ...
Iframes are dangerous as the user has no easy way of verifying that the embedded page is indeed, say, facebook.com and not some phishing page. Depending on how it is set up, allowing embedding might also enable clickjacking.
Using a popup versus redirecting the current page is just a matter of user experience and has no impact on security.
They are false positives. Usually, is not a good idea to have two different AV software installed. One can block other as is your case.
In your case, concretely, it seems it's blocking database files. Maybe it has some known virus pattern. Of course, any AV has itself and its files as exception on detection but it is not know for other AV software and that'...
You can attack the extension
Fuck Fuck Adblock
Fuck Fuck Fuck Adblock
I'm not clear on how this works, but if you know what the script is called/and or get your hands on a copy of it, you can easily begin a sort of 'arms race' against this chrome extension.
CSP frame-ancestors already does what you want.
Content-Security-Policy: frame-ancestors [...] checks the entire ancestor chain. If any parent document doesn't match the source whitelist, your document will not be loaded.
If your chain is top(child(grandchild)), this policy for grandchild would pass:
Content-Security-Policy: frame-ancestors top child
Web wrappers within an app has become quite common among applications and is not going to change anytime soon. The following measures will be helpful for securing the account used here
Login without password - For example, Google allows you to login using your phone, Microsoft allows you to authenticate from it's authenticator app. This will prevent anyone ...
Imagine that the superSecretToken token was something retrieved from your service's server and was specific to the authenticated user. Or imagine that it was the user's bank balance.
Then any random webpage on the internet could embed your page in an iframe, and whenever someone visited the attacker's page and happened to be logged into your service, the ...
If you care about security, don't use iframe.
How can your user trust your iframe to enter their precious login information when the other site can use some simple css to put other elements above your iframe?
If you want security and provide a login solution that can be used by ...
X-FRAME-OPTIONS to your rescue!
If you want to load a page from one app to an iFrame on another use the "ALLOW-FROM uri" setting.
The X-Frame-Options response header
Clickjacking Defense Cheat Sheet
After a quick search, I found the following two relevant StackOverflow (SO) questions about this:
Preventing child iframe from “breaking out of frame”; and
Frame Buster Buster … buster code needed
These questions are a bit dated, but they suggest applying the following code to prevent parent (top) redirects:
Using an https iframe in an http webpage only protect against passive attackers.
It is not a good solution because:
It doesn't protect against active attacker (they can rewrite the url of the iframe, see sslstrip)
The browser can't display a padlock for https (because the main page is not secure)
The only way to handle data securely is with HTTPS on the ...