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)