Manual:Security/hu


 * Ha úgy gondolod, hogy a MediaWiki-ben vagy a Wikimédia bármely oldalán biztonsági problémát találtál, vedd fel velünk a kapcsolatot (lásd: ) hogy hibajavítást adhassunk ki.



Maradj naprakész
A legfontosabb biztonsági szempont a szoftver naprakészen tartása. Mind a MediaWiki, mind azon szoftverek amelyektől függ, időnként frissülhetnek, amely új kiadások biztonsági foltokat is tartalmaznak.

A MediaWiki fejlesztői erősen ajánlják, hogy a szoftvert használók iratkozzanak fel a mediawiki-announce levelezőlistára. Ez egy alacsony forgalmú lista, ahol az új verziókat jelentik be.

A MediaWiki élettartam-ciklusával összhangban minden kiadáshoz egy éven át érkeznek biztonsági frissítések. A régebbi kiadásokban ismert, de javítatlan biztonsági rések lehetnek.

Ne feledkezz meg az Apache, PHP, MySQL/MariaDB és más, a szervereden futó szoftverek, az operációs rendszer és a webapplikációk frissítéséről sem.

Számos, a MediaWiki 1.3.x kiadását futtató felhasználót érintett a 2004 telén terjedő PHP-féreg, amely más, nem frissített phpBB-oldalakon jutott be a szerverre, ahol az írható PHP-fájlokba, köztük a MediaWiki 1.3 lefordított sablonjaiba is „you are hacked” („oldalad feltörve”) üzenetet helyezett el.

Légy óvatos a használt kiterjesztésekkel
Számos kiterjesztés érhető el a MediaWikihez, azonban ezek változó minőségűek. Az alacsony minőségű kiterjesztések használata a biztonsági hibák egyik leggyakoribb forrása.

Egy kiterjesztés használata előtt járj utána annak. A közösség ismert tagjai által fejlesztett eszközök általában biztonságosak, ugyanez igaz a Wikimédia Alapítvány oldalain telepített kiterjesztésekre is (természetesen erre sincs garancia). Ha egy több éve nem frissített, kevés tapasztalattal rendelkező személy által készített kiterjesztést találsz GitHubon, akkor az magas biztonsági kockázatot rejthet magában. Extensions made by prominent members of the MediaWiki development community are usually quite safe. Similarly any extension used on a wiki run by the Wikimedia Foundation has probably been looked at carefully, and is probably safe (There are of course no guarantees). However if you find an extension floating around github that hasn't been touched in many years and was developed by someone with little experience in web development, it is probably pretty high risk.

A nap végén vedd fontolóra a telepítéssel járó biztonsági kockázatot a más szoftvereknél megszokott módon.

A kiterjesztéseket is szükséges naprakészen tartani; a MediaWiki-szoftverrel együtt érkező bővítményekkel kapcsolatos bejelentések a mediawiki-announce levelezőlistán olvashatóak, azonban a többinél ez a lehetőség nem áll fenn. Néhány külső kiterjesztés készítője a biztonsági hibákat közzéteszi a mediawiki-l levelezőlistán.

Fájlengedélyek
Az egyik legfontosabb biztonsági tényező az, hogy a PHP- (Debian esetén gyakran www-data) és a MySQL-futtató felhasználónak ne legyen a PHP engedélyezésekor nyilvánosan hozzáférhető mappákhoz írási joga.

On Debian-based systems this means the www-data user should not own the php files.

