Commit d706b4bf authored by 127.0.0.1's avatar 127.0.0.1 Committed by amnesia
Browse files

No commit message

No commit message
parent 649d7263
[bastardising the links to dodge the stupid blogspam bot]
h t t p ://tails.boum.org/contribute/design/I2P/
...describes a regex:
<blockquote>urls matching ^http://(127.0.0.1)|(localhost):7657(/.*)? will get a direct connection to the local host so the I2P router console can be reached.</blockquote>
According to the FoxyProxy regex documentation (h t t p ://getfoxyproxy.org/patterns.html):
FoxyProxy uses EcmaScript-compatible regexes, so what that regex actually means is:
Any URL beginning "http://127[any char]0[any char]0[any char]1" OR any URI containing the string "localhost:7657" anywhere within it, will evade the proxy.
It's probably meant to be:
^http://(127\.0\.0\.1|localhost):7657(/.*)?$
Specifically, the changes here are:
1) we escape the wildcard dot characters to accept only a literal dot.
Failing to change this means that a URL like the following would match:
h t t p ://127x0y0z1/maliciousscript.php:7657
So, a machine named 127x0y0z1 on the same LAN could be accessed without the proxy. Not that machine names should begin with numbers, but still...
1a) You might also want to consider using (?:blah1|blah2) instead of (blah1|blah2) for performance reasons, unless you actually need to capture blah1 or blah2 for later use. But that's not a security thing, may make no difference, and may reduce readability/maintainability.
2) We place the "or" character inside the braces, where it separates only the halves of the braced clause, rather than having it separate the entire URL in two.
Failing to change this means that a URL like the following would match:
h t t p ://example.com/maliciousscript.php?localhost:7657
3) Added the final $ anchor, without which the final (/.*)? became meaningless.
Failing to change this means that a URL like the following would match:
h t t p ://localhost:76579
h t t p ://localhost:7657?something=bad
Not a terrible risk, but who can tell what's running on port 76579? So if you want to guarantee anything following the port number is separated by a slash, you need that anchor.
While we're at it, let's look at the other regexes on that page.
^https?://[^/]+\.i2p(:[0-9]{1,5})?(/.*)?
Well, the following would match:
h t t p ://malicious.example.com?.i2p
That is, a regular .com site would be sent through the .i2p filter. No idea if that could be exploited, but let's fix that up anyway.
^https?://[-a-zA-Z0-9.]+\.i2p(:[0-9]{1,5})?(/.*)?$
Here, I've made a whitelist for the domain name, instead of a blacklist; and again, I've added the terminating $ anchor so that the (/.*)? is meaningful.
Again, the brackets (blah) should probably be non-capturing brackets, like (?:blah) for speed, but this reduces readability and maintainability, so I didn't include it above.
The third regex looks fine to me.
http://tails.boum.org/todo/FTP_in_Iceweasel/ describes some more regexes. Let's check them, too.
ftp://.*
http(s)?://.*
These both need an anchor ^ at the beginning, and the ending .* seems pointless, since there's no end anchor. Also, the brackets: they do nothing. I'd replace these with:
^ftp://
^https?://
Finally, there's:
http://[a-zA-Z0-9\.]*\.i2p(/.*)?
That's better than the last .i2p regex, but you don't need to escape a dot if it's in a group; domain names can include dashes, too; you need to deal with alternative port numbers; and you need beginning and ending anchors. So the version listed earlier is probably a better choice:
^https?://[-a-zA-Z0-9.]+\.i2p(:[0-9]{1,5})?(/.*)?$
Of course, that still allows requests for invalid names like "http://...---...i2p:00000" but I assume that's OK and perfectly secure, so long as no valid non-.i2p addresses match.
Many apologies if my English is unclear: please feel free to ask for clarification on any points.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment