Is it possible to tell headless Chrome somehow to resolve example.com to 127.0.0.1 without editing /etc/hosts ? I am testing an oauth login flow where the provider determines the hostname where it redirects to based on the application ID and this makes automated testing problematic.
While the command line argument --host-rules="MAP my.site.com 127.0.0.1", like this: chrome --host-rules="MAP my.site.com 127.0.0.1" will do a host override, currently headless chrome doesn't support this https://bugs.chromium.org/p/chromium/issues/detail?id=798793 .
Note if you are using a self signed certificate, make sure it has a subject alternative name of IP.1 127.0.0.1 , not my.site.com.
Related
I am trying to write a question for a CTF (Cybersecurity Hacking Competition). Part of the question will include an XSS vulnerability where the user can "report" a URL. When the user reports a URL, I run chromium in headless mode to visit the URL.
I am currently using the following shell script (.sh) to make chromium visit the URL in headless mode (while hiding all output and running in the background).
chromium-browser --headless {url} > /dev/null &
I want the "flag", or what the user is trying to steal from the fake user, to be the browsers user agent.
I plan on running this question from an AWS EC2 server, so I do not believe I can change chromium's user agent by visiting some options in the browser. Is there a way I can do this from the console? Perhaps an option in chromium-browser or a config file that I can write to?
Edit: Should have mentioned that the system I am running on is Ubuntu 18.04.
Edit 2: An example of what the User-Agent should look like: flag{u53r_4g3nt!!}
All of a sudden I seem to have an issue with Google Chrome using localhost.
I'm trying to access any of my development sites (using Ampps) and I get the following error:-
Your connection is not private Attackers might be trying to steal your
information from website.dev (for example, passwords, messages
or credit cards). Learn more NET::ERR_CERT_AUTHORITY_INVALID
When I visit any of the dev sites it is redirecting from http://website.dev to https://website.dev automatically. I'm not having any issue in Safari or Firefox so I don't understand what is going on.
I've tried re-installing Google Chrome, resetting it to the factory default settings...
I think it could be an issue with Keychain Access --> Certificates but wouldn't that mean it wouldn't work in Firefox and Safari if that was the case?
I've spent a while trying to find a solution but so far nothing has worked so I would appreciate some suggestions on how I can fix this. I can't even proceed passed this warning as I don't get the proceed link (insecure) as shown below:-
Navigate to
chrome://flags/#allow-insecure-localhost
and set this to enabled.
After playing around, I came up with one kind of a solution.
First, lets talk about the problem: the cause of this error is that both of us used a .dev domain for our local development. If you go here you will find out that root .dev domain is owned by Google and applying HSTS in Chrome they enforce https-redirect for this domain. Since we use .dev domains, we get redirected to https version and at the same time we don't have any actual certificates installed. So, we see this annoying error. If you go to chrome://net-internals/#hsts you can check your .dev domain and you will actually find out that
static_sts_domain: dev
static_upgrade_mode: FORCE_HTTPS
static_sts_include_subdomains: true
which confirms that HSTS is enforced on *.dev indeed. The policy type is static and, as I understand, it's kind of hard-coded to https-redirect .dev domains.
So, there are at least 2 ways - get and set up an actual certificate somehow or just use another (not .dev) root domain in httpd-vhosts.conf for your local development (also don't forget to update /etc/hosts and launch apache again). I went another root domain route and it solved this issue.
This is really annoying to deal with, but mapping the local website to something other than .dev (I personally use .devo) does work and fixes the problem in chrome. Also, you can add an exception for the page in Mozilla Firefox and not deal with this at all. It's only a problem on Chrome 63+
Best solution is to not use .dev because it owned by Google.
Here you can find an updated list of all claimed TLDs : https://www.rfc-editor.org/rfc/rfc6761
To be safe, choose an unclaimed TLD like .test or .localhost. You can read a useful blog post here : https://iyware.com/dont-use-dev-for-development/
I got same bug， because the CRL file is out of date， and the solution is that update the crl file
you need to add remote site certificate to your local key store
To download certificate from remote site, you will require keytool, open gitbash as admin and run below command to generate the certificate
openssl s_client -showcerts -connect host:port
save the value of above command to from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- to the .crt file.
to add certificate to your local key store, run below command
keytool -import -noprompt -trustcacerts -alias name_of_certificate -file "path_of_dot_crt_file" -keystore "C:\Program Files\Java\jdk1.8.0_192\jre\lib\security\cacerts" -storepass changeit
you can also add downloaded certificate to your browser.
In my case, in order to solve the issue so that I can "Proceed to unsafe",
I needed to go to:
chrome://net-internals/#sockets
then click: "Close idle sockets", "Flush socket pools"
Afterwards go to:
chrome://net-internals/#dns
Then click "Clear host cache"
If it still doesn't work and you are a mac user, try to repeat above after removing localhost certificates using Apple's Keychain Access tool
Google Chrome is ignoring the settings in C:/Windows/System32/drivers/etc/hosts file. Both IE11 and Firefox are installed on the same machine and work as expected.
I've tried all the solutions I could find online including:
Open chrome://net-internals/#dns and click the Clear Hosts Cache button.
Go in Settings, Show Advanced Settings and uncheck the following three options: (X) Use a web service to help resolve navigation errors (X) Use a prediction service to help complete searches and URLs typed in the address bar (X) Use a prediction service to load pages more quickly
Go in Settings, Show Advanced Settings, click the Clear Browsing Data button, selected Cached Images And Files from the beginning of time, and click Clear Browsing Data.
Restart Chrome.exe.
Restart the computer.
Make sure to add http:// to the front of the web address.
Make sure proxy settings are turned off
Run cmd.exe and run ipconfig /flushdns
Uninstall and reinstall Chrome
I'm at a loss... Is there anything I missed that I can try or check?
Seems that Chrome doesn't likes the following extensions for that kind of stuff:
.dev
.localhost
.test
.example
.app
Use .local and the problem seems to disappear.
If anyone stumbles on this problem in 2021, for me the fix was to disable Use secure DNS option from chrome settings. After disabling that, all the options in the hosts file started working.
The option is located under Privacy and Security > Use secure DNS
Link to get there faster:
chrome://settings/security
This has been identified as a "bug" in Chrome, but it appears to be absolutely intentional behavior. Google Chrome does not honor /etc/hosts when connected to the Internet. It always does a DNS lookup to determine IP addresses.
While my references below mostly relate to my expereinces with this on Linux, it is not confined to Linux.
https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/iKXqyc40tW0
https://superuser.com/a/887199/75128
https://bugs.chromium.org/p/chromium/issues/detail?id=117655
Okay I faced the same problem but then I found the solution.
Try this:
Go to history (Ctrl+H) -> In the left pane click on Clear browsing data
In the new window that opens go to Advanced tab
Set Time Range to All Time -> check Cached Images and Files -> click on Clear data
Restart your computer, It should start redirecting addresses mentioned in Hosts file (C:\Windows\System32\drivers\etc\hosts)
Note: This Solution is only for Google Chrome
Try clearing the DNS Cache:
1) run cmd.exe as administrator
2) type: ipconfig /flushdns
I just encountered this tonight and none of these options worked. I discovered that Chrome now hides "www" (https://www.howtogeek.com/435728/chrome-now-hides-www-and-https-in-addresses.-do-you-care/). Chrome was using my hosts file, but I had to add "www." to my hostname in my hosts file since that's what the browser is actually requesting, even if it doesn't show it.
A little late, but after hours i find a solution. It seems that Google Chrome sometimes has problems on recognize the name of the hosts defined en /etc/hosts.
I'm using linux and i'm behind a proxy.
Try adding at the end of the name server: .localhost
Example:
At: /etc/hosts:
127.0.0.1 myservername.localhost
On the virtual-hosts of your server configuration you'll need to rename the server name. In my case, i'm using apache so at /etc/apache/sites-enabled/myserver.conf rename the line of the old server name with:
...
ServerName: myservername.localhost
If you are behind a proxy, you can except all the hosts just adding to the no_proxy vars:
$no_proxy= "localhost"
Finally don't forget to restart the server and try to access on the browser with the new server name.
😊 simple answer 😊
there are 3 workarounds about this:
1- deleting Visited Links binary file (beauty👍)
2- using .local or .app instead of your desired TLD (standard & preferred by chrome docs but i don't like it)
3- restarting your computer (ugly👎)
deleting Visited Links binary:
kill all chrome tasks (close all chrome windows:))
delete C:\Users\[USERNAME]\AppData\Local\Google\Chrome\User Data\Default\Visited Links binary
you can define a function in your shell profile to perform this fast and just by a command whenever you face this issue: e.g:
function respectHosts () {
$path = $HOME + "\AppData\Local\Google\Chrome\User Data\Default\Visited Links";
Remove-Item $path;
}
important Note:
it is suggested that first time after deleting Visited Links binary file, also delete your history cause if you use a url from history, actually you are using the cached dns of that url too:
Running Chrome 105 on Windows 11, nothing seemed to work until I added ::1 (i.e. ipv6) in addition to 127.0.0.1. For example:
127.0.0.1 local.foo.com
::1 local.foo.com
While it was stated that no proxy is being used, I have had the same issue on OS X while using a proxy and the eventual solution was to add a proxy-exception for this domain.
What the OP could try is turn off async DNS via command-line switch as
mentioned here in 2015:
Async DNS: Remove toggle from about:flags
Async DNS is fairly stable at the moment, so we don't really need the
toggle in about:flags anymore. (Note that the --enable-async-dns and
--disable-async-dns command-line flags will still work for now.)
This, however, seems to have no effect in my case, as chrome://net-internals/#dns still displays the internal DNS-client as enabled with no obvious way to turn it off.
Had a similar issue working from a windows based server that had proxy settings. In the proxy advanced settings there are 2 options that can help. Ignore proxy setting for local hosts which is a check box; as well as a list of addresses set off my semi-colons where you can except out certain IP destinations. This fixed my issue.
For me
chrome://net-internals/#sockets
Flush socket pools work wonder, credit: https://superuser.com/a/611712
Chrome has a really awesome feature that allows you to open the dev tools from another browser or window. It works by starting chrome with this flag:
--remote-debugging-port=9222
Then from another window/browser you can go to http://localhost:9222 and open dev tools for any running tab in Chrome. For security reasons Chrome will not allow access from another machine by IP, lets say http://192.168.1.2:9222.
However there is an additional flag that indicates it opens this ability, here is what Chrome has to say for it:
--remote-debugging-address
Use the given address instead of the default loopback for accepting
remote debugging connections. Should be used together with
--remote-debugging-port. Note that the remote debugging protocol does not perform any authentication, so exposing it too widely can be a
security risk.
Either it's not working or I have no idea how to format it. I have tried the following:
--remote-debugging-port=9222 --remote-debugging-address=http://192.168.1.2:9222
--remote-debugging-port=9222 --remote-debugging-address=http://192.168.1.2
--remote-debugging-port=9222 --remote-debugging-address=192.168.1.2:9222
--remote-debugging-port=9222 --remote-debugging-address=192.168.1.3 //maybe thinking its supposed to be the IP of the remote machine
The target machine a Mac
it turned out, that the option "--remote-debugging-address" can only be used for the headless mode ("--headless") and is intended to be used for tests when the browser runs in a docker container and not for remote debugging.
The parameter of "remote-debugging-address" must be the numeric ip-adress of a local network interface of the machine where you start Chrome with "--remote-debugging-address".
When using any non-local ip-address you will get the following errors:
[0526/132024.480654:ERROR:socket_posix.cc(137)] bind() returned an error, errno=49: Can't assign requested address
[0526/132024.480766:ERROR:devtools_http_handler.cc(226)] Cannot start http server for devtools. Stop devtools.
On my Mac I can start the Chrome Canary version from today using this command line (the current stable version just crashes with "--headless"):
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --remote-debugging-port=9222 --remote-debugging-address=192.168.1.20 --headless
In another shell you can see, that this address is used to listen on the socket:
netstat -a -n | grep 9222
tcp4 0 0 192.168.1.20.9222 *.* LISTEN
Without "--headless" the output will look like this:
tcp4 0 0 127.0.0.1.9222 *.* LISTEN
Michael
--remote-debugging-address is semantically different from chromedriver's --whitelisted-ips
The remote debugging address must specify the address to bind to. So what you want in there is your machine's IP address not the address you will be connecting from. Try binding to all interfaces with --remote-debugging-address=0.0.0.0
Try create a HTTP-proxy in your target machine.
httpProxy
.createServer({
target: wsurl,
ws: true,
localAddress: host
})
.listen(port);
works for me.
I'm using Chrome in a Docker container (published by SeleniumHQ) to run automated tests in the Cloud. This runs a minimal display environment on XVFB that you can VNC into to see results.
Now we're using this within a Corporate firewall - and so external requests need to go through a proxy. We're setting the proxy with the Selenium proxy command.
Now we've run a test on the command line with curl on the Chrome docker container and curl with the proxy can access external resources just fine. But Chrome has an unknown problem accessing external resources (internal are fine). When we try and look at the settings, it is locked out. (Something about not being about the render the settings on xvfb).
So I'm looking for a way to look at the settings similar to Firefox's about:config. Now obviously this doesn't work on Chrome, but there appear to be some similar things.
There appear to be some details on URLs to use here.
They suggest:
chrome://net-internals/proxyservice#events
chrome://net-internals/proxyservice.config#events
chrome://net-internals/proxyservice.init_log#events
chrome://net-internals/proxyservice.bad_proxies#events
My question is: How to view Chrome settings on XVFB?
One way to see the current preferences is to open the file scoped_dir5752_14079\Default\Preferences in the temporary folder once the session is started.
And for a list and description of the preferences :
https://chromium.googlesource.com/chromium/src/+/master/chrome/common/pref_names.cc