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:
Whether open redirects should be considered security vulnerabilities is somewhat controversial, but it looks unintended and probably something that should be fixed.
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.
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.
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.
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.
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…
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.
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