Unix-szerű rendszereken ehhez a MediaWiki-könyvtár tulajdonosa a webszerver- (www-data) vagy a MySQL-felhasználótól eltérő kell, hogy legyen. A telepítés módjától függően ez lehet alapértelmezés is; ha nem, a $code1 segítségével hajtható végre a művelet, ahol a felhasználónév az előbbiektől eltérő (valószínűleg a $mysql és a $php nem saját neved alatt fut). Ezen lépés után szükséges lehet a képek könyvtára jogosultságának visszaállítása a PHP-felhasználóra, mivel a feltöltéshez a MediaWikinek írási jogra van szüksége (például $code2). Végül futtasd a $code3 parancsot, így a tulajdonosokon kívül másnak nem lesz írási joga; ezután szükséges lehet a képek mappáján az előzőekben leírtak elvégzésére. Depending on how you installed MediaWiki this may already be the case, but if not can be accomplished by doing where username is a user other than the webserver or mysql user (commonly you would use your own username provided mysql and php are not running as your username). After doing that step, you may however need to change the owner of the image directory back to the php user, as uploaded files need to go there, so MediaWiki needs to be able to write there (e.g. ). Next you run  to remove write access from all other users besides the file owners. After doing that step you may need to re-enable write access to the images directory.

Azon mappák, amelyekhez a szoftvernek írási jogra van szüksége (például $wgCacheDirectory), a gyökérkönyvtáron kívül helyezkedjenek el; ez alól a képek könyvtára kivétel, amelynek a gyökérben kell lennie, viszont fontos, hogy ezen mappában tiltsd le a PHP-t. A részletek a szervertől függenek, de Apache alatt általában a $htaccess fájlban elhelyezett $code1 a kívánt viselkedést hozza. Ha a beállítást magán a könyvtáron belül végzed el, győződj meg róla, hogy a konfigurációs fájl nem írható a webszerver által. A feltöltések biztonságáért lásd a vonatkozó szakaszt. The exception being the images directory, which must be in the web root. However, it is important to disable php in the images directory. The details on how to do this varies with webserver, but on apache it can sometimes be accomplished by using  in a .htaccess file. If you do accomplish this via a config file in the images directory itself, you should ensure the config file is not writable by the webserver. See the section below on upload security for more details.

A LocalSettings.php fájl a PHP-felhasználó által olvasható kell, hogy legyen, azonban az adatbázis-jelszó és más érzékeny információk elrejtéséhez ne legyen írható. A többi MediaWiki-fájlhoz hasonlóan a LocalSettings.php-hoz se legyen a PHP-felhasználónak írási joga. Like all MediaWiki files, the php user should not be able to write to LocalSettings.php.

TLS
A Firesheep-stílusú támadások és az általános adatszivárgások elleni védelemként javasolt a TLS (HTTPS) használata. Ennek beállítása kívül esik ezen útmutató témáján, annyit viszont érdemes megjegyezni, hogy a $letsencrypt ingyenes tanusítványokat kínál. A guide for setting up TLS is out of the scope of this document, however it should be noted that this is much cheaper now that letsencrypt.org provides free certificates.

A TLS beállítása esetén fontos az ssllabs.com/ssltest/ oldalon való tesztelés, mivel a rendszer könnyen félrekonfigurálható.

Ha engedélyezed a TLS-t, érdemes beállítani a webszerveren a -fejléc küldését, amely erősíti a védelmet az adatlopások ellen, viszont ekkor nem dönthetsz úgy, hogy egy időre kikapcsolod a TLS-t. This will improve the security of your website against eavesdroppers quite a bit, but at the drawback that it means you cannot decide to stop using TLS for a set period of time.

Általános PHP-javaslatok

 * További információkért lásd az OWASP PHP-biztonsági útmutatóját.

Ezek a tanácsok nemcsak a MediaWiki, de bármely PHP-környezet esetén megfontolandóak.

Javasolt beállítások a fájlban vagy máshol való konfigurációhoz:

