Zabezpečení mediawiki

2.3.2012 13:18 | Přečteno: 2031× | Za vším hledej Linux |

Když jsem před téměř čtyřmi lety spouštěl náš podpůrný server http://support.dce.felk.cvut.cz vsadil jsem na MediaWiki. Vcelku jednoduchý kalkul - předpokládám, že vývoj systému na kterém běží Wikipedie hned tak neskončí.

Benevolence nebo restrikce?

Většina školních wiki, na které jsem tehdy natrefil měla nastaven restriktivní přístup. Tzn. že na jejich stránky se mohl dostat pouze přihlášený uživatel, který navíc byl příslušníkem příslušné instituce.

Já jsem zastávánce benevolentního přístupu - pokud neděláš bordel, můžeš spolupracovat i když nejsi z naší školy. Řešil jsem tedy otázku: "Jak v mediawiki zajistit, aby mohly v jejím rámci vznikat stránky pro uzavřené skupinky uživatelů a zároveň i pro lidi zvenčí, aniž by mě musel někdo otravovat ohledně nastavení práv?".

Natrefil jsem tenkrát na rozšíření Group Based Access Control, které umožňovalo chránit obsah stránky pomocí uživatelských seznamů editovatelných stejným způsobem jako běžné stránky. Super! Jenže to mělo nějaké mouchy. Nejdřív jsem se je pokoušel opravit, ale nakonec z toho vylezlo rozšíření vlastní - AccessControl.

Kdo si čte ten nezlobí

Základní podmínkou pro použití ochrany přes uživatelský seznam je zaregistrovaný účet. Každý si v naší wiki tedy může založit svůj účet a začít tvořit, případně se podílet na úpravě již existujících stránek. To je hlavní rozdíl mezi anonymním a přihlášeným uživatelem.

Každý přihlášený uživatel si navíc může vytvořit vlastní seznam uživatelů, oprávněných přistupovat na jím chráněné stránky. Na tyto stránky mají kromě osob ze seznamu přístup pouze administrátoři wiki. Nikdo jiný.

Hlavní rozcestníky a kategorie jsou pro běžné uživatele uzamčeny, ale tím restrikce v podstatě končí. Čas od času kontrolujeme změny, jestli náhodou nějaký vykuk netropí neplechu.

Škodiči

Víc jak tři roky utekly bez toho, že by se nějaký objevil. Ovšem na sklonku minulého roku se tu a tam začali objevovat registrovaní uživatelé s už od pohledu generovaným jménem. Ze začátku jsme tomu nevěnovali příliš pozornost, ale pak začal někdo prostřednictvím takto založeného účtu vkládat stránky s nežádoucím obsahem.

Z logu jsem zjistil že to dělá někdo skriptem, který spouští z různých lokací. Tak jsem mu zatnul tipec jednoduchým opatřením - každý nově zaregistrovaný uživatel může zakládat nové stránky až po uplynutí intervalu, který spolehlivě odradí jakýkoliv skript.

Fajn. Zakládání nežádoucích stránek skončilo. Jenže registrace pseudouživatelů neustávala. Nejprve jsem zkusil hook, který byl navěšený na registrační formulář, ale nezabralo to. Tak jsem se dožral a pořádně si okouknul log v apachi.

A je pokoj. Dopsal jsem si jednu malou podmínku přímo do třídy v níž se řeší vytvoření nového účtu a je klid. Lapidárně řečeno - kontroluje se, zda-li odesílatel registračního formuláře skutečně prošel registrační procedurou.

       

Komentáře

[xkucf03]

Koukám, že tam máš i SSO – ale teď nějak nefunguje:

Not Found
The requested URL /Shibboleth.sso/Login was not found on this server.
Apache/2.2.16 (Debian) Server at support.dce.felk.cvut.cz Port 80

BTW: když to funguje, tak je to jen v rámci vaší školy, nebo je tahle wiki v EduID federaci?

[Aleš Kapica]

Nefunguje - je to relikt rozšíření MultiAuth. Pro potřeby naší wiki je přihlašování přes externí server v podstatě zbytečné. Chtěl jsem ho vyhodit, ale hází to pak nějakou chybu, kterou se mi už nechce řešit.

V současné době totiž připravuji novou, aktualizovanou 64-bitovou verzi supporta s mediawiki 1.19.1 u které je nutné AccessControl předělat. Jsem s tím již v podstatě hotov, ale tím že jsem pořešil ty škodiče akutnost aktualizace mediawiki razantně klesla.

Navíc jsme zjistili jednu nepříjemnou věc. Server vůči kterému se autorizace Shibbolethu provádí je only IPv4 a nový support by měl být dostupný i přes IPv6. Zatím jede ten stroj v uzavřeném testovacím prostředí, takže je otázkou jak se s tím pak popere.

[sidik]

Božínku, díky za to, že se někdo překonal a do tý hrůzy dopsal funkční plugin. Za tohle bys zasloužil poděkování před nastoupenou jednotkou. Taky jsem přesně tohle potřeboval ale neměl jsem sílu a žaludek do MediaWiki cokoliv dopisovat. Jak je to na povrchu skvělý soft, tak uvnitř...

Ještě jednou dík :)

[Let_Me_Be]

A fakt to funguje? Kdyz jsem takovy plugin hledal, tak jsem jenom nasel prohlaseni od vyvojaru, ze takovy plugin neni mozne vytvorit, kvuli neprebernemu mnozstvi zpusobu jak se da k obsahu dostat.

Nakonec jsem proto skoncil u dokuwiki (na co si teda v zadnem pripade nestezuji).

[Josef Kufner]

Co jsem si tak všimnul, tak na FELu je Dokuwiki velmi oblíbená.

[Aleš Kapica]

Jak jsem psal. Je to čtyři roky co jsem to napsal. Pak následovala asi po roce oprava, kdy jsem zjistil že se to dalo obejít přes redirect. My máme mediawiki verze 1.15.1, ale našli se lidé co napsali jakou úpravu je třeba udělat aby to fungovalo i u v. 1.16.

U mediawiki verze 1.18 odstranili hook, na který je ta stávající verze navěšená. Překopal jsem to, ale ještě s tím nejsem hotov. Nějaké změny totiž nastaly i v tom co, kdy a jak má uživatel povoleno. Vím už jak to mám pořešit, ale mám teď nějaké resty. Hodně času jsem zabil i díky tomu, že mě nenapadlo explicitně zakázat veškeré kešování na serverové straně mediawiki. Za normálního provozu to nevadí, ale při testech jsem koukal jako blázen že mi pořád vrací stejný výsledek, i když se kód co generuje stránku změnil.

[Josef Kufner]

Já když dělám nějaké kešování, tak do podmínky, která kontroluje aktuálnost keše, přidávám i porovnání s mtime souboru zdrojáku, neboť jsem se kdysi taky divil

[Aleš Kapica]

Aktuálnost keše nekontroluji. Jakákoliv keš je totiž v tomto případě nežádoucí. Měl jsem za to, že když od verze 1.18 zrušili nutnost jejího vypínání, že ji zrušili úplně. Ale jak se ukázalo, týkalo se to jenom keše, která vracela již zpracovanou stránku.