Please have a Look in my txt file.
I have Elaborated the Issues.
Please follow back if you are not able to understand.
Thanks

Deleted: Google_Chrome_Reports.txt 2.0 KB

Google_Chrome_Reports.txt 2.0 KB View Download

mmenke: Can you take a look at this bug (or reassign if appropriate)? Looks like an issue with proxies that require authentication. Thanks!

This does not look like a security bug, since Chrome is just failing to request credentials for the Proxy the second time around, so removing restrictions and security tag.

No idea who owns the password saving logic, unfortunately.

This is definitely not expected behavior. If the password was saved, the browser should prompt the user with the credentials filled in instead of using saved passwords without user interaction.

Do you have any extensions installed that are managing passwords for you?

Hello ALL,

Now What is Happening is Chrome is Responding to the Proxy with A Proxy-Authorisation Header
Which is Wrong 
A scenario where 

A company with 50000 Users having an SWG [Authentication Required]
Now in this case
The User Won't be Prompted for any Kind of Authentication
and AS-PER SWG Rules
The Users who fail to Supply Correct Authentication in 3 Tries are Denied to use the Service

How will the users use the service.
and their Machine will be Permanently BANNED to use the Service.
This Replicates a Brute-force-Scenario


This is an Security ISSUE.

Thanks
Ashish R Bhandari

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hello  asanka@chromium.org,

I have not Installed any kind of Extensions in Google Chrome.
I have a New Machine with a New GOOGLE CHROME [version 69] INSTALLED.


I wanted to Clear Few Things


"This is definitely not expected behavior. If the password was saved, the browser should prompt the user with the credentials filled in instead of using saved passwords without user interaction."

The Above Line "in instead of using saved passwords"
Is not what is HAPPENING

Even if I SAVE OR I don't SAVE the Password.

Chrome is Goinf to Send 

Proxy-Authentication Header by itself
as 

Proxy-Authorization: Basic Og==
Og== --> Base64Encoded(":")


i.e Neither it is asking for any kind of Password
Nor it is using any Saved Passwords.

It is Just sending Blank Authentication 

Thanks,
Ashish R Bhandari

As PER,
My Knowledge
This is a BIG Security ISSUE

Could you give us a net-internals log from a new profile? Instructions for doing so can be found in https://dev.chromium.org/for-testers/providing-network-details  . You may need to go through the "Logging on startup" section since the problem seems to affect browsers after a restart.

The log would give us more information on where the headers were set and based on what. 

There doesn't seem to be a widespread issue Chrome making up proxy authentication credentials. This leads me to believe that there's something peculiar about your configuration that's causing this to happen.

Hello asanka@chromium.org,

I am sorry that I was not able to make you understand my scenario properly.

Let me Explain you what troubleshooting I have done and what i have discovered till now.

There is NO extra plugin,Add-on or any other things downloaded in my Google Chrome.

I have done this test in 10 Machines and the Output seems to be same.

Even you will face this ISSUE in CHROME's LATEST version.

TRY using a Proxy Server[Authentication ENABLED] ---> like FIDDLER HTTP DEBUGGING TOOL

LINK [TO SETUP FIDDLER WITH BASIC AUTHENTICATION] :--->   https://jegansblog.wordpress.com/2015/05/07/setup-fiddler-as-proxy-server-with-basic-authentication/

You can use FIDDLER or ANY OTHER PROXY SERVER that Supports AUTHENTICATION.

Use LATEST version of CHROME
1. Configure Proxy on CHROME 
2. When to try to search a website you will see Authentication Challenge Provide the Authentication.
3. Surf for a minute or 2
4. Close the Browser and Open it again 
5. What you will see in the PROXY SERVER's[FIDDLER or any OTHER PROXY that SUPPORTS AUTHENTICATION] LOG is
Automatic Proxy-Authorization Header being send to the PROXY Server

Please Update me with the status


Thanks and Regards,
Ashish R Bhandari

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hello asanka@chromium.org,

I am waiting for your Reply,
My Users are Facing alot of ISSUES while ACCESSING Internet.

Requesting you to kindly Check the ISSUE and UPDATE ME.

Hello asanka@chromium.org

As you can See I have ATTACHED the Image containing the Issue Details.
Kindly Revert BACK.

Deleted: FIDDLER_SHOWING_AUTO_SENDING_PROXY_AUTHENTICATION.PNG 101 KB

	FIDDLER_SHOWING_AUTO_SENDING_PROXY_AUTHENTICATION.PNG 101 KB View Download

Hello Chromium Team,
Why are You all NOT RESPONDING.

My CLIENTS are FACING ISSUES because of this.
Please REVERT BACK

Thanks,
Ashish R Bhandari

As mentioned in comment #9, Could you give us a net-internals log from a new profile? Instructions for doing so can be found in https://dev.chromium.org/for-testers/providing-network-details 

The reason why I'm asking for one is that such a log would give us insight into where the blank password is coming from. I'm not disagreeing with what you are seeing via Fiddler or otherwise. :-)

Hello asanka@chromium.org,

Okay I will Provide you with the Logs.
The Log File is Attached.
Please Update if you find that the LOGS are NOT PROPER.

Thanks
Ashish R Bhandari

Below is the LOG FILE

Deleted: chrome-net-export-log.json 842 KB

chrome-net-export-log.json 842 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hmm. Yeah. Looks like it's been around since Chrome 68. Let me see if we can do a bisect.

Hello asanka@chromium.org,

This ISSUE was REPORTED by ME for the VERSION 68.
and AFTER the UPDATE [i.e 69]

The PROBLEM STILL SEEMS to be the SAME

SO this is AN ISSUE RIGHT?

Thanks
Ashish R Bhandari

