Commit 59f3cc7b authored by Tails developers's avatar Tails developers
Browse files

Formatting.

parent 8f52aa86
[bastardising the links to dodge the stupid blogspam bot]
The page at [[contribute/design/I2P]] describes a regexp:
The page at tails.boum.org/contribute/design/I2P/ describes a regexp:
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>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 regexps, so what that regexp actually means is:
According to the FoxyProxy regex documentation (http://getfoxyproxy.org/patterns.html), FoxyProxy uses ECMAScript-compatible regexps, so what that regexp 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(/.*)?$
^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
http://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.
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
http://example.com/maliciousscript.php?localhost:7657
3) Added the final $ anchor, without which the final (/.*)? became meaningless.
Failing to change this means that URLs like the following would match:
h t t p ://localhost:76579
http://localhost:76579
or
h t t p ://localhost:7657?something=bad
http://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 regexps on that page.
^https?://[^/]+\.i2p(:[0-9]{1,5})?(/.*)?
`^https?://[^/]+\.i2p(:[0-9]{1,5})?(/.*)?`
Well, the following would match:
h t t p ://malicious.example.com?.i2p
http://malicious.example.com?.i2p
That is, a regular .com site could 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})?(/.*)?$
^https?://[-a-zA-Z0-9.]+\.i2p(:[0-9]{1,5})?(/.*)?$
Here, I've made a white-list for the domain name, instead of a blacklist; and again, I've added the terminating $ anchor so that the (/.*)? is meaningful.
Here, I've made a white-list 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.
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 regexp looks fine to me.
http://tails.boum.org/todo/FTP_in_Iceweasel/ describes some more regexps. Let's check them, too.
[[todo/FTP_in_Iceweasel]] describes some more regexps. Let's check them, too.
ftp://.*
`ftp://.*`
http(s)?://.*
`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:
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://
`^ftp://`
^https?://
`^https?://`
Finally, there's:
http://[a-zA-Z0-9\.]*\.i2p(/.*)?
Finally, there's: `http://[a-zA-Z0-9\.]*\.i2p(/.*)?`
That's better than the last .i2p regexp, 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})?(/.*)?$
^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.
......
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