Talk:Security issues with authorization extensions

Proposed table of extensions & which flaws they pass/fail

Good idea to make this list. There was an old one similar to this. We could create a table showing if and how each security extension handles this issues. --Fernando Correia 19:46, 23 February 2007 (UTC)

I've added which ones my Extension:Simple Security fails - I know how to fix them all since we've dealt with all those on our own hiddeous hack of a wiki (OrganicDesign:XmlWiki), so I'll slowly incorporate the fixes into Simple Security. --Nad 00:20, 2 March 2007 (UTC)

Proposed template for security extension's info pages

A template similar to Template:Extension could be used, say Template:Security extension, which could have parameters for which of the flaws it passes and fails. The template could also have a message saying something like:

MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content. But with the massive increase of MediaWiki use in corporate intranets and the many CMS-like features emerging, demand for tighter security is emerging.

To help authors of security extensions and features, a list of the security flaws found in the field is being maintained, so that they can test their extension against each. There are several extensions that claim to give selective read/write access to pages in Category:Page Access Control Extensions, and currently most of these do exhibit several of the listed flaws.

--Nad 03:21, 3 March 2007 (UTC)

Good idea, but who's going to do the auditing? Also, not only authorization extensions expose security flaws - especially, parser hook extensions are prone to be vulnerable to HTML injection, opening the wiki to XSS attacks. I have been thinking about a Template:security alert, and perhaps a toned down version, Template:security advisory. Not sure if/how this should be combined with what you propose. -- Duesentrieb ⇌ 10:58, 3 March 2007 (UTC)

There should be different "security levels"

1) Intranet - Edit permission

If the content is "read only" and just needs to be protected against changes.

2) Intranet - read permission

If the whole content needs to be protected.

3) Internet - protection against advanced hacking attempts

In the case of 2) and 3) I kind of favor the idea of RSA-crypting of the content, which I think is easier to implement. Most security breaches will retrieve the content, but would not help much, if the content is crypted.

--GunterS 11:36, 3 March 2007 (UTC)

Hm, why do you think stuff in the intranet does not have to be "so secure"? Insider attacks are generally much more serious - because insiders know what to look for (or what to change), and where.

Encrypting the data would not help to stuff remaining holes - in oder for MediaWiki to function, it needs to be able to access the decrypted data. So, if someone can query the decrypted data, anyone can (that's the nature of the security leak). The only thing encryption would protect against would be people looking at the database directly. And if you are able to do that, it's also likely you can find the place where the decryption key is stored, rendering the whole scheme pointless.

Sure, you can have people manually encrypt and decrypt all pages they want to view or edit, so their key never leaves their box. But that would be so cumbersome, it would render the wiki useless if done for anything but a few pages. -- Duesentrieb ⇌ 15:56, 3 March 2007 (UTC)

API

What about api.php access restrictions ? is it possible to access a page's content using that and bypassing any "inwiki" restriction ?

Darkoneko 09:22, 4 July 2008 (UTC)

It should not -- if it is, that's a bug in either the extension of the API code. Extensions using the UserCan hook should be fine, if it's possible to circumvent UserCan using the API, that's a bug. -- Duesentrieb ⇌ 13:12, 4 July 2008 (UTC)

Okay, thanks ^_^

Darkoneko 14:12, 4 July 2008 (UTC)

Philosophy of openness

There seems to be a bias against wikis wanting to have much functionality for restricting some access but not other access. I.e., not only do people point out that MediaWiki doesn't currently support such functionality, they seem to suggest that MediaWiki shouldn't support such functionality.

While it would be great if information could be free, the fact is that there is a lot of censorship out there. E.g., a lot of hosts will take exception to certain content if its public availability would attract controversy. There are all sorts of threats that can be brought to bear against hosts, such as economic ostracism, frivolous but costly lawsuits (especially in jurisdictions that use the American rule), unwelcome regulatory attention and investigatory scrutiny/harassment from the government, and even threats of physical violence in some cases.

One way to make that less of an issue is for a wiki to restrict public access to controversial parts of the site, e.g. by only making that content available to logged-in users. That way, the community's members can "go underground" and talk freely, without having to worry so much about outsiders raising a fuss and trying to get the plug pulled. At the same time, the wiki may wish to have a public part of the site that contains non-controversial information.

In some situations, it's not a choice between completely open, public communication and restricted communication. It's a choice between restricted communication and no communication. So, I think it is good to encourage the development of security measures that will enable these underground communities to collaborate efficiently without making their content available to everyone. Leucosticte (talk) 14:08, 12 September 2012 (UTC)