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:

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.