Bezpečnostní problémy s autorizačními rozšířeními

MediaWiki není navržena jako systém správy obsahu (CMS) nebo k ochraně citlivých dat. Naopak byl navržen tak, aby byl co nejotevřenější. Nepodporuje tedy ze své podstaty plně funkční, vzduchotěsnou ochranu soukromého obsahu. Ale s masivním nárůstem používání MediaWiki v podnikových intranetech a mnoha novými funkcemi podobnými CMS se objevují požadavky na přísnější zabezpečení.

Abychom pomohli autorům bezpečnostních rozšíření, tento seznam bezpečnostních chyb nalezených v této oblasti je udržován, aby mohli svá rozšíření otestovat proti každému z nich. Existuje několik rozšíření, která tvrdí, že poskytují selektivní přístup ke čtení/zápisu na stránky v Kategorie:Rozšíření uživatelských práv pro konkrétní stránku , a v současné době většina z nich vykazuje několik uvedených nedostatků.

Testování bezpečnostních rozšíření

Pokud se chystáte implementovat přístup pro čtení nebo zápis, zkontrolujte rozšíření, zda neobsahuje nedostatky uvedené v tabulce níže, a to tak, že se přihlásíte jako uživatel bez oprávnění ke čtení/zápisu. Spuštění nové relace procházení webu prostřednictvím režimu inkognito umožňuje navigaci na webu jako neprivilegovaný uživatel, když je software testován a konfigurován.

Tabulka běžných omezení bezpečnostních rozšíření

