Locking down Chrome for hosted application - google-chrome

We need to publish a web browser (preferrably Chrome) via Citrix/XenApp. Security constraints required by our customer prevents direct browser access from the outside. To avoid opening up other security risks we want to prevent the user from doing anything else but interacting with our hosted application.
I've been experimenting with Chrome shortcuts (using the --app command line option) and Chrome extensions (which I then start with the --app-id command line option). Basically these work and look very good but I have two problems:
The keyboard shortcuts are not disabled which means that the user can do things s/he should not.
We need to open up more than one tab in our application. When using "--app" or "--app-id" new tabs are opened in a new browser window which is not constrained at all.
Is there a way to lock down Chrome to only allow interracting with a specific host address while still allowing more than one tab? I know that extensions do that but since new tabs are opened in new browser windows and the keyboard shortcuts are still enabled the user can easily do too much.

Related

Completely forget a single domain in Chrome

How do I completely remove all data about a single domain in Google Chrome? (in one action)
Use case:
I am developing an offline web application, and frequently need to 'start fresh' while testing
Chrome's "Clear browsing data" can only be limited to time, not domains
Removing a domain's pages in history does not remove service workers
App Cache doesn't work properly in Chrome's Incognito mode
Ideally, a UI button or keyboard shortcut would be best. Extensions are fine, if they work.
Please don't submit answer unless service workers are also removed (I know there are many solutions for cookies/cache etc).
thanks
Chrome now includes a 'Clear storage' function in the 'Application' tab of dev tools (using v52). Thanks Chrome!

How to turn off windows integrated authentication in Chrome

I used to be able to disable windows integrated authentication by updating the settings in IE. Recently this no longer works. Has something changed in recent versions of chrome? Is there a new way to turn this off?
Chrome version 46.0.2490.71
I used to use this setting in IE
Internet Options -> Advanced -> uncheck 'Enable Windows Integrated Authentication'
I got this response from an internal admin and it seems to work.
I think the best we came up with was to create a shortcut to
chrome.exe on your desktop and modify the target of the shortcut to be
something like:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --auth-server-whitelist="_"
Edit: Corrected the path for misplaced backslashes. Note also the (x86), just in case.
Expanding on Daniel Trimble's answer, which worked for me:
I would like to help more people find this useful answer by adding a little more context. What is Integrated Windows Authentication, and why would you want to disable it?
Basically, Integrated Windows Authentication allows a browser such as Chrome to access credentials that are stored on your computer (for example, the password you use to log into your office computer) and use those same credentials to log you into a website (for example, a password-protected portion of your company's website). This occurs behind the scenes, without a visible password prompt.
The problem is that you may not want to be automatically logged into a particular website.
Example: I like to use Chrome as a test browser to see the "public" view of my company's website. Generally I log into our site in Firefox or IE, make changes there, and then view the site in Chrome to make sure my changes were "published" as intended.
Suddenly, one day, I could no longer stay signed out of my company's website in Chrome. Whenever I navigated to a password-protected page, instead of giving me a login prompt, Chrome would automatically sign me in to Microsoft SharePoint (my company's content-management system) and show me the "logged in" version of that page.
If something similar is happening to you, there are other, more obvious things you should try first. Start by clearing your saved passwords (Chrome menu button > Settings > Show advanced settings > Passwords and forms > Manage passwords).
Clearing my saved passwords didn't work for me, so I tried other things: cleared the cache, removed all cookies, reset Chrome's settings, uninstalled and reinstalled Chrome. I even visited a password-protected page in an Incognito window, but Chrome still signed me in automatically.
Finally I found this Stack Overflow page, which solved the problem. (Thank you, Daniel Trimble!) Integrated Windows Authentication was the culprit. IWA used to be turned off by default in Chrome; you had to enable it via a checkbox in your Internet Options (shared with IE). At some point in the recent past, Google apparently decided to enable IWA by default. The unfortunate part is that they did not provide an option under Chrome's Settings panel to disable it. At least there's this workaround!
How to disable Integrated Windows Authentication (IWA) for Chrome via Windows' Control Panel:
(This applies to both Internet Explorer and Chrome since Chrome uses system settings that are managed using Internet Explorer.)
Press Windows' Start button, type "Internet Options" to search, and click the one result, from the control panel
Go to the "Security" tab
Select "Local Intranet" and click on "Custom Level" button
Scroll to the "User Authentication" section at the bottom of the list and select "Prompt for user name and password"
Click Ok, Apply, and Ok to save changes
Close all instances of the IE browser to make the changes effective. Launch the browser again and access the application. A basic authentication challenge will be served.
Source: https://sso.cisco.com/autho/msgs/disable_IWA.htm
I found out we had a windows policy that set the following registry key:
HKEY_CURRENT_USER\Software\Policies\Google\Chrome\AuthServerWhitelist
Deleting this key made Chrome prompt for a username and password for me.
More information about the registry keys.
Great and all the above answers work perfect.!
To add more -- I found that google chrome (version 68.0.3440.106) has the GUI option for Windows integrated authentication, just like in IE, this worked for me :)
goto chrome://settings/
Show advanced settings...
In the "Network" section, click on "Change proxy settings..."
Chrome opens the internet properties window
in the security tab
Select Local Intranet and Click on "Custom Level" button
Scroll to bottom of the window to User Authentication section, select "Prompt for user name and password"
Click Ok, Apply and Ok to save changes.
close existing session and start a new chrome session.

