Last modified: 2010-05-15 15:59:49 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.
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).
Created attachment 4663 [details] The IRC conversation about this bug
Created attachment 4675 [details] Human readable version of the same IRC log
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?
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.
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. >
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.