A  kikapcsolása. A beállítás bekapcsolásával a sütik helytelen működése esetén a munkamenet-azonosítók megjelenhetnek az URL-ben, ezzel harmadik felek ajánlóadatokkal vagy másolás-beillesztéssel megszerezhetik ezeket.
 * A  letiltása.
 * Számos PHP-támadás globális változókkal történik, így ezek megelőzésének érdekében győződj meg róla, hogy a register_globals ki van kapcsolva.
 * Ha egy másik applikáció miatt szükséged van a -ra, csak a virtuális hoszt és a kérdéses alkönyvtár esetében engedélyezd.
 * A MediaWiki a beállítás On értéke esetén is biztonságos; a kikapcsolás elővigyázatosság a nem ismert fenyegetések ellen.
 * A  letiltása (kivéve ha szükséged van rá).
 * A távoli PHP-kódok futtatásával kapcsolatos kockázatok attól függenek, hogy a kártékony kódot sikerül-e  vagy   funkcióba burkolni. Ha nem használod a távoli fájlbetöltést, akkor ennek kikapcsolásával megelőzhetőek az ilyen típusú támadások.
 * A MediaWiki esetében a Lucene keresési kiterjesztés, az OAI értelmezőbővítmény, a TitleBlacklist, illetve az 1.5 verzióban a Special:Import egyes funkciói igénylik ennek bekapcsolását, azonban általános beállítások mellett erre nincs szükség.
 * A MediaWiki a beállítás On értéke esetén is biztonságos; a kikapcsolás elővigyázatosság a nem ismert fenyegetések ellen.
 * Ezt mindig kapcsold ki.

Például ha a következőt látod a php.iniben:

register_globals = On

változtasd meg a következőre:

register_globals = Off

Alternatívaként a könyvtáralapú engedélyezéshez használhatod a következő Apache-direktívát:

php_flag register_globals off

Ezután indítsd újra az Apache-ot a változtatások újratöltéséhez ( vagy   (SUSE)).

Többfelhasználós rendszer esetén, ha a PHP Apache-modulként lett telepítve, minden felhasználói szkript ugyanazon, csökkentett jogosultságú fiókon fut. Ezzel más felhasználók láthatják a konfigurációs állományokat (köztük az adatbázis-jelszavakat is), módosíthatják a bejelentkezési munkamenet adatait és ha engedélyezted, írhatják a feltöltési könyvtárat is. This may give other users access to read your configuration files (including database passwords), read and modify your login session data, or write files into your upload directory (if enabled).

Többfelhasználós rendszerek biztonságához fontold meg CGI/FastCGI-konfiguráció használatát, így minden szkript saját fiókon fog futni.

Általános MySQL- és MariaDB-javaslatok
Általánosságban érdemes az adatbázis elérhetőségét minimalizálni. A használat csak a futtató számítógépről történjen; érdemes letiltani a hálózati elérést, vagy csak helyi hálózatot használni (a loopback eszközön át, lásd alább), így a szerver a Unix domain socketjein keresztül csak a helyi kliensekkel tud kommunikálni. If it will only be used from the single machine it's running on, consider disabling networking support, or enabling local networking access only (via the loopback device, see below), so the server can only communicate with local clients over Unix domain sockets.

Az adatbázist csak korlátozott kliensszámú hálózaton használd, és érdemes beállítani a tűzfalon, hogy a TCP 3306-os porton (az adatbázis portja) keresztül csak a megbízható gépekről fogadjon kéréseket, az internet felőlieket pedig utasítsa el. Ez segíthet megakadályozni, hogy egy ismeretlen adatbázis-hiba (rosszul beállított GRANT vagy kiszivárgott jelszó) miatt a szerver széles körben elérhetővé váljon. This can help prevent accidentally opening access to your server due to some unknown flaw in the database server, a mistakenly set overly broad GRANT, or a leaked password.

Ha a MySQL/MariaDB-felhasználót a MediaWiki telepítőjével hozod létre, egy második szerverről való elérhetőség érdekében lazább szabályok lesznek érvényben. Fontold meg ezek szigorítását, vagy győződj meg róla, hogy a felhasználó csak a szükséges helyekről érhető el; a fióknak csak a SELECT, INSERT, UPDATE és DELETE jogosultságokra van szüksége. You might consider manually narrowing this or establishing the user account yourself with custom permissions from just the places you need. The database user only needs to have SELECT, INSERT, UPDATE and DELETE permissions for the database.

A biztonsági problémák egy oka a FILE privilégium megléte; győződj meg róla, hogy az adatbázis-felhasználó nem rendelkezik sem ezzel, sem más adminisztrációs jogosultságokkal.

