I have been reading a lot regarding iframes and clickjacking, and was not able to find the information I am looking for. Can you help me out with below questions?
How does Iframe clickjacking spread? I have seen lot of articles which mentions editing of html code in the local machine and by the same they are able to hijack users click by adding an invisible button. But, this is a modified logic on a local machine of a user. I am interested in knowing is it possible to push this same code to the cloud and impact every user logging in or using that portal? If yes, how?
If I enable Iframe options on my website, it is a security risk because my page can be loaded as an Iframe in some one else's website and they can misuse it. And if there is any secured data, if end user is accidentally entering on that website, the data is hacked. This is a security concern so it is always recommended not to allow Iframe, is that correct? Are there any other security risk.
Please add if there are any other risks.
Clickjacking does not spread.
It is literally as it is stated - jacking clicks - nothing more. However, the consequences of those clicks could be severe.
Imagine you visit a site, evil.example.org. In another tab you are also logged into your bank, bank.example.com.
evil.example.org also loads bank.example.com in an IFrame. However, it uses CSS to make this IFrame invisible. And it does not load the home page, it loads the money transfer page, passing some parameters:
<iframe src="https://bank.example.com/loggedIn/transferMoney?toAccount=Bob&amount=100000"></iframe>
Now, this page does not transfer the money immediately. It asks the user to click to confirm the transfer to Bob.
However, evil.example.org draws a button right underneath the Confirm Transfer button saying Free iPad click here.
Because the IFrame is invisible, the user just sees Free iPad click here. But when they click, the browser registers the click against Confirm Transfer.
Because you are logged into the bank site in another tab, Bob has just nicked your money.
Note that the X-Frame-Options header fixes this vulnerability on your site, assuming it is set to SAMEORIGIN or DENY. You are vulnerable until you add the header. There's a new directive in CSP called frame ancestors - however, only the latest browsers support it, so you're best off adding both headers at the moment. This will give you protection on Internet Explorer 8 and later, plus Chrome, Firefox, Opera and Safari.
Preventing framing can also help thwart over attacks such as Cross Site History Manipulation.
Related
Apart from all the other typical security best practices I'm wondering about this, since I lately read some articles talking about how browser extensions can spy anything their user does. So that we shouldn't trust them.
Therefore in order to give users and additional layer of protection should I process all users credential and sensitive info inside an iframe inside my webpages?
Can content inside a sandboxed iframe be read/spied by browser
extensions?
Yes
Could I use iframe to secure user credentials?
Quick answer, no.
When a user installs a chrome extension the extension can do basically anything in the website to access the user credentials. The extension has also access to the iframes that the page generates.
My proposed solutions to overcome this two issues and keep the website feel "secure" are the following:
If the end goal is to secure the content that your user will put in the website, and by no mean you want to let the user put content if there are other kind of extensions running in the page, what you can put is some kind of pop up in the page blocking the access to the user until he is accessing the website without extensions.
Another solution you could propose to the user is to go incognito mode, as there are many options to disallow extensions in incognito without having to force him to uninstall all of the extensions that he has on his browser. This could also make less users leave your page, as if you force him to uninstall of the extensions on his browser it might make him leave your page if it's not a clear enough reason for him.
If you do know which are the extensions that shouldn't be blocked or prevented because they are harmful or known to have some kind of shady behaviour, what you can do is checkout if the user has them installed with this solution Checking if user has a certain extension installed and then print a message to him saying he can't continue until he uninstalls those extensions.
My webmaster has an online store on a site with ssl that i would like to feature on my site. He says this could be done with an iframe. Are there any security risks in using an iframe for this shop, in example a middle man attack? Or is this safe for any customers using it because the origin is protected?
Although iFrames are, in theory, loaded securely in their own environment, there are several security issues with them including:
They can be used for ClickJacking attacks. For example a site loads another website in an iframe and then floats username and password text boxes on top of the iframe so people think they are typing these into the website in the iframe, when in fact they are not.
It's not easy to see the website the iframe is loading. For example you load a frame of badbank.com and make it look exactly like goodbank.com. The user has no idea which domain has loaded as there is no address bar nor green padlock.
In general it's suggested for websites to prevent framing using X-Frame-Options or Content Security Policy HTTP Headers to prevent framing.
For sites like you doing the framing (rather than being framed) you are therefore risking your users. So if your site is hacked then this might lead to above issues. Additionally I've worked on a couple of sites where framing suddenly broke when the framed site prevent it from being framed anymore using above headers. Which looks bad on your site.
Finally framing breaks some of the fundamental ways of using the web (e.g. Back button).
All in all I would caution against iFrames.
I have a Java web application in domain A (that we control). This application displays another website located in domain B (which we do not control) in an iframe. This external website was recently updated to require users to log on before they can see content. They provided us with a URL that will automatically log our users into their site. This URL works when we navigate directly to it in Internet Explorer (we get automatically logged in etc).
However, apparently there was an update to Internet Explorer so that cross domain communication is not allowed. So now when the login URL is displayed in the iframe, it does not successfully log on (I am guessing its being blocked from creating security cookies).
Also, if we browse to the URL directly and get the security in place, then any iframe elements of the site will not work (I am guessing it is being blocked from accessing security cookies).
Does anyone know of a work around for this? Changing the security level on Internet Explorer is not an option (it is controlled by our company's system administrator). Internet Explorer is also our company standard, so we cannot change that (even though it works fine in Firefox).
When you say "elements of the site will not work" what precisely does that mean?
"Cross-domain" interactions have always been restricted in all browsers. This is called "same-origin-policy" and it's the foundation of web security. The "update" to Internet Explorer you're referring to restricts IE such that a webpage on Domain A can no longer navigate a subframe that is inside a page from Domain B. That restriction has been present in IE for 7+ years and is in all browsers. This restriction is not causing your problem.
This most likely problem here is that the subframe fails to set a P3P header that would permit its cookies to be stored. There are perhaps 30 duplicates on that issue on StackOverflow.
To determine if this is what you're encountering, try this:
In IE, click Tools > Internet Options > Privacy tab.
Set the slider to Accept all
Clear your cookies
Restart the browser and retry the scenario.
If this change solves the problem, then the fix is easy: configure the page which is being framed to specify its cookie policy using a P3P response header.
If this doesn't solve the problem, please update the question with more information that would allow others to reproduce it (e.g. traffic logs, live site URL, etc).
It turns out that this was causes by the login site not being on the trusted sites list. Having security add it as a trusted site and pushing that to all company computers solved the issue.
I should note, I'm not a chrome extension expert. However, I'm looking for some advice or high-level solution to a security concern I have with my chrome extension. I've searched quite a bit but can't seem to find a concrete answer.
The situation
I have a chrome extension that needs to have the user login to our backend server.
However, it was decided for design reasons that the default chrome popup balloon was undesirable. Thus I've used a modal dialog and jquery to make a styled popup that is injected with content scripts.
Hence, the popup is injected into the DOM o the page you are visiting.
The Problem
Everything works, however now that I need to implement login functionality I've noticed a vulnerability:
If the site we've injected our popup into knows the password fields ID they could run a script to continuously monitor the password and username field and store that data. Call me paranoid, but I see it as a risk. In fact, I wrote a mockup attack site that can correctly pull the user and password when entered into the given fields.
My devised solution
I took a look at some other chrome extensions, like Buffer, and noticed what they do is load their popup from their website and, instead, embed an iFrame which contains the popup in it. The popup would interact with the server inside the iframe.
My understanding is iframes are subject to same-origin scripting policies as other websites, but I may be mistaken.
As such, would do the same thing be secure?
TLDR
To simplify, if I embedded a https login form from our server into a given DOM, via a chrome extension, are there security concerns to password sniffing?
If this is not the best way to deal with chrome extension logins, do you have suggestions on what is? Perhaps there is a way to declare text fields that javascript can simply not interact with? Not too sure!
Thank you so much for your time! I will happily clarify anything required.
The Same origin policy does indeed protect the contents of the iframe from the main page.
However. There's no way for the user to know whether the iframe in the page belongs to your extension or not. A rogue page could copy your design and impersonate your extension, and ultimately steal the credentials.
The only secure way to get the user to input credentials is through a separate window, popup or tab.
Chrome offers an API to open a window with desired properties, which should be sufficiently flexible to meet your design requirements. See this example, which is also about getting a credentials in a popup window: https://stackoverflow.com/a/10341102/938089
I am working on a website related to physically/psychologically abused person.
There is an emergency exit button available all time so the user can click on it before the "aggressive" person enter the room where the computer is located.
When the user click on the emergency button, the user is automatically redirected to Google with a query like "cooking apple pie" (this is an example).
Also, we would like to hide our website from the browser history in case the aggressive person check the history of the abused person. I think this cannot be done technically.
At least, can we generate fake browsing history to justify to the aggressive person the time that the user was on our website?
I tried multiple things to simulate a "browsing" like using an iframe or an ajax query to another website but none populate the browser history.
Is this can be done?
Thank you for your input!
I think you may be focusing too much on the browser and computer that you do not control and not enough on the content and the server that you do control. How about taking a different approach? Why not generate the pages for the user on the fly? The links are only good once. If you click on the home button (your escape key) and the aggressive person looks in the history the attempt to access them a second time could be made to display the weather or lottery results or something innocuous, Focus on what you have control over.
Useful Technical Details
Removing/Preventing Back Button Click History
You can allow the user to browse throughout a webpage without building up a history trail on the back button by having them click exclusively on javascript: links. This would still not remove any of the visited websites from their full browser history, so it's not a full solution.
Here's an example HTML JavaScript link:
CLICK HERE TO ESCAPE!
If this is acceptable, you could build an inoffensive homepage from which the user could access the site that would use JavaScript to send them to the real website. Every link on that new website would have to be a javascript link. Disadvantages of this would be that they would no longer be able to use the back button to navigate and that JavaScript is 100% required for the site to function.
Sanitized History
Make sure you have inoffensive titles and icons for any pages in the site so if the user does not delete their browser history they will not grab the attention of the third party.
Preventing Access to Protected Content
One option you have is to disguise your website as something else by having the user log in before they are allowed to access any of the content. You could save their session/login data in such a way that it is cleared if they hit an escape button it is erased or reset. As part of the login page, you could give users an alternate password to type in that would redirect them to fake content if their abuser becomes suspicious enough to demand they log in.
The session/login information should never save between browser sessions and always have a short expiration period, to further reduce the chances of the abuser gaining access to the website.
Disguising the Site
Considerations
If you choose to disguise the site either on the homepage or behind a "fake" login, be very careful to choose something that makes sense and would not arouse suspicion or interest. You don't want the fake page to be some sort of game or anything that might pique the third party's interest.
You also don't want it to look so boring or mundane that the original user would be hard-pressed to explain their possibly frequent visits. It shouldn't be anything so specific that the third party would think twice about the original user visiting it though. For example, it might be suspicious if someone who does not enjoy the great outdoors were to be visiting a page on mountain biking.
It also can't do something like just redirect them to Google without explaining the fact that they had to log in to access it.
General Advice
Private Browsing
Multiple sources have suggested either educating your target audience in how to use IE's InPrivate Browsing mode, Firefox's Private Browsing mode, or Chrome's Incognito mode.
There unfortunately does not appear to be a way to prevent the browser from keeping the current page in its browsing history through JavaScript. It's possible there might be some sort of plug-in or third-party control which would enable this, but it's probably just easier to get your users to use a private browsing mode.
Clearing History
Clearing a user's web history would not be possible since browsers restrict websites from accessing or altering data on the user's computer directly. Since the user's browser history is part of this data it would be a security issue if any website could clear the history.
You should provide instructions to your users for pruning or clearing their browser history, whether on the website itself before they enter, or through whatever resource you showed them how to access your website.
Generating a Fake History
If you need to generate a fake list of visited websites, you can always create new tabs/windows for the users (or possibly iframes) at timed intervals with JavaScript, but the user would have to disable their popup blocker for this to take effect.
Further Reading
Here is a helpful article on creating a useful Quick Disguised Exit From A Website. This forum thread that I found it on also had some useful information, but it's likely you've already seen it.
At least, can we generate fake browsing history to justify to the aggressive person the time that the user was on our website?
Have you cosidered turning it around?
What if technically all your pages and its content are about something else. So it is the content you want to hide that's loaded in a special way, making it easier for you to avoid having it in the browser history.
So then it becomes about knowing when to load/show the special content.
Above said, it's very important what #Frédéric Hamidi said:
Just keep in mind that if the "aggressive" person has control over that computer or the network, nothing can really prevent him/her from installing loggers on the machine or analyzing network traffic.
IE's InPrivate Browsing mode, Firefox's Private Browsing mode, and Chrome's Incognito mode
I would recommend this to prevent the abuser from finding the secret site in the browsing history.
Also, opening a social networking site and letting the browsing history collect that would be an excellent and believable excuse for the time spent on the computer.