New issue
Advanced search Search tips

Issue 710832 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

shExpMatch not matching correctly in a PAC script

Project Member Reported by pastarmovj@chromium.org, Apr 12 2017

Issue description

I'm using Chrome latest version on Windows 7.
And set proxy.pac stored local IIS (http://127.0.0.1/proxy.pac) which can access using anonymous auth.

proxy.pac file is written as follows:
---------------------------------------------------------------------------------------------
 function FindProxyForURL(url, host) {
 
	if (shExpMatch(url, "https://www.microsoft.com/ja-jp*"))
	{
        	return "PROXY 1.2.3.4:8080";
	}
	else
	{	
		return "DIRECT";
	}
 
}
---------------------------------------------------------------------------------------------

[My expected result]
  https://www.microsoft.com/ja-jp   : access block (ERR_PROXY_CONNECTION_FAILED)
  https://www.microsoft.com/en-us   : accessible

[Result on IE11]
  https://www.microsoft.com/ja-jp   : access block (proxy server not responding)
  https://www.microsoft.com/en-us   : accessible

[Result on Chrome]
  https://www.microsoft.com/ja-jp   : accessible ...Not as expected
  https://www.microsoft.com/en-us   : accessible

Does anyone who know the causes and resolution way for this issue?
Are wildcards of sub-domains not recognized effectively on Chrome such as "/ja-jp*"??
 

Comment 1 by mmenke@chromium.org, Apr 13 2017

Cc: eroman@chromium.org mmenke@chromium.org
Components: Blink>JavaScript
So the function declaration is as follows:

function shExpMatch(url, pattern) {
   pattern = pattern.replace(/\\./g, '\\\\.');
   pattern = pattern.replace(/\\*/g, '.*');
   pattern = pattern.replace(/\\?/g, '.');
   var newRe = new RegExp('^'+pattern+'$');
   return newRe.test(url);
}

Running "https://www.microsoft.com/ja-jp".replace(/\\?/g, '.'); in the console gives me:  ".h.t.t.p.s.:././.w.w.w...m.i.c.r.o.s.o.f.t...c.o.m./.j.a.-.j.p." (And running it after the second substitution is even uglier, just simpler to focus on the third).

So the last replacement is wrong.  Unclear if this is a V8 bug or a bug in the PAC code, though I'd lead towards a v8 issue, since presumably it should be replacing ?'s with .'s, as the ? is escaped.

Comment 2 by mmenke@chromium.org, Apr 13 2017

Labels: -Pri-2 Pri-1
Actually, the second one looks wrong, too..."https://www.microsoft.com/ja-jp".replace(/\\*/g, '.*'); is giving us:  ".*h.*t.*t.*p.*s.*:.*/.*/.*w.*w.*w.*..*m.*i.*c.*r.*o.*s.*o.*f.*t.*..*c.*o.*m.*/.*j.*a.*-.*j.*p.*"

We do have tests for shExpMatch, which do seem to be passing, curiously.

Comment 3 by mmenke@chromium.org, Apr 13 2017

Components: -Blink>JavaScript
Labels: -Pri-1 Pri-2
Oops, I forgot that the string appeared in C code...correctly unescaping it and running the js in the console, shExpMatch seems to be working as expected, and shExpMatch("https://www.microsoft.com/ja-jp", "https://www.microsoft.com/ja-jp*"); is returning true.  Hrm...

Comment 4 by mmenke@chromium.org, Apr 13 2017

Oh, the issue here is that we no longer send full HTTPS URLs to PAC scripts - we only send the origin.  This is so that a hostile PAC script can't steal securely accessed URLs.

Comment 5 by mmenke@chromium.org, Apr 13 2017

Status: WontFix (was: Untriaged)
Since this is a privacy feature and an expected behavior, WontFixing this.   Issue 593759  caused the change in behavior.

Sign in to add a comment