oh boy here we go again, and again, and again
Oops, I’ve fallen into the trap. I’ll go fix my other problem first… Sorry to have bothered you.
I believe this change has broken my ability to use non-default ports ie. whatever.tld:3000/feed
Dang! Just came here to type about this issue as well! In my case…
Back story. In addition to tt-rss I run rss-bridge both served to the internet on a non-standard port. Recently notice that the feeds I subscribe to in tt-rss from my rss-bridge were failing. I finally determined this was because of the non-standard port issue. The commit that started this issue is this one:
https://git.tt-rss.org/fox/tt-rss/commit/aa89ea77690b954a6739ee4ec5227c4d369202d3
At present reverting back to tt-rss commit: 6c02fea64 fixes the issue.
.
PLEASE READ THIS BEFORE POSTING:
Describe the problem you’re having:
Since recent updates, cannot open external pages when clicking on article title. It ends with message {“error”:{“code”:13,“message”:null}}
If possible include steps to reproduce the problem:
Open article by clicking on title, ends on page backend.php with message {“error”:{“code”:13,“message”:null}}
tt-rss version (including git commit id):
Tiny Tiny RSS v20.09-88c4dc405
Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:
PHP Version 7.2.24-0ubuntu0.18.04.6
Please provide any additional information below:
…
there are multiple reasons to not allow this, even as a hidden tweakable. why not use a separate subdomain instead?
its impressive how you managed to not read anything before posting here. congratulations.
e: well, we went through non-standard ports and explicitly misconfigured origin URL already, i hope scheme whitelist is next. was anyone here subscribing to feeds via gopher or ftp?
also,
you’re not passing X-Forwarded-Proto properly to the container.
since skip url path checks leads to hard to diagnose issues such as above. should it stay? if it should stay, what if tt-rss generates a single warning on login mentioning wrong origin address potentially leading to various issues?
also,
doing this is a bad idea, unless you’re only staying while migrating away from your setup.
https://git.tt-rss.org/fox/tt-rss/commit/da5af2fae091041cca27b24b6f0e69e4a6d0dc60
etc
there are multiple reasons to not allow this, even as a hidden tweakable. why not use a separate subdomain instead?
I ended up using nginx to do this, but I’d prefer not having to do that. In my situation is was an easy change because it’s internal-only, but I could imagine a world where a third party could be running on a non-standard port. I understand there are security implications to this, but it should be an optional restriction for those who need non-standard port functionality.
an optional restriction is really not a restriction at all, i think.
main problem is services bound to loopback. tt-rss proxy opening access to fpm daemon or whatever else you might have “safely” bound to ::1 is bad news.
unfortunately, it’s somewhat hard to definitely prevent all connections to loopback specifically so we also filter by “safe” ports. this does break external services on nonstandard ports, yes, but in my opinion in this particular situation it is worth it.
luckily, in the year of our lord 2020, an absolute minority uses anything but regular https, if only because browser vendors push it so hard and whine at everything else.
i’m going to go as far as saying that at this point any web-related service in production on a random nonstandard port might be considered questionable simply because of it.
also,
well, the code is open, you can change whatever you like. as long as you understand the consequences, one of those being that i’m not going to feel responsible if you get owned.
i don’t particularly like this “forbid everything aaaa” thing but in a world where some imbecile decided that adding fucking javascript to a vector image was a good idea, and nobody told him to go jump off a cliff instead of implementing this whole cancerous abortion into web browsers, can we really afford to do something else? 
FYI, my post got merged into this thread. I had created one thread on its on. How could I have then read all this?
yes, imagine reading a bunch of recent posts before enriching us with a new thread. unthinkable, really.
Thanks for pointing me in the right direction. Correcting this fixed the issue.
I also use a non-standard port. There really shouldn’t be an issue of leaving non-standard ports and it adds no real risks. I’d ask you leave this capability as a “:port” is a completely valid part of a URL and shouldn’t be disallowed. I am also one who think relative is fine, although I don’t use. There are no security issues with this and is someone is worried they can just not set that up in their tt-rss config. Fox can fix stuff that relates to CVEs but he can’t prevent idiots from shooting themselves in the foot by misconfiguring their servers, using admin/123456 as username/password and other stupid stuff. If you don’t have some modicum of real technical knowledge you shouldn’t be trying to run a web server.
tt-rss serving as a web proxy for services on random ports, internal or otherwise, absolutely does add risks.
I would prefer to keep validation consistent for all URLs instead of adding special handling for SELF_URL_PATH specifically to minimize confusion and potential for further exploits.
especially if the goal here is running stuff on http://myserver:1234. this kinda setups went out of fashion a decade ago.
I’m just going to comment out the loopback check. Using public IP addresses has it’s own set of security implications that are more concerning than allowing my private single-user instance to loopback on itself.
actually, no. it works kinda like this:
your private instance → XSS from feed data or w/e → your local service bound to localhost is potentially exposed → your LAN is also exposed
good luck
Fox, you will as always do what you think makes sense/is right. I just point out that a “valid URL” includes a port number, and people have reasons for this use case. for example, if your ISP blocks incoming traffic on specific ports or other limits/monitoring you might want to use an alternative. yes, the ISP are jerks but many folks don’t have a choice and have only a single broadband carrier choice.
well, that much is obvious. valid in this situation is more like “we’re reasonably certain that we won’t be screwed over if we try to fetch and show data from this URL or even simply show it to the user”
don’t get me started on a recent bunch of changes that deals with redirects.
I use uMatrix for a reason, anyone running a browser that just executes any JavaScript handed to it has way bigger issues than loopback connections. I wouldn’t be using tt-rss at all for security reasons without uMatrix.
tt-rss doesn’t work without javascript so you’d have this origin whitelisted. successful XSS via tt-rss and you’re screwed.