Új felhasználói csoport létrehozása a mindenki által használt CSS/JS szerkesztésére

Tracked in Phabricator:
Task T190015

A probléma

Az adminisztrátoroknak van egy rendkívül veszélyes képessége: az olyan lapok szerkesztésével, mint a Common.js, képesek azonnali parancsokat kiadni sok millió olvasó és sok ezer szerkesztő böngészőjének. (Ugyanez igaz más, hasonló jogosultságokkal bíró csoportokra, például a felületszerkesztőkre is.) Bár ez viszonylag közismert, kevesen értik, mennyire durván vissza lehet élni ezzel:

• Az olvasók vagy szerkesztők böngészőjének rosszindulatú utasításokat küldve gyakorlatilag bármit meg lehet tenni: jelszavakat vagy bankkártyaszámokat kifigyelni, ellopni az adományokat, leleplezni a szerkesztők személyazonosságát, mások nevében szerkeszteni, vírust telepíteni az olvasók gépére, spamet küldeni, DDoS-támadásokat indítani más oldalak ellen…
• Míg a legtöbb más veszélyes jogosultsággal (mint pl. az IP-ellenőrök) való visszaélésre nincs anyagi ösztönző, a fentiek nagyon is vonzóak egy tisztán a pénzkeresés által motivált bűnöző számára. Nemrég láthattunk példát arra, hogy valaki a jogosultságával visszaélve kriptopénzbányászó programot futtatott az olvasók gépén; ennél sokkal ártalmasabb támadási lehetőségek is vannak, amik vonzóak lehetnek egy könnyű bevételre vágyó támadónak.
• A kár nem korlátozódik az adott wikire: mivel a Wikimédia-wikik mind egy közös bejelentkezési rendszert használnak, aki egy wikin adminjogokat szerez, a segítségükkel könnyedén adminná teheti magát bármelyik más wikin is, és továbbterjesztheti a támadást.

Ezért a rosszindulatú adminisztrátorok vagy az adminisztrátorok felhasználói fiókját feltörő hackerek komoly veszélyt jelentenek, és minden tőlünk telhetőt meg kell tennünk ennek a semlegesítésére. Kisebb csoda, hogy semmilyen súlyos visszaélés nem történt eddig, annak ellenére, hogy rendszeresen törnek fel adminfiókokat; nem bízhatunk örökké a csodában.

Ugyanakkor a Wikimédia közösségek azon képessége, hogy befolyásolják, hogyan működnek a weboldalaik, rendkívül értékes és megőrzendő. A szerkesztői segédeszközök óriási segítséget jelentenek a munkában; az olvasóknak szóló módosítások lehetővé teszik, hogy a sok száz Wikimédia-wiki változatos problémáihoz és feladataihoz igazodjon a felhasználói felület, amit egy központosított fejlesztési módszerrel soha nem lehetne elérni; az, hogy egy közösség önmaga, külső segítség igénybevétele nélkül meg tudja oldani a problémáit, az önbizalom és motiváció fontos forrása. Legjobb, ha a helyi CSS/JS-környezet a helyi közösség irányítása alatt marad.

A megoldás

Az adminisztrátorok nagy részének sem szüksége nincs arra, hogy tudjon CSS- és JavaScript-oldalakat szerkeszteni, sem szándékában nem áll. Sokuk nem is ismeri ezeket a technológiákat. Akik jelenleg is szerkesztenek közös JavaScript- és CSS-kódot (vagy éppen most készülnek elkezdeni), azokat nincs okunk megakadályozni benne, de akiket nem érdekel az ilyen jellegű munka, azoknak ne legyen jogosultságuk hozzá, hogy a fiókjukat feltörő támadó ne tudjon kárt okozni. Továbbá a wikiszoftvernek támogatnia kell azokat a közösségeket, akik szigorúbb elbírálás szerint akarják kiosztani a a JavaScript-szerkesztési jogot, mint a hagyományos adminisztrátorit (ami bölcs dolog).

Mindezt egy új műszaki adminisztrátor felhasználói csoport fogja lehetővé tenni; csak ennek a csoportnak a tagjai tudnak majd közösen használt CSS/JS-oldalakat szerkeszteni. Alapértelmezésben a bürokraták és az intézők állíthatják be a csoporttagságot, hasonlóan ahhoz, ahogy az adminisztrátorokat kezelik. A műszaki adminisztrátorok megválasztásának módja a helyi közösségre lesz bízva (vagy a globális Wikimédia-közösségre, ha az utóbbi globális irányelvet alkot róla a szokásos módon).

Ennek számos előnye van:

