Last modified: 2010-05-15 15:59:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T15107, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 13107 - Security hole through RSS/Atom feeds of Recentchanges
Security hole through RSS/Atom feeds of Recentchanges
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.11.x
All All
: Highest critical (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-22 12:14 UTC by Palaniappan Chellappan
Modified: 2010-05-15 15:59 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
The IRC conversation about this bug (43.49 KB, application/xml)
2008-02-22 12:59 UTC, Palaniappan Chellappan
Details
Human readable version of the same IRC log (15.01 KB, text/plain)
2008-02-25 02:45 UTC, Tim Starling
Details

Description Palaniappan Chellappan 2008-02-22 12:14:22 UTC
There is a security hole that allows parts of a read-protected ($wgGroupPermissions['*']['read'] = false;) wiki's content to be accessed by anyone. Through the RSS/Atom feeds of Special:Recentchanges. The feed isn't password protected.

The feed's URL for any wiki can be figured out easily by anyone with a couple of days' experience with MediaWiki.

A temporary workaround for this problem is to set the feed limit to 0, as suggested by Hojjat in #mediawiki.

I think you should put up an alert on the front page (mediawiki.org), and warn people of this problem, and suggest the temporary solution.

Thank you.
Comment 1 Huji 2008-02-22 12:43:07 UTC
With r31184, I provided a way for wiki admins to turn off the syndication feeds totally, when they desire. My knowledge of syndication feeds is limitted but if there is no standard way to authenticate inside feed readers, then I think the only solution available is to turn them off when there are good reasons (such as when read permission is restricted).
Comment 2 Palaniappan Chellappan 2008-02-22 12:59:18 UTC
Created attachment 4663 [details]
The IRC conversation about this bug
Comment 3 Tim Starling 2008-02-25 02:45:00 UTC
Created attachment 4675 [details]
Human readable version of the same IRC log
Comment 4 X! 2008-02-25 02:54:34 UTC
Hmm...even when using a version of MW downloaded a few weeks ago, turning read to false turns off the feed as well. Are you sure you are using the latest version of MediaWiki?
Comment 5 Tim Starling 2008-02-25 03:00:51 UTC
Works for me.

http://office.wikimedia.org/w/index.php?title=Special:Recentchanges&feed=rss

The reporter seems to be under the impression that the URL is insecure because
it doesn't contain a password. The opposite is true. Access to the URL is
authenticated by cookies. Putting the user's password in the URL would expose
it to accidental leaks. 

Note that if Special:Recentchanges were in $wgWhitelistRead, then the RSS feed
would be available. So don't put Special:Recentchanges in $wgWhitelistRead.

The feed is served with CC:private and Vary:cookie, so there is no cache-based
leak. 
Comment 6 Palaniappan Chellappan 2008-02-25 09:57:23 UTC
Soxred93,
The version I'm using is 1.11.1. I downloaded it about 7-10 days back. I can upload the .tar.gz file here if you want to check. And yes, I had turned read to false. $wgGroupPermissions['*']['read'] = false;

(In reply to comment #4)
> Hmm...even when using a version of MW downloaded a few weeks ago, turning read
> to false turns off the feed as well. Are you sure you are using the latest
> version of MediaWiki?
> 


Tim Starling,
I am not under the impression that the URL is insecure because it doesn't contain a password. At that point in the IRC chat, I remembered that some feeds contain a username and password in the URL to allow content to be served to registered users. But since I was able to read the content via my RSS reader though the Special:Recentchanges page's content was supposed to be protected (can't read it without logging in and $wgWhitelistRead is set to false - see below) AND the URL didn't contain any username/password, I made that comment.

I'm not saying that u/ps in URLs is a secure method. But I do believe that serving protected content only in the presence of a username/password is more secure than serving that content anyway (discounting the fact that the u/p could be discovered by someone else).

I've pasted the relevant parts of LocalSettings.php and DefaultSettings.php below. Am I missing something here?

LocalSettings.php:
#permissions
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['read']          = false;
$wgGroupPermissions['user']['read']       = true;
#because of RSS bug
$wgFeedLimit=0;

DefaultSettings.php
# Pages anonymous user may see as an array, e.g.:
# array ( "Main Page", "Special:Userlogin", "Wikipedia:Help");
# NOTE: This will only work if $wgGroupPermissions['*']['read']
# is false -- see below. Otherwise, ALL pages are accessible,
# regardless of this setting.
# Also note that this will only protect _pages in the wiki_.
# Uploaded files will remain readable. Make your upload
# directory name unguessable, or use .htaccess to protect it.
$wgWhitelistRead = false;

(In reply to comment #5)
> Works for me.
> 
> http://office.wikimedia.org/w/index.php?title=Special:Recentchanges&feed=rss
> 
> The reporter seems to be under the impression that the URL is insecure because
> it doesn't contain a password. The opposite is true. Access to the URL is
> authenticated by cookies. Putting the user's password in the URL would expose
> it to accidental leaks. 
> 
> Note that if Special:Recentchanges were in $wgWhitelistRead, then the RSS feed
> would be available. So don't put Special:Recentchanges in $wgWhitelistRead.
> 
> The feed is served with CC:private and Vary:cookie, so there is no cache-based
> leak. 
> 

Comment 7 Brion Vibber 2008-02-25 17:53:33 UTC
Is your feed reader also your browser? (Eg, Safari, Opera, Firefox.) In this case, your login session in the browser will apply just as much to the feed reader, and you're just seeing an authenticated page because you're in an authenticated session.

It's possible that some third-party feed readers also in some way share cookies with associated browsers (perhaps by piggybacking on Internet Explorer), so check into that.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links