Tiny Tiny RSS: Community

Open Redirect via public.php


#1

Hi,

I have a tt-rss instance on a subdomain of my domain for which I run a (no-payout) bug bounty program, so people can report security issues on my webpages via the Hackerone plattform.

I got a report that the tt-rss instance has an open redirect, i.e. someone can create an URL on it that will redirect to any arbitrary external URL:

Example:
Take a publicly accessible tt-rss instance and append this to the hostname:

/public.php?return=http%3a%2f%2fevil.com%2f&op=login&login=password=&profile=0

Whether open redirects should be considered security vulnerabilities is somewhat controversial, but it looks unintended and probably something that should be fixed.


#2

why would you consider this a security issue? please elaborate.


#3

Phishing


#4

The most obvious scenario is phishing.

Imagine you have a trusted domain example dot com from company Example. I.e. “trusted” in a sense that Customers of Example know that “example dot com” is their domain and believe they can trust the services running there.

Company “Example” - for whatever reason - runs tt-rss on a subdomain and now a malicious person can construct an URL pointing to the trusted domain, but actually redirecting to a malicious phishing page that’s trying to trick the user into giving username and password to them.

I can’t include links in my post, but google for “Open redirect URLs: Is your site being abused?” and you can find a blogpost by Google discussing this in more detail.


#5

Personally, I don’t just click random links. :man_shrugging:

Nevertheless, I’m going to guess most people are running a private instance of TT-RSS; they should therefore be suspect of any link they receive pointing to their own domain that they, themselves, didn’t send… I know I would.

That being said, the user is always the weakest link. I think there probably should be a check that the return URL begins with SELF_URL.

e: Do keep in mind that for something like this to actually be malicious, there has to be several breakdowns: The final site needs to be able to execute an exploit without user interaction, which requires an exploit at the browser and/or operating system level. Otherwise the user’s just going to see they’re not where their supposed to be and close the window… Assuming existing checks (like Google’s Safe Browsing stuff) doesn’t catch it first.


#6

the security issue in this scenario is strictly between the ears of whoever is dumb enough (and you need to be really dumb) to be phished.

that aside, since tt-rss only needs relative URLs in this situation, we might as well enforce it: https://git.tt-rss.org/fox/tt-rss/commit/c68ac04020d85a296c784de18f8def3f365f9f6a


#7

Typical Fox. From denial to acceptance:

  1. It’s not an issue.
  2. It’s an issue but only for morons.
  3. It’s an issue for morons but I’ll fix it.

:wink:


#8

i wish morons didn’t use tt-rss but we all know i’ts an impossible dream :face_with_raised_eyebrow:


#9

I am not sure if you are interested but the fix can be bypassed using for example ?return=\\evil.com&..


#10

Confirmed.

Though I sort of feel this is an issue with PHP’s parse_url() because it should identify the domain at the front of the URL.

Regardless, maybe the best thing is to ensure SELF_URL is at the front of the return address? The alternive would probably be crazy regex to match domains or strip leading characters.

Even filter_var doesn’t work because \ is an allowed character for FILTER_SANITIZE_URL.


#11

this way we’ll need to use absolute URLs everywhere instead of relative, which is just boring

maybe i should just revert this and let feeble-minded dimwits suffer the dreaded redirect, you can’t fight stupid with technical means anyway

e: reverted, if someone cares about this, post a PR. difficulty - no bloat, minimum lines of code.


#12

This seriously needs to be made into a poster. :laughing:


#13

You know, that kinda describe someone changing their mind when they think about a subject in more details. Sure, the first gut reaction is “this is bullshit” then “actually, maybe there’s something in this” and finally followed by “Well, yeah, kinda a problem”. I sincerely wish more people had the intelligence to actually do that.


#14

Another danger is DDoS. If the dimwits’ tt-rss instances get recruited into a botnet, the application in general will earn a bad reputation.


#15

in order to get redirected you need to login successfully first

unless thousands of people donate their tt-rss credentials to the attacker i don’t really see this happening

e: actually no, return is handled even if login is unsuccessful. oh well.


#16

But it’s not like it could be used in an amplification attack. It’s still a one-for-one hit (using the TT-RSS instance versus hitting the target directly). Also, TT-RSS runs on PHP, I’m pretty sure most people’s TT-RSS server will die before the target because PHP.

e: Right, I guess we could sort of amplify if we had multiple credentials but again, PHP itself kinda sucks and there are so many easier ways to DDOS someone, so…


#17

you could do an amplification attack because you could use many tt-rss instances to ddos one target, it would be terribly inefficient though


#18

you can file this as a win by attrition

hopefully i won’t hear anything about this non-issue of a non-security fucking non-problem ever again


#19

Um… I haven’t tried this, but you’re using HTTP_HOST, which is client-defined. If the site only has one virtual host it will be the default and therefore still load TT-RSS but with the client-defined HTTP_HOST value.


#20

we can use server_name i guess :face_with_raised_eyebrow:

even though i imagine properly configured server won’t respond to requests with random Host: (?)

also we’re comparing with SELF_URL_PATH which is fixed so even if HTTP_HOST is some garbage value redirect won’t happen anyway - unless i’m missing something

btw this would also mean that skipping self url path checks might break logins to auxiliary pages like sharepopup dialog but i’m ok with it