Vedd figyelembe, hogy az adatbázis  táblájában a jelszavak hash-értéke, illetve néha e-mail-címek is megtalálhatóak, így ezeket személyes adatként kell kezelni.

Karbantartószkriptek
A Special:MyLanguage/Manual:Maintenance scripts használatához érdemes egy adatbázis-adminisztrátori fiókot létrehozni. Ehhez a következő változók beállítása szükséges:



A szükséges MySQL/MariaDB-jogosultságokhoz lásd a Kézikönyv:Karbantartószkriptek#Konfiguráció szakaszt.

A MediaWiki frissítése
A frissítés során több MySQL/MariaDB-jogosultságra lehet szükség.

A MySQL-ről és a MariaDB-ről bővebben

 * mysql command-line options.
 * A  my.ini-ben történő beállításával (  szakasz) az adatbázis csak a loopback interfész felől érkező kérésekre reagál; ez a Windows alatti EasyPHP-konfiguráció alapértelmezése. (Ha a MySQL/MariaDB Unix alatt lett telepítve, a beállítás lehet, hogy a $cnf állományban található $skip-net néven.) This is the default in the EasyPHP install for Windows. (If you are using MySQL/MariaDB on a Unix machine, the setting may be   instead in the my.cnf file.)
 * GRANT- és REVOKE-szintaxis

Ha az adatbázis kiszivárgott
Ha az adatbázis kiszivárgott, a LocalSettings.php-ban:


 * 1) Változtasd meg a $wgDBpassword-öt annak kiszivárgása esetén
 * 2) Változtass meg néhány betűt a $wgSecretKey-ben
 * 3) Nullázd a user_token oszlopot a user táblában, így ezekkel nem követhetőek vissza felhasználóid.

Ha a LocalSettings.php kiszivárgott
Ha a LocalSettings.php kiszivárgott, gondoskodj a védelméről és:


 * 1) Változtasd meg a $wgDBpassword-öt
 * 2) Cseréld le a $wgSecretKey értékét véletlenszerű, betűkből és számokból álló sztringre
 * 3) Készíts új $wgSpamRegex-et (opcionális)
 * 4) Nullázd a user_token oszlopot a user táblában, így ezekkel nem követhetőek vissza felhasználóid.

Adatbázis-jelszavak
Lásd a lapot a fontolóra veendő elővigyázatossági lépésekről, hogy elkerüld a MySQL/MariaDB-jelszavak interneten való megjelenését.

Alternatív fájlelrendezés
A MediaWiki úgy lett tervezve, hogy kicsomagolás után helyben fusson. Ez kényelmes, azonban csökkentett biztonsághoz és fájlduplikációkhoz vezethet.

A fájlduplikációkat az állományok elhelyezésével lehet megszüntetni.

Az includes és skin fájlok átmozgatása különös elővigyázatosságot igényel; a műveletekhez szükséges a -ban található   megváltoztatása. Ez csak tapasztalt felhasználóknak ajánlott.

A biztonság növelésekor vedd figyelembe, hogy a  az aktuális könyvtárat használja, így az   beállítása esetleg nincs hatással a biztonságra.

Érzékeny adatok mozgatása
Vedd fontolóra az adatbázis-jelszó és más érzékeny adat átmozgatását a -ból más, a gyökérkönyvtáron kívüli helyre, majd erre az   segítségével hivatkozz a  -ban. Ezzel megbizonyosodhatsz arról, hogy egy esetleges webszerver-hiba miatti PHP-leállás esetén nem jelenik meg az adatbázis jelszava a szövegesen megjelenő állományban. This can help to ensure that your database password will not be compromised if a web server configuration error disables PHP execution and reveals the file's source text.

Ehhez hasonlóan a  szerkesztése biztonsági mentést hagy a módosított kiterjesztéssel, így az egyszerű szövegfájlként lesz elérhető (például  ). Ha ilyen szerkesztőt használsz, tiltsd le a biztonsági mentést vagy az érzékeny adatokat ne a gyökérkönyvtárban tárold. If you use such an editor, be sure to disable backup generation or move sensitive data outside the web root.