Funkce/Test	Zkontroluje	Poznámka
Inkluze/transkluze	Máte přístup na stránky s omezeným přístupem prostřednictvím {{:restricted article}}? Co když používáte více úrovní (transkluze v rámci transkluzí)? Můžete přistupovat na stránky s omezeným přístupem prostřednictvím převodu na přesměrování? Můžete obejít omezení transkluze použitím transkluze v režimu náhledu úprav nebo prostřednictvím Special:ExpandTemplates? Můžete obejít omezení transkluze pomocí rozhraní API (např. metoda action=parse) Můžete použít chybové zprávy, které berou uživatelem řízené parametry a poté je analyzují jako wikitext, abyste obešli omezení Máte přístup přes {{msgnw::název stránky}}	Částečně to řeší nastavení $wgNonincludableNamespaces zavedené v MW 1.10 (rev:19934). Můžete také použít manual:Hooks/BeforeParserFetchTemplateAndtitle , manual:Hooks/ParserFetchTemplate , ParserOptions::setTemplateCallback(), ParserOptions::setCurrentRevisionCallback(), ale pozor na ukládání do mezipaměti.
Předběžné načtení	Můžete obejít omezení pomocí parametrů URI editintro= nebo preload= v režimu úprav?	Mělo by být bezpečné s rozšířením pomocí háčku UserCan , alespoň od 1.12 (možná i dříve).
XML export (Special:Export)	Je možné exportovat obsah stránky s omezeným přístupem?	U rozšíření pomocí háčku userCan to bylo opraveno v MW 1,10 (rev:19935).
Atom/RSS kanály	Bude článek doručen? S rozdílem nebo plným obsahem? Existují dva zdroje, jeden na speciálních stránkách Poslední změny a druhý na historii stránek. Rozšíření mohou poskytnout další zdroje.	U rozšíření pomocí háčku userCan to bylo opraveno v MW 1,12 (rev:25944). userCan není uznán v MW 1.14 a rozhodně dříve (SpecialRecentChanges*.php byly přesunuty)! Stránky seznamů RecentChanges upraví komentáře.
Výpisy a vyhledávání	Jsou na stránce Special:Search uvedeny nečitelné stránky? Jsou zobrazeny úryvky? (Viz také phab:T10825) Jsou nečitelné stránky uvedeny na Special:Recentchanges nebo Special:Allpages? Jsou nečitelné stránky uvedeny na jiných speciálních stránkách, jako jsou Lonelypages atd.?	Pro rozšíření používající háček userCan to bylo částečně řešeno v MW 1.10 (rev:21821): Stránka vyhledávání již nezobrazuje úryvky ze stránek, které nejsou čitelné - ale stále uvádí názvy článků, které nejsou pro uživatele dostupné.
Odkazy na rozdíly a revize	Lze použít přímý odkaz na rozdíl stránky k zobrazení textu z omezené stránky? Jak je to s rozdílem mezi revizí stránky bez omezení a revizí stránky s omezením pomocí manipulace s ID revize? Můžete použít trvalý odkaz (odkaz na revizi) na starou verzi k přečtení stránky, kterou byste neměli číst? Co takhle odkaz, který má ID revize patřící jinému, než na který odkazuje nadpis, manipulací s URL?	Pro rozšíření používající háček userCan by to mělo být v pořádku na nejnovějších verzích MediaWiki.
API	Lze parametr revids pro action=query použít k načtení revizí, které by měly být skryté? Může action=compare uniknout obsah stránky.	V moderní MediaWiki by měl háček na userCan dostat prop=revisions, ale možná ne ostatní
Aktivní odkazy	Můžete použít možnosti action=raw nebo action=render ke čtení stránky, kterou byste neměli číst? Máte přístup k tisknutelné verzi stránky, kterou byste neměli číst? Lze přímý odkaz na stránku úprav použít k zobrazení obsahu stránky s omezeným přístupem?	Pro rozšíření používající háček userCan by to mělo být v pořádku na nejnovějších verzích MediaWiki.
Související práva	Brání rozšíření uživateli ve vytvoření nové stránky, ke které nebude mít přístup pro čtení? Můžete přesunout nebo přejmenovat stránku, ke které máte přístup pro čtení, ale nemáte přístup k zápisu? Můžete si přečíst diskusní stránku stránky, ke které nemáte přístup pro čtení? Můžete napsat diskusní stránku na stránku, ke které nemáte přístup pro zápis, pokud to výslovně nepovolíte?	Pokud používáte userCan, mělo by to být v pořádku, ale možná budete muset napsat ArticleInsertComplete háček pro výtvory a TitleMoveComplete háček pro pohyby, které volají userCan ke 'kopírování' oprávnění.
Autorská zadní vrátka	Některá rozšíření vždy umožňují původnímu autorovi stránky k ní přistupovat, přičemž ignorují pozdější omezení přístupu.
Ukládání do mezipaměti	Mezipaměť analyzátoru (ve výchozím nastavení povoleno) ukládá články mezi uživatele do mezipaměti. $wgEnableSidebarCache (ve výchozím nastavení není povoleno) provádí podobnou funkci pro postranní panel. Pokud by rozšíření mohlo odesílat různé stránky různým uživatelům, může být nekompatibilní s tímto ukládáním do mezipaměti.	Omezení ukládání článků do mezipaměti na anonymní uživatele může poskytnout většinu výkonnostních výhod pro weby s převážně anonymními uživateli (jako je Wikipedie), aniž by došlo k ohrožení zabezpečení.
Soubory a obrázky	Můžete si soubor stáhnout přímo bez ohledu na přístup pro čtení k příslušnému článku? Můžete si stáhnout miniaturu souboru obrázku přímo bez ohledu na přístup ke čtení souvisejícího článku? Můžete nahrát nebo smazat obrázek bez ohledu na přístup k zápisu do souvisejícího článku?	Vzhledem k tomu, že nahrané soubory jsou běžně obsluhovány přímo webovým serverem, nikoli prostřednictvím MediaWiki, není snadno možné, aby rozšíření bránila přístupu. Pokyny k nastavení omezení přístupu k obrázkům naleznete v části Manual:Image Authorisation . (img_auth.php používá userCan od r52751).
−Přesměrování	Pokud má uživatel oprávnění zobrazit přesměrování, ale ne stránku, na kterou odkazuje, je stále přesměrován? Pokud má uživatel oprávnění zobrazit stránku, ale nemá přesměrování, které na tuto stránku odkazuje, může na stránku přistupovat přes přesměrování?
Úprava sekce	Může uživatel použít funkci 'upravit sekci' pro stránku, i když nemůže upravit celou stránku (buď prostřednictvím rozhraní nebo změnou adresy URL)? Může uživatel použít funkci 'upravit sekci' pro stránky, ke kterým mu byl udělen přístup?	Pokud zabezpečení závisí na značkách vložených do kódu stránky, pak tyto značky nemusí být nutně přítomny v textu, který upravujete, i když jsou přítomny jinde na stránce.
Sledování stránek	Může uživatel sledovat stránku, kterou nesmí číst? Může uživatel přestat sledovat stránku, kterou nesmí číst? Dostává uživatel stále upozornění, i když byl uzamčen?	Potřebuje háček WatchArticle , který zavolá userCan.
Další rozšíření	Může uživatel k zobrazení části stránky použít jiná rozšíření? Přemýšlejte o DynamicPageList nebo Semantic MediaWiki , které poskytují způsoby dotazování databáze na určité stránky nebo vlastnosti. Zobrazuje rozšíření důvěrné názvy stránek, jako je gadget nedávno upravených stránek? Můžete načíst obsah stránky přes mw.title.new( "Page name" )::getContent() Scribunto	Scribunto bude respektovat zpětná volání při načítání revizí ParserOptions::setCurrentRevisionCallback, ale ostatní rozšíření pravděpodobně ne
Znečištění mezipaměti	Existuje nějaká situace, kdy by se soukromá stránka mohla uložit do mezipaměti MediaWiki s oprávněním kontrolovaným v době mezipaměti? Později pak jiný uživatel získá hodnotu uloženou v mezipaměti, aniž by byla spuštěna kontrola oprávnění.
API:REST API	Zobrazuje REST API důvěrné stránky?	Aktivuje se při aktivaci VisualEditor nebo některých dalších rozšíření.

V systému ochrany proti čtení je pravděpodobně více "děr". Odepření přístupu pro čtení by tedy mělo být vnímáno jako něco jako "k vidění, pokračujte dál", spíše než jako záruka utajení.