Chrome extensions and bookmarks disabled using Brackets.io

The question is regarding Bracket.io with Chrome as the default browser.
When using the option "Live Preview" Chrome browser opens with the live document, but does not show me the extensions and bookmarks that I have installed on my browser.
This is when Chrome opens Brackets Live Preview:
This is when I open it myself (with extensions and bookmarks but without automatic updates), which is how I would like to have it:
How I set it to open Chrome with my bookmarks and extensions?
Brackets Live Preview uses a separate Chrome profile from your regular copy of Chrome. It starts out as a completely clean new profile, so it won't have any of your regular bookmarks, etc. But Live Preview reuses that same profile on each subsequent launch -- so if you add bookmarks to the window Live Preview is running in, they'll reappear the next time you use Live Preview.
There are a couple good reasons for this, and also one way to work around it that's become available recently.
Quoting from my answer to "Why does Brackets open a new instance of chrome when using Live Editor?":
The Chrome profile that Brackets launches for Live Preview has the
Chrome Remote Debugging
API
enabled. There are two reasons Brackets uses a separate profile for
this:
Remote Debugging is off by default, and enabling it requires re-launching Chrome. Using a separate profile means your existing
browsing session doesn't have to be restarted, which would be
disruptive if you have lots of tabs open.
It reduces security slightly -- other processes on your local machine could use the Remote Debugging API to monitor / interfere
with other browsing you do in this Chrome window. (The API is not
exposed to the network, so if you trust your computer to be
malware-free, this is less of a concern).
If you don't like having to open a separate Chrome window, you can
check File > Enable Experimental Live Preview to try out a new Live
Preview implementation that doesn't require the Remote Debugging API,
and thus doesn't launch a new copy of Chrome. You can't use this
option if your project has a custom server URL set, though.
This is by design, as it sets various flags needed for remote debugging.
See this issue report on GitHub: https://github.com/adobe/brackets/issues/8653
In your first Chrome Browser : If you don't have chrome account, please SignUp and Login. All of your Chrome Preference will be save in your account.
Then, in Brackets's Chrome Browser you have to login to Show all of your Chrome extensions
& Bookmarks.

"Chrome legacy Window" when launching chrome with RunAs

I am trying to use MSAA (on Win7) to get the addressbar in chrome browser and replace it with a different url. When chrome is launched normally (as the loggedon user), I am able to find the addressbar using the IAccessible interface by traversing through the UI tree of the window classes owned by the process.
However, if I launch chrome as a different user (by using RunAs in windows), I see window with name, "chrome legacy window" when going through the classes owned by the "RunAs" process. The window hierarchy and the content within is vastly different from what I see if I scan the process that is running as the logged on user.
Although I can see (window classnames) Chrome_WidgetWin_0 & Chrome_WidgetWin_1 in both the browser instances, only the one running as the current user is giving access to the address bar.
Any idea on what is happening when chrome is launched as a different user? Is there any workaround or should I be looking at a different technology?
As Penn has noted this may have something to do with the PDF view which has caused peculiar problems in the strangest of places.
Looking at the bug tracker here it looks like sporadic behaviour with PDFs and the "legacy window" has been introduced in a recent build so perhaps try rolling back to an earlier version of Chrome.
Also I presume you are using chrome://accessibility with
Global accessibility mode: on
Show internal accessibility tree instead of native: on
or starting chrome with the flag --force-renderer-accessibility it seems to be a prerequisite for other automation programs like autoit as seen here.
If you can't get this method working I'd recommend trying the autoit script there.
Here is an autoit code example that shows grabbing the address bar and using it for general navigation, upon other things!
I have found that if a PDF file is open in the chrome viewer (in some versions of chrome) the window you referred to appears. Please confirm what URL is being used when you open chrome.
I have also read that a password request prompt can cause the same window to open. The PDF window only appears if the window is launched by certain processes/users

chrome extension: open an website with different account in each tab

I have several accounts for a website and currently I want to write an extension that I can open all the accounts simultaneously in chrome, each tab for one account.
So that means I want each tab with a separate cookie system, is it doable? If so please suggest the API I should use, thanks!
Go to Chrome Preferences. There is a Users section where you can add users. Each new user will have its own cookie jar, so you can log in to a site as many different users at once. It makes new chrome windows, but it seems you cannot drag a tab onto a window of another user.
According to Chrome documentation, you can modify HTTP headers (including cookies) in the onBeforeSendHeaders event handler. So, you need to store new cookies for every account by means of the onHeadersReceived event handler, and then substitute them for every tab in outgoing requests.
There even exists an extension which seems doing almost the thing you want - Chrome Cookie Switcher.
Also I have found an answer that may be helpful for your task: Associate a custom user agent to a specific Google Chrome page/tab.
I really don't think Chrome allows extensions to do this. If I recall correctly, extensions can inspect and block requests, but they can't modify them, such as changing cookies on the fly for each tab.
I suggest you use the --user-data-dir command-line option of Chrome. It allows you to keep several separate profiles, each in its own directory, and then you only need to start chrome with the proper option:
# run this command to use the first profile
google-chrome --user-data-dir=/home/binchen/my_chrome_profiles/my_profile_1
# run this command to use the second profile
google-chrome --user-data-dir=/home/binchen/my_chrome_profiles/my_profile_2
...
Each profile will be in its own Chrome window, with its own cookie store, instead of its own tab, but it's easier than writing an extension.
Lastly, if the website you're mentioning is Google, you can keep several Google accounts open at the same time.