A MediaWiki hibakeresési naplói szintén tartalmazhatnak érzékeny részeket. Győződj meg róla, hogy illetéktelenek és a nyilvánosság nem férhet hozzá ilyen állományokhoz, valamint töröld a naplófájlokat, ha már nincs rájuk szükséged, a -ban pedig a vonatkozó sorokat tedd megjegyzésbe vagy töröld.

A DocumentRoot /dev/null-ra állítása
Az Apache-szerver biztonságosabbá tételéhez a  egy üres vagy nem létező könyvtárra mutasson, majd az  -direktivákkal csak azon szkriptek és mappák látszódjanak amelyeknek kívülről elérhetőnek kell lenniük.

Betöltőszkriptek
A bármely webszerverrel működő PHP-alapú megoldáshoz egy specifikus könyvtárra mutató -szkriptsorozatot kell létrehozni, amely egy vagy több forrásfájlt igényel, például:

Felhasználói biztonság
Mindenki, aki módosíthatja a MediaWiki rendszerüzeneteit, HTML- és JavaScript-kódot helyezhet el a lapok kimenetén; ezek az editinterface jogosultsággal rendelkezők és bárki, aki írási joggal rendelkezik az adatbázis szövegtáblájához. This includes wiki users who have the editinterface permission, as well as anyone with direct write access to the text table in the database.

A HTML számos rendszerüzenetben tiltva van, főképp a bejelentkezés során megjelenő lapokon, így a JavaScript-alapú jelszólopás valószínűsége minimális. Továbbra is előfordulhat kártékony kód beillesztése a böngészők biztonsági résein át (például kémprogramok telepítésével), így csak megbízható emberek kapjanak interfész-szerkesztői jogot. Malicious code could still attempt to exploit browser vulnerabilities (install spyware, etc.), though, so, you should make sure that only trusted people can modify system messages.

Feltöltési biztonság

 * Lásd még:

A fő kérdés: Hogyan akadályozhatjuk meg kártékony állományok feltöltését?

A fájlfeltöltés a MediaWiki opcionális eleme, és alapértelmezésben le van tiltva; ha engedélyezed, szükséges a webszerver által írható tárolómappa létrehozása.

Ennek számos biztonsági következménye van:
 * A feltöltési könyvtár bárki által-, vagy csak a webszerver felhasználója által írható is lehet. Többfelhasználós rendszereken ez lehetőséget ad kártékony állományok elhelyezésére (lásd a vonatkozó információkat fentebb).

Ha lehetséges, a mappa csak a webszerver által legyen írható.
 * The directory may have to be world-writable, or else owned by the web server's limited user account. On a multiuser system it may be possible for other local users to slip malicious files into your upload directory (see multiuser notes above).
 * Míg a PHP-konfiguráció korlátozza a feltölthető méretet, a MediaWikiben nincs ilyen kontroll; egy kártékony célú vagy túlbuzgó felhasználó így egy a teljes partíciót megtelítheti.
 * A generált bélyegképek és a felülírás esetére tárolt feltöltött fájlok az images/thumb és az images/tmp könyvtárakban lehetnek, és ennek a MediaWiki felületén nincs látható nyoma. Tartsd szemmel ezek méretét is.

A szoftver alapértelmezésben próbálja a kártékony fájlokat visszaszorítani:


 * Alapértelmezésben a .png, .gif, .jpg és .jpeg kiterjesztések találhatóak meg a fehérlistén ($FileExtensions).
 * Számos futtatható fájl és szkript eleve feketelistázva van ($FileBlacklist) még akkor is, ha a felhasználók felülírhatják a fehérlistát ($StrictFileExtensions).
 * Több ismert képtípus kiterjesztésének ellenőrzése is a PHP $getimagesize funkciójával történik.
 * A feltöltött fájloknál ellenőrzésre kerül, hogy előidézik-e az Internet Explorerben és a Safariban jelen lévő típusfelismerési hibát, minek következtében HTML-szövegként jelennek meg.