This appears to be a result of https://chromium-review.googlesource.com/c/chromium/src/+/1042825

Though the issue itself wasn't introduced there. SimpleURLLoader invokes AuthChallengeResponder::OnAuthCredentials() with an empty AuthCredentials object when the request doesn't have an associated WebContents. This is the case for GoogleURLTracker.

The code in network_service_client.cc:NetworkServiceClient::OnAuthRequired() which looks like:

  if (!web_contents_getter.Run()) {
    std::move(auth_challenge_responder)
        ->OnAuthCredentials(net::AuthCredentials());
    return;
  }

Should be:

  if (!web_contents_getter.Run()) {
    std::move(auth_challenge_responder)
        ->OnAuthCredentials(base::nullopt);  // <-- here
    return;
  }

Adjusting labels.

This issue:
* only affects requests created via SimpleURLLoader -- i.e. doesn't affect normal browsing.
* only affects HTTPS requests routed via an authenticated proxy.
* only affects proxies that don't use ambient authentication, or for which ambient authentication fails. Negotiate authentication isn't affected on non-Windows platforms. On Windows, negotiate authentication will fail with no tokens being sent out to the proxy server.
* has been there since M68, though it was a regression then.

I'm removing the RVST label because this doesn't endanger the user's security. It can create a bunch of log entries that might be concerning. But it seems this issue has only been reported here.

The fix is pretty small. We should be able to merge it to M70, but I don't think it warrants a stable merge.

Hello asanka@chromium.org,

May it be a small fix but the ERROR throughput is very high.
Understand the Situation,
Whenever I try to open Google Chrome , my swg shows me around 500 requests being processed, without my interaction, which is wrong ,
Seems like an abnormal behaviour.
We are security firm, we cannot allow people to enter wrong credentials too many time.
They are automatically blocked by our swg.

Seems like a big issue.

May the company size be 500 - 5000 .
It is messing up things.

This seems to be a big security issue.

Hello asanka@chromium.org,

As you have understood my Problem,
Can you Provide me Temporary Solution for this ISSUE, until the NEW GOOGLE CHROME Version is OUT.

Thanks,
Ashish R Bhandari

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5d2da02a711bc40ec41b8bd5b15a3bd20232aa5a

commit 5d2da02a711bc40ec41b8bd5b15a3bd20232aa5a
Author: Asanka Herath <asanka@chromium.org>
Date: Tue Oct 02 18:49:30 2018

Cancel credential request for authentication challenges with no UI.

If an authentication challenge is received by NetworkServiceClient --
implying that there were no cached credentials or ambient identity
around to respond to the challenge -- the authentication request should
be canceled. A typo resulted in this pending challenge being supplied an
empty username and password instead.

This condition applies to requests that are made in the absence of a
WebContents, and those made with an associated WebContents that went
away prior to the network service notified the client of the
authentication challenge.

Bug:  874790 
Change-Id: Ib3c866d1074b2a431a5196614ac3397bf97ea132
Reviewed-on: https://chromium-review.googlesource.com/1252868
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Matt Menke <mmenke@chromium.org>
Commit-Queue: Asanka Herath <asanka@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595930}
[modify] https://crrev.com/5d2da02a711bc40ec41b8bd5b15a3bd20232aa5a/content/browser/network_service_browsertest.cc
[modify] https://crrev.com/5d2da02a711bc40ec41b8bd5b15a3bd20232aa5a/content/browser/network_service_client.cc

OP: Could you verify whether 71.0.3569.0 addresses your issue? This is today's Canary and includes the fix.

aashish.bhandari97: Ping? Could you verify the fix on Canary?

In the meantime, I'll queue this up for merge consideration for M70. This has baked in Canary for a couple of cycles with no adverse effects. The only functional change is the expression in network_service_client.cc [1].

[1]: https://chromium.googlesource.com/chromium/src.git/+/5d2da02a711bc40ec41b8bd5b15a3bd20232aa5a%5E%21/#F1

This bug requires manual review: We are only 11 days from stable.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is this fully behind the network servicification flag?

No.  Most browser-side consumers of URLRequests use this path in production, regardless of whether the network service is enabled or not.

Why is this critical for M70? My recommendation is to target M71, since this has been present since M68. 

Since this is present since M68, rejecting merge for M70. Let's target M71. 

Checked on Google Chrome:71.0.3572.0 Platform:11141.0.0 pantheon
Attached logs and screenshot. Please confirm if this is expected as per the fix.

Deleted: Screenshot 2018-10-10 at 10.00.12 AM.png 329 KB

	Screenshot 2018-10-10 at 10.00.12 AM.png 329 KB View Download

Deleted: debug-logs_20181010-100227.tgz 575 KB

debug-logs_20181010-100227.tgz 575 KB Download

 Issue 900850  has been merged into this issue.

#38: Close :-)

To reproduce the issue you need an authenticating proxy that uses an auth scheme that accepts explicit credentials (like "Basic" that you are using here, correctly). But don't login or provide credentials for the proxy. Instead type something in the omnibox.

This should result in some traffic generated by Chrome under the system request context that should fail. The activity we are interested won't show up in a 'network' tab of developer tools since they aren't made in the context of a renderer. Instead the requests need to be captured as a network log as described in #16.

FLipping back to "Fixed" in order to indicate the current state of the bug.

Re-requesting merge per offline conversation.

Closing the issue for now as per #41, Please re-open if the issue persists at users end. 

... and after further discussion, pushing this to M71.

Unfortunately affected parties will see spurious authentication errors. There could be a very large number of these to the tune of several hundred per day per client machine. This will stop as M71 rolls out in about a month or so.

However this failure mode does not prevent legitimate requests from failing. I.e. the effects would be observable to whomever is looking at proxy authentication errors, but not to normal users.