• Az oldal feltörésére képes felhasználói fiókok száma drasztikusan lecsökken. Ha kevesebb az olyan fiók, amit egy támadó fel tud használni, kisebb az esélye, hogy hogy talál alkalmas feltörhető fiókot, amikor egy újabb adag jelszó kerül nyilvánosságra valamelyik külső weboldal feltörése után. (Ez egyben azt is jelenti, hogy a hagyományos adminisztrátoroknak kevésbé kell aggódnia amiatt, hogy hackerek célpontjává válnak.) Kevesebb fiók esetén a gyanús bejelentkezéseket figyelni is könnyebb.
• Túl azon, hogy csökken a támadó által felhasználható fiókok száma, a legsebezhetőbb fiókok alkalmatlanná válnak a támadásra. Azok a felhasználók, akik tudnak CSS/JS-kódot írni, jellemzően általában is jobban értenek a számítástechnikához, és így a jelszavaikat és az operációs rendszerüket nagyobb biztonságban tudják tartani.
• A jövőben lehetséges lesz így magasabb biztonsági feltételeket előírni a CSS/JS-szerkesztőknek (mint például a kétlépcsős azonosítást), anélkül, hogy a többi adminisztrátornak (akiknek a fiókjának a feltörése nem jelent akkora veszélyt) kényelmetlenséget kellene okozni.

Műszaki oldalról nézve két új jogosultság jelenik meg a MediaWikiben (editsitecss és editsitejs); egy MediaWiki-névtérbeli .css vagy .js oldal szerkesztéséhez mind a hagyományos editinterface, mind a megfelelő editsiteXXX jog szükséges. Az adminisztrátorok és más olyan csoportok, akiknek jelenleg megvan az editinterface joga, egy rövid átmeneti időszakra megkapják az új jogokat (hogy az átállás zökkenőmentesen menjen), de hosszabb távon nem, és a szoftver nem is engedi a jogok megadását a műszaki adminisztrátorokon kívül más csoportnak.

Hogyan segíthetsz

• Amikor a konzultáció véget ér, lesz egy átmeneti időszak (valószínűleg két hét), amikor a műszaki adminisztrátor csoport már létezik, de a sima adminisztrátorok még tudnak CSS/JS-lapokat szerkeszteni. Hívd fel a saját közösséged figyelmét erre, hogy fel tudják venni a műszaki adminisztrátor csoportba a megfelelő embereket, és hogy legyen valami módszerük annak az eldöntésére, ki a megfelelő ember. (Hogy pontosan mi ez a módszer, az a helyi közösségre van bízva; egy egyszerű megoldás, ha minden olyan adminisztrátort felvesznek, aki kéri ezt.)
• Segíts megalkotni a műszaki adminisztrátor szerep dokumentációját és szabályozását a saját wikiden! Ez megint csak lehet olyan egyszerű is, mint hogy minden újonnan megválasztott admint megkérdeznek, hogy szeretne-e műszaki adminisztrátor is lenni (és ismeri-e a JavaScriptet, és vannak-e alapvető biztonsági ismeretei). Mindenesetre érdemes legalább olyan magasra tenni a mércét (megbízhatóság és viselkedés tekintetében), mint az adminisztrátoroknál, vagy akár magasabbra is (bővebben lásd a felhasználói csoport dokumentációjában).
• Ha tudsz olyan CSS- vagy JavaScript-szerkesztési szituációról, amihez további jogosultságok kellenek, írd meg, mi az (ez segít eldönteni a műszaki adminisztrátorok alapértelmezett jogosultságait). Például kell-e tudnia egy műszaki adminisztrátornak lapokat törölni, vagy a tartalomtípust megváltoztatni?
• Javasolj jobb nevet a csoportnak! A „műszaki adminisztrátor” nem a legjobb. Potenciális buktatók: ne legyen összetéveszthető a wikin kívüli programkódot karbantartó fejlesztőkkel (MediaWiki-fejlesztőkkel, Toolforge-eszköz-készítőkkel stb.); ne legyen összekeverhető a Lua-kódon (a Modul névtérben) dolgozókkal; a felületszerkesztő csoport továbbra is létezni fog (a rendszerüzenetek módosítására); lehetőleg fejezze ki a név, hogy legalább annyira bizalmi pozícióról van szó, mint az adminisztrátor.
• Ha bármi olyan problémát látsz, amit nem láttunk előre, vagy olyan változtatást javasolnál, ami hasznosabbá teszi az új szerepet vagy könnyebbé az átállást, mondd el!

A vitalapon tudsz üzenetet hagyni. Bármilyen nyelven írhatsz.

GYIK

Ki van a szöveg mögött?

Ezt az oldalt és a kapcsolódó kódváltoztatást Tgr írta (önkéntesi minőségben). A T190015-ön és a wikitech-l-en zajlott megbeszélés alapján úgy vélem, hogy a MediaWiki fejlesztői közösségének konszenzusos álláspontját képviseli.

Ez egy véleménykérés?

