Wildcard patterns should match the whole URI

[randomstuff]

The documentation about wildcard URI patterns suggests using wildcards such as:

• *.yahoo.com/* (with the comment "Everything in Yahoo’s domain")
• http://digg.com/

However, the following rule matches with any URI containing .yahoo.com/ and http://digg.com/ respectively. This includes for example:

https://www.example.com/?.yahoo.com/
https://www.example.com/?redirect_uri=https://www.yahoo.com/
https://www.example.com/?http://digg.com/
https://www.example.com/?redirect_uri=http://digg.com/

I believe that the the intent is that the pattern should match the whole URI string, not only a substring.

See for example the wildcard examples:

• *.yahoo.com/* is actually equivalent to .yahoo.com/;
• *mail.yahoo.com* is acutally equivalent to mail.yahoo.com
• *://*.asimov.???/* is actually equivalent to ://*.asimov.???/

See as well these examples from the Common Mistakes section:

Invalid	Valid
http://www.myspace.com	http://www.myspace.com/*
localhost, 127.0.0.1	Must be TWO patterns: *://localhost/* *://127.0.0.1/*
.abc.com	.abc.com/
eric.abc.com	eric.abc.com/

The valid examples are acutally not completely valid either.

Security impact

This might have a security impact. An attacker might attempt to exploit an existing wildcard rule in the user browser in order to attack unintended servers. For example, let's assume a user has configured a SSH dynamic proxy to an server in an internal network:

ssh -D9999 server.internal

Now the user configures, a wildcard rule to use this tunnel for accessing this server only:

• Type: SOCKS5
• Hostname: 127.0.0.1
• Port 9999
• Include: Include
• Rule Type: Wildcard
• Pattern: https://server.internal/*

An attacker could attempt to bypass this rule in order to access another internal server:

https://target.internal/?_=https://server.internal

This could be used to attack an internal server using CSRF or DNS rebinding attacks.

Documented wildcard patterns

Even if FoxyProxy is modified in order to match the whole URI when using a wildcard pattern, rules such as *.yahoo.com/* are dangerous because they can be abused using URIs such as:

https://www.example.com/?q=.yahoo.com/

Here is a summary of the suggested patterns in the documentation and whether they might have unintended behavior for the user:

Pattern	Status	Unexpectedly matching URL
*.yahoo.com/*	Problematic	https://www.example.com/?.yahoo.com/
*mail.yahoo.com*	Problematic	https://www.example.com/mail.yahoo.com
http://??.wikipedia.org/wiki/Clown	Mostly OK	http://x/.wikipedia.org/wiki/Clown
http://digg.com/	OK	https://www.example.com/?http://digg.com/
*://*.asimov.???/*	Problematic	https://www.example.com/?://.asimov.123/
*	OK
http://www.abc.com/foo.html	Problematic	https://www.example.com/?http://www.abc.com/foo.htm
http://www.myspace.com/*	OK	https://www.example.com/?http://www.abc.com/
*://localhost/*	Problematic	https://www.example.com/?://localhost/
*://127.0.0.1/*	Problematic	https://www.example.com/?://127.0.0.1/
*.abc.com/*	Problematic	https://www.example.com/?.abc.com/
*eric.abc.com/*	Problematic	https://www.example.com/?eric.abc.com/

Mitigations

• Only use regexp patterns.
• When using wilcard pattern, only use * after the path leading slash (https://www.example.com/*). This greatly limits the power of wildcard patterns however.

Resolution

• Match the whole string in wildcard patterns. This is consistent with the intended behavior according to the examples.
• Do not recommend wildcard patterns with * wildcards before the resource path in the documentation.
• Warn about wildcard patterns with * wildcards before the resource path in the documentation. Suggest using regexp patterns instead.
• Alternatively to the previous point, exclude many characters from * expansion. This is a breaking change however as many (documented) patterns would break.

[erosman]

The documentation about wildcard URI patterns suggests using wildcards such as:

Above documentation belongs to FoxyProxy version 6-7.
Please refer to the included Help for FoxyProxy version 8+.
A copy can also be found in this repo at Help.

[Gentran]

I also noticed this issue exist in Foxyproxy for Chrome. I try to proxy one whole url and the pattern tester passed but only the domain patterns will work.

[erosman]

I also noticed this issue exist in Foxyproxy for Chrome. I try to proxy one whole url and the pattern tester passed but only the domain patterns will work.

Please provide examples for testing.

[randomstuff]

Above documentation belongs to FoxyProxy version 6-7.

Ouch, I was not aware of that :)

Indeed the examples in the new documentation are more explicit about this behavior!

Type	Pattern	match	no-match
Wildcard	example example* *example *example*	http://help.example.com/ https://example.com/	https://google.com/ref=examplelist