Elővigyázatosságból érdemes a PHP-szkriptek (és más, általad használt szkripttípus) szerveroldali futását letiltanod a feltöltési könyvtárban (alapértelmezésben $images).

Például ha a MediaWikit a /Library/MediaWiki/web könyvtárba telepítetted, akkor ez az Apache .conf fájljában a következőképp valósítható meg:

Ha nincs elérésed az Apache konfigurációs fájljaihoz, de használhatsz .htaccess állományokat a beállítások felülírásához bizonyos könyvtárakban, akkor a feltöltési mappában helyezd el a következő tartalmú .htaccess állományt:

A te konfigurációd eltérhet, az használata megnehezítheti a feltöltések kezelését.

If you use any of the above solution, you can check whether it's really working with this simple test.


 * Create a 'test.php' file in the upload directory.
 * Put  in the file.
 * Visit the file path in a web browser. If you see just the text of the file you are good, otherwise something is wrong somewhere.

Megoldás Nginx esetén: http://serverfault.com/a/585559/162909

A legmagasabb fokú biztonsághoz a feltöltött állományokat külön domainen tárold. A teljes biztonsághoz ne külön aldomainen, hanem teljesen elkülönülő címen tárold a feltöltött fájlokat, habár előbbi is elég biztonságot nyújt. Ez akkor különösen fontos, ha engedélyezed az SVG-feltöltést, mivel ezek a HTML-hez hasonló fájlok. Ugyan a MediaWiki ellenőrzi a feltöltött SVG-ket, de sosem árt még egy védelmi réteg. Az eltérő domain beállításához lásd a $UploadPath lapot.

Külső programok

 * A  futtatható a szerkesztési ütközések eredményének összevonásához.
 * Ha az ImageMagick bélyegkép- vagy SVG-támogatása engedélyezett, a feltöltött fájlokon futtatható a.
 * A Math kiterjesztés engedélyezése esetén meghívja a -t, amely ugyanezt teszi a ,   és   funkciókkal (utóbbi a  -t hívja meg).

Lásd még

 * Általánosságban
 * Configuration Settings: Access
 * meta:Category:MediaWiki authentication
 * Tervezés/Szükségletek begyűjtése
 * Felhasználói azonosítás
 * AuthManager - – leírja a felhasználók identitását meghatározó plug-in felépítését
 * - – a plug-in felépítése által használt konfigurációs változó
 * - – elérhető hitelesítési kiterjesztések
 * - – MediaWiki-felhasználók jelszavának visszaállítása
 * A felhasználói tevékenység figyelése
 * Jogosultságok megadása IP- vagy identitás alapján
 * Access control
 * FAQ/Initial user was not created by installer
 * FAQ/Anti-spam
 * - – az alapértelmezett MediaWiki-jogosultsági architektúra konfigurációjának leírása
 * - – tippek és útmutatók
 * - – IP/felhasználó alapú korlátozások a képekkel kapcsolatban
 * - – a jogosultság-kezelésben segítő kiterjesztések
 * Konfigurációs változók:, , ,
 * Fokozott biztonságú MediaWiki-verziók/mintakonfigurációk
 * Biztonsági figyelmeztetések
 * - – hibajelentések módja, értesítések kérése
 * ModSecurity
 * Technikai részletek
 * database schema: User groups table, User table, Revision table, Recentchanges table
 * hooks:, , , ,
 * code:
 * - – jogosultságfüggő speciális lapok létrehozása.
 * Nyílt Webes Applikációk Biztonsági Projektje (OWASP)
 * Webapplikációk biztonsága – Szabályok (WAS)
 *  - – fejlesztőknek
 * ModSecurity
 * Technikai részletek
 * database schema: User groups table, User table, Revision table, Recentchanges table
 * hooks:, , , ,
 * code:
 * - – jogosultságfüggő speciális lapok létrehozása.
 * Nyílt Webes Applikációk Biztonsági Projektje (OWASP)
 * Webapplikációk biztonsága – Szabályok (WAS)
 *  - – fejlesztőknek