A szónak abban az értelmében nem, hogy a résztvevők álláspontja határozná meg, hogy létre lesz-e hozva az új csoport. Ez nem szavazás. Szoftverbiztonsági kérdésekben a MediaWiki fejlesztői közösségének konszenzusa dönt, nem a szerkesztők konszenzusa; a végső döntés, mint ilyen esetekben mindig, a kódellenőrzés során születik. Ezzel együtt kíváncsiak vagyunk a véleményedre! A megbeszélés során felszínre kerülhetnek indokok arra, hogy ne az itt leírt módon járjunk el, és dönthet fontos részletekről, például hogy milyen további jogokat kapjon az új csoport. Emellett az egyes wikiközösségeknek is segít annak átgondolásában, hogyan kezeljék ezt a változást az irányelveikben és munkafolyamataikban.

Ez egy reflexszerű reakció a közelmúltbeli incidensekre?

Nem. Bár remélem, hogy ezek rámutattak a veszély nagyságára, ez a változtatás évek óta tervben volt, és az új jogosultságkezelő kód márciusban született meg.

Az adminisztrátoroknak ez után a változtatás után is lesznek lehetőségei arra, hogy mindenkinek a böngészőjében lefutó JavaScript-kódot adjanak az oldalhoz.

Ez egy (nem könnyű) műszaki probléma, amivel idővel meg fogunk birkózni. Akárhogy is, ha az adminisztrátorok JavaScript-szerkesztési lehetőségeit néhány kevesek által ismert trükkre korlátozzuk, azzal jelentősen csökken a támadási felület, és a megmaradó sebezhetőségek figyelése is könnyebbé válik.

Miért kezeljük a CSS-szerkesztést ugyanolyan veszélyként, mint a JavaScriptét?

A CSS ugyan kevésbé veszélyes, mint a JavaScript, de azért épp elég veszélyes:

• A képekhez kapcsolódó CSS-tulajdonságokkal ki lehet deríteni a szerkesztők személyazonosságát.
• Elavult böngészőkben a CSS-be is lehet JavaScriptet rejteni.
• Lehetséges CSS-kód segítségével edit tokeneket lopni (és ezáltal mások neve alatt és jogosultságaival szerkeszteni), még ha ezt egyelőre a legtöbb böngésző nem is támogatja.
• A CSS-alapú klikkelterelés adathalászati támadások kitervelésére használható.

A statisztikák azt mutatják, hogy majdnem minden olyan adminisztrátor, aki rendszeres CSS-szerkesztő, rendszeres JavaScript-szerkesztő is, úgyhogy nem származna belőle előnyünk, ha a két problémát külön kezelnénk.

Lehetséges, hogy a jövőben a CSS egy biztonságos, szűrt részhalmazának a szerkesztését újra elérhetővé tesszük; lásd a TemplateStyles projektet.

Ez a TemplateStyles .css lapjaira is vonatkozik?

Nem, csak a MediaWiki-névtérbeli CSS lapokra. A TemplateStyles CSS-kódjából a szoftver automatikusan kiszűri a nem biztonságos elemeket.

Miért nem inkább arra koncentrálunk, hogy automatikusan felismerjük és megakadályozzuk az ártalmas JavaScript-szerkesztéseket?

Bár ezen a területen is van hova fejlődnünk (például be szeretnénk vezetni a CSP-t és valamilyen közösségi kódellenőrzést), a támadások biztos megelőzése sohasem lesz lehetséges – egy programnyelvet nem lehet szűrni. Továbbá az ilyen irányú óvintézkedések sokkal bonyolultabbak és sokkal több munkát igényelnek. Rövidtávon a JavaScriptet szerkeszteni tudó felhasználói fiókok számának csökkentése messze a leghatékonyabb megelőzési stratégia; hosszabb távon erre is és az egyéb óvintézkedésekre is szükség van.

Mi a helyzet az editusercss/edituserjs jogosultságokkal?

Ezek a (nem közismert és nagyon ritkán használt) jogosultságok lehetővé teszik egy másik felhasználó személyes CSS/JS-lapjainak szerkesztését. Mivel így el lehet lopni az adott felhasználó fiókját, ugyanazok a megfontolások érvényesek rájuk, és ugyanúgy korlátozva lesznek. (Hosszabb távon lásd a T197087-beli megbeszélést.)

Mi a helyzet az új editsitejson jogosultsággal?

Ez a MediaWiki-névtérbeli .json lapok szerkesztésére szolgál (ezt a funkciót a szoftver nemrég kezdte el támogatni, a célja a segédeszközöknek és botoknak szóló konfigurációs lapok létrehozása). A JSON adat, nem kód, ezért a szerkesztése nem veszélyes, és az adminok továbbra is képesek lesznek rá; a segédeszközöket úgy kell megírni, hogy a rosszindulatú JSON ne tudjon ártani nekik.