News: cURL issues

[Grotax]

As a followup of #412 this issue will keep track of issues related to cURL.
If you find different curl issues you might post them below, please no "same" messages.

• cURL error 3: Illegal port number

https://$USER:[email protected]/feed/everything
http://$USER:[email protected]/rss/politics
http://$USER:[email protected]/services/xml/rss/nyt/HomePage.xml

• More than 5 redirects

http://feeds.washingtonpost.com/rss/entertainment

[SMillerDev]

https://github.com/nextcloud/news/pull/420 will fix the username issues as soon as I get it working. More than 5 redirects seems more like an upstream issue.

[chr4]

I've experienced the same issue and I recognized my Nextcloud account username/ password showing up in those error messages.

Which makes me wonder: Could this lead to compromised passwords? If the request would succeed, the receiving feed service could catch the credentials, couldn't it? At least in my case, there's no username and password required for the feed and none configured.

[chr4]

After some digging: The password was indeed set in the database basic_auth_password field. I'm not sure how it got there, as I haven't updated the feed since ages and the last_modified field roughly fits to the News app update?

Sorry for the guesswork, but I'm leaving this here in case someone else experiences the same thing. I'm a little worried that my passwords might be compromised - I guess I better change them.

[Grotax]

Hey @chr4 there seems to be a heavy misunderstanding. The username and password in this context are for basic http authentication notice the syntax:
http(s)://$username:[email protected]/path
These of course need to be stored in the database otherwise the server couldn't fetch feeds that require authentication. If your feed doesn't require authentication no password/username is stored.

You wrote about leaking to the feed service, which confuses me. What service do you mean? You, the admins of your server and the hoster of the feed all know the credentials but that's to be expected. They should however not be related to your nextcloud credentials.

[heyarne]

You wrote about leaking to the feed service, which confuses me. What service do you mean?

@Grotax I opened an issue on hackerone for this as I see this as a serious vulnerability, so even though I'm not @chr4 I'll answer here:
The username and password that show up in these requests are not the username and password required to view the feed. They are the username and password used to access the nextcloud instance and they are consistent across several feeds. I have no idea how an unencrypted password could even get there to be honest.

[SMillerDev]

Are you sure you're not using a password manager that filled out the username and password for the current website (nextcloud) when setting up the feed? News has absolutely no idea how you are authenticated in nextcloud, it just uses a user ID.

[Grotax]

So I tried to reproduce the "nextcloud password" but I can't, neither my test server nor my actual server have credentials in the db.
I also added a feed with http auth but I couldn't find my password in the logs.

[chr4]

@SMillerDev this might very well be a possibility. It only affected one feed - maybe my password was leaking because of this for a while and I just noticed because of this bug...

I suppose that the app should somehow ensure that the basic auth fields are not automatically filled by a password manager (not sure how they differentiate, maybe with unique HTML IDs?

@heyarne Thanks for taking this seriously, even though it might have been coming from a different angle!

[heyarne]

Are you sure you're not using a password manager that filled out the username and password for the current website (nextcloud) when setting up the feed?

I am not and since I subscribed to these feeds a while ago it's hard for me to reproduce. I described this in greater detail in the report that I opened on hackerone.

The password manager I use is PassFF (maybe @chr4 uses that as well?); I changed my Nextcloud password and the old password is still showing up. I can't find any element in the GUI to clear my password, how would I do this? Un- and resubscribe?

[chr4]

I'm using Firefox, but without the pass integration. So this might be Firefox related.

I guess un- and resubscribing would work, I've cleared mine using psql (which also makes sure there's no other feed with credentials):

-- Look for feeds with basic auth password set
SELECT * FROM oc_news_feeds WHERE basic_auth_password != '';

-- Delete credentials for a feed
UPDATE oc_news_feeds SET basic_auth_user='', basic_auth_password='' WHERE id=$FEED_ID;

-- Alternatively delete all credentials
UPDATE oc_news_feeds SET basic_auth_user='', basic_auth_password='';

[Grotax]

There was already an attempt to prevent browsers from auto-filling
https://github.com/nextcloud/news/blob/master/CHANGELOG.md#security
https://github.com/nextcloud/news/commit/66c8819283e7088a508bdd07e2d1693f3757d42b

But apparently browser don't really care and if that's the case why should extensions/plugins?
https://gist.github.com/runspired/b9fdf1fa74fc9fb4554418dea35718fe

There seems not to be a proper solution to this problem.

[Grotax]

I will close this as #420 should fix the first Problem and #435 will track the redirect thing.

If you have a solution to prevent the auto-fill for all systems feel free to create a PR.

[chr4]

One thing to add (might be not related to news at all): When opening up the news app on my instance, Firefox asks for the master password, even though I'm logged in already and there's no input password field visible.

My guess would be, that there's some field that might be prefilled by the password manager, therefore it asks for the password. Maybe that helps somehow.

As a workaround, I've removed my Nextcloud password from the password manager in the meantime, just to be sure.

[Grotax]

Well thats exactly the issue.
News supports authenticated feeds. So there is a button to expand the "add a new feed" box.
If expanded you will find a username and password field.

The password field is already labeld as "please do not auto-fill" but Firefox's answer to that would be ¯_ (ツ) _/¯.

There are some crude ways to prevent that, which will lead to other problems.

Maybe this can be fixed with a new Frontend and more modern library's that prevent this somehow.

[heyarne]

From what I can tell those two fields, username and password, are hidden via ng-if unless explicitly requests, which makes sense because the vast majority of feeds do not require authentication. I double-checked and they do not seem to be present in the DOM - how did the password get autofilled into fields that are not present in the DOM?

[Grotax]

Maybe preloading by the browser in case you actually open it? Which would be stupid but so is not following standards which browsers tend to do all the time. My advise would be to change your password manager.

[heyarne]

I opened an issue in the other repository in the hope of finding out how this happened. I'm not sure this is specific to a password manager but may be a broader problem. Shouldn't it at least be indicated to the user that they have entered a password that will be transferred to third parties? You could for example always show the password field if it is filled an clearly mark it as being filled with potentially sensitive information. You could also highlight the feeds that use authentication in the sidebar.

I understand you don't want to write software that deals with every possible misconfiguration in the world, but you yourself are talking about browsers not adhering to standards etc. I consider myself to be quite tech-savvy and it took me quite a while to figure this out. There are possibly many other users that have not yet figured this out.

[Grotax]

I would be OK with a solution that doesn't violate any common rules. The problem there is that we don't have enough people dealing with the frontend.

If you want you can take a look at this and open a PR. Or open a issue with a sensible solution to this problem. But for that to be implemented could take several months depending on how long it takes until we find someone that is capable of fixing our frontend that has multiple issues.