Tehát, mindenkinek ajánlott 2.8.4-re frissítés, aki bármelyik 2.8-as verziót használja.
A 2.7-es kiadási ág úgy tűnik nem érintett a hibában.

A javítócsomagot közvetlenül elérhetitek már az admin felületetekről, az Eszközök -> Frissítés menüpontból,
vagy közvetlenül a magyar csomagok lelőhelyéről a hu.wordpress.org-ról.

Mivel arra gondoltam, hogy így hajnal 5 körül úgy sincsen nagyon más dolgom, ezért a magyar telepítő csomagot is frissítettem ehhez a verzióhoz.

Aki némiképpen lustának érzi magát, hogy telepítse a teljes frissítést azzal megosztom, hogy mi változott:

• wp-includes/class-snoopy.php
• wp-includes/version.php

Ezenkívül, aki a telepítőcsomagot tölti le, az annak is örvendhet, hogy a legújabb Akismet 2.2.1 -et is a csomagban találja már, a friss magyar fordítással egyetemben.

Szokásosan ismét 2 verzióban érhető el, van egy nyelvi fájlos verziónk, és van egy telepítőnk. A nyelvifájlos verzió jelenleg 2 azaz kettő darab szóban tér el az előző 2.6.2-es változattól, szóval igazából csak azért készült, hogy ha már van telepítő, legyen nyelvi csomag is.

[dm]21[/dm]

[dm]22[/dm]

Egyébként a fordítócsapat jelenleg éppen önnön nagyszerűségét ünnepli, mivel szerdára elkészültünk, a WordPress 2.7 pre-beta teljes fordításával. Éles blogban is próbáltam már a 2.7 magyar verzióját, és a fordítás is zseniális, a szoftverről pedig inkább ódákat zengenék.

A megfelelő információk és a felhasználó név tudatában a lelkes hacker bárkinek leresetelheti a jelszavát. Maga a támadás a blogra nem veszélyes, de idegesítő lehet. A hiba főleg akkor lehet érdekes a számodra, ha a nyílvános regisztrációd nyitva van. Ebben az esetben feltétlenül frissítened kell.

A hiba technikai részletei jelenleg még nem nyílvánosak, ezért nem kell attól tartani, hogy az önjelölt hackerek végig másznak a világ több millió wordpress blogján. De a javítást célszerű telepíteni.

Frissítve!

[dm]20[/dm]

[dm]18[/dm]

[dm]17[/dm]

Úgy tűnik ebből egy cikk sorozat lesz, bár nem így indult. De most nem szeretnék egyszerre sok információt átadni.

Először egy-két biztonsági alap dolgot fogok firtatni. Majd a wp-admin könyvtár biztonságát érintő bővítményeket, és tippeket.

A cikk következő részében a content, azon bellül is a bővítmény és sablonok könyvtárak védelmét nézzük át. A harmadik rész pedig a 2.6 újdonságait mutatja majd be a biztonságra nézve, valamint az SSL támogatást és a biztonságos Cookie kezelés mikéntjét.

Általános dolgok

Frissítés

Nem győzzük hangsúlyozni a frissítések fontosságát. A WordPress fejlesztői nem a saját szórakoztatásukra adnak ki újabb és újabb verziókat. Vagyis annak érdekében is, de főleg hibajavító verziók érzkeznek újabban, annak érdekében, hogy kritikus réseket befoltozzanak.

Biztonsági mentés

Ennek a szerepéről is sokat beszélünk, de kevésbé alkalmazzuk, legalábbis ez a tapasztalatom. Te mikor csináltál utoljára teljes adatbázis mentést a blogodon található bejegyzésekből? És ezt utoljára mikor mentetted át külső adathordozóra, külső gépre?

Tudjátok nem is volt olyan régen az, amikor az egyik nagy szolgáltató szerver termében a szerverek nagyrésze a tápig vízben állt… Vajh, ha a te blogod egy olyan szerveren lett volna, mikor állhatott volna újra üzembe?

Adatbázis mentéshez használahatod a WordPress Database Backup névre hallgató bővítményt.

Nálam rendszeres, napi adatbázis mentés fut, de tanácsos időnként, mondjuk egy WordPress kompatibilis XML-be is akár kimenteni az adataidat, és ilyenkor könnyen importálható marad. Én néha be szoktam importálni a teljes blogom egy-egy WordPress MU alapú blog szolgátatóhoz, mint például a PirateBay blog szolgáltatása a BayWords.com.

Biztonságos kapcsolat

Amikor csak lehetőségünk van rá, a blogunkra SFTP-n vagy SCP-n keresztül töltsünk fel háttéranyagot, bővítményeket, új sablonokat. Mivel a sima FTP protokollon keresztül küldött adatok titkosítatlanul folynak. Oké, nem te vagy a NASA, hogy arra legyen kiváncsi bárki is, hogy milyen adatot töltesz fel. De mivan, ha mégis?

Egyébként tudtad, hogy a blogod admin felülete a 2.6-os verzió óta képes HTTPS alapon is működni? Erről bővebben majd a harmadik részben, fogok írni.

Fájl jogosultságok

Először is tanuljuk meg, mit jelentenek a unix rendszerek fájl jogosultsági maszkjai, utánna pedig nézzük meg, hogy a blogunk lényges fájljai milyen jogosultságokkal rendelkeznek.

Ha nem dedikált szerverünk, vagy dedikált VPS-ünk van, akkor ez különösen fontos. Természetesen egy szolgáltatónak minden tőle telhetőt meg kell tennie, az ügyfelek adatainak eszakálása érdekében, de mi is tegyük meg a magunkét, és állítsuk be megfelelően a fájlok és könyvtárak jogosultságát.

Admin könyvtár védelme

Az első és kézenfekvő megoldás, a .htaccess alkalmazása IP címre, tartományra szűkítéssre, amennyiben ez megoldható. Nyilván nem járható út, ha az internet szolgáltatód mindig más IP tartományból oszt neked IP-címet.

(Két évvel ezelőtti tapasztalataim alapján a T-onlány képes volt egymás után kiosztani olyan IP-címet, amiben nem volt közös tag. Azaz minden tartomány különbözött, ilyenkor ez a megoldás nem alkalmazható.)

A htaccess fájlok használatának a lehetőségét a szolgálattód tudja engedélyezni, erre nem létezik “meghekkeljük phpből” jellegű megoldás.

Az IP címre szűkítés egyébként ideális lehet, egy fix irodai IP-címmel rendelkező szerkesztőségnek bejegyzéseket írni a céges blogra. Ennek a mikéntje annyiban merül ki, hogy a wp-admin könyvtár gyökerében létrehozunk egy .htaccess fájlt, hasonló tartalommal:

Order deny,allow
Deny from all
allow from xx.xx.xx.xx

Nyilván a xx.xx.xx.xx cseréljük a pontos IP-címünkre.
Használhatóak még a következő formák is:

- 10.1.0.0/16
- 10.1
- nitro.glicer.in
- nsa.gov
- .gov

AskApache

Az admin hozzáférés korlátozására nyilván vannak még más módja is. Talán az egyik legismertebb, az AskApache bővítmény, amit arra szokás használni, hogy egy plusz biztonsági szintet emeljen a login oldal elé, vagyis, már a login oldalra bejutáshoz is egy standard HTTP authentikáción kell átmennünk.

De ennél jóval többet tud az AskApache, tartalmaz nyilvános proxyk elleni védelmet, különböző spam filter modulokat (referer ellenőrzés, trackback spam szűrés, UserAgent ellenőrzés, Content-Length vizsgálat, Content-Type vizsgálat…), exploit elleni védelmek (directory traversal, illegális karakter formázások, nem standard HTTP parancsok…), valamint tárolja a jelszó fájlok korábbi állapotait. Ugye milyen kis aranyos?

WP Security Scan

Az All-in-One SEO Pack jelenlegi karbantartójának egy régebbi bővítménye, ami átvizsgálja a fájl és könyvtár jogosultságokat, a jelszavakat, és az adatbázist gyenge pontok után kutatva. Valamit segít elrejteni a szoftver verzióját, és eltávolítja a Generator META tagot az oldal fejlécéből.

Login LockDown

Arra szokás használni, hogy megakadályozza az esetleges brute force jellegű támadásokat a login oldal ellen. Az alap beállításban 5 percen bellül 3 sikertelen bejelentkezési kísérlet után 1 óra bünti jön, és csak utánna próbálkozhatunk újra belépni, miután felkeltünk a sarokból a kukoricán térdelésből.

A sikertelen bejelentkezési kísérleteket ezen kívül még naplózza is.

Nos, ma eddig jutottunk, hamarosan (valószínűleg a jövőhéten) folytatás következik.

Igen, ez egy erősen negatív díj, úgy érzem Matt blogja, ezt nem fogja főoldalon hozni

Ez a dolog számomra rávilágít a frissítések fontosságára. Úgy érzem nem véletlenül centralizálják a frissítéseket a srácok az Automatticnél, szeretnék, ha minnél biztonságosabb rendszert használhatnánk.

Egyébként megnéztem a pwnie-awards.org által linkelt biztonsági oldalon a hibák számát, más népszerű PHP alapú keretrendszerekre. A joomla, a mambo és a phpnuke is sokkal több hibával rendelkezik a rendszerük szerint, mint a WordPress. Egyedül a drupal volt jobb, 1, azaz, egy hibával találtak benne kevesebbet.
Még viccből megnéztem az Apache webszervert, és a Firefoxot. Bennük háromszor annyi hibát találtak, a Microsoft Internet Explorerben, pedig hatszor ennyit.

Nem, most nem arra gondolok, hogy a félszemű a vakok közt a király, csak gondoltam egy kis összehasonlítási alapot keresek.

Szóval akkor mi is tanulság?
Annyi, hogy upgrade, upgrade, upgrade!
A rendszert, a bővítményeket, és a sablont!

• Jelszó újraküldés felhasználókénti tiltása
• A lekérdező funkció, ezentúé vesszúvel elválasztott listát is elfogadnak a post_status paraméterre
• Még több automatikusan generált link fel lett készítve az SSL kompatibilitásra
• Atom feedet is lehet hírdetni az alapértelmezett sablonban
• Az Atom API a legújabb bejelentkezési funkciókat használja
• Egy objektum cachelési hiba javítás, a bővítmények frissítésénél

phpMyAdmin

Amennyiben rendelkezünk phpMyAdmin hozzáféréssel, akkor ide jelentkezzünk is be, a wp-config.php-ban megadott adatbázis elérési adatokkal. Válasszuk ki azt az adatbázist, amelyben a blogunkat telepítettük, a bal oldalon listázott elérhető adatbázisok közül.

Majd, itt válasszuk ki a felhasználói adatokat tartalmazó táblát, amely valószínűleg wp_users, de mivel egyéni prefix beállítására is lehetőség van telepítés közben, így ismét a wp-config.php fájl, $table_prefix nevű változója tud felvilágosítást adni arról, hogy milyen előtag szereplet a users megnevezés előtt.

A tábla kiválasztása után a Tartalom fülre kattintva keressük meg a nekünk kellő felhasználót, ami valószínűleg az első sor lesz és ahol az ID oszlop egyes (mivel normál körülmények között ezt a felhasználói fiókot nem lehet törölni.)

Majd, kattintsunk rá ebben a sorban a ceruzát formázó, és szerkesztést jelentő ikonra. Ez után valami hasonló kép fog fogadni minket. A három lényeges tulajdonság eredeti színekkel van ábrázolva, minden mást ami a lényeg szempontjából számunkra teljesen lényegtelen, ki szürkítettem:

Szóval a user_pass mezőnél válasszuk ki az MD5 funkciót, semmi más nem jó, (tehát sem PASSWORD, sem ENCRYPT, sem SHA1). Majd mellé az érték mezőből töröljük ki a benne lévő adatot, és írjuk bele az új jelszavunkat.

Ezután a táblázat láblécében lévő végrehajtás gombra taposva, a beállítást végre is hajtódott.

Kézi SQL

Ha nem phpMyAdmint használunk, hanem valami natív SQL elérést (MySQL Administrator, SQLyog, stb.), esetleg saját szkriptet szeretnénk írni, amig nem készül el a javítás, akkor a következő SQL utasítást kell eldurrantanunk:


UPDATE `blog`.`wp_users` SET `user_pass` = MD5('valamijelszo') WHERE `wp_users`.`user_login` =`admin` LIMIT 1;


Szerencsés bejelentkezés után a blogmotorunk a jelszót átkonvertálja a phpass metódussal egy biztonságosabb titkosítású karaktersorozattá.

(A bejegyzés Ryan McCue angol nyelvű cikke alapján készült)

Ami azért kritikus csak, mivel az md5 hash ismeretében admin jog szerezehtő a WordPress Cookie authentikációs methódusának ismeretében, amire az előző bejegyzésben is hivatkoztam.

A megoldással kapcsolatban írtam egy rövid cikket, amit itt syntax highlighter hiányában nem tudok publikálni.
De elérhető magyarul itt, angolul pedig itt.

Ez a hiba felhasználható arra, hogy az adatbázis nem nyilvános részeit megtekintse a rosszindulatú látogató, illetve kombinálva az egy hónapja talált cookie authentikációval hibával, akár adminisztrátori jog is szerezhető.
A biztonsági oldalak a hibák közepesen veszélyesnek tartják.

Mennyire is kell félned neked, kedves blog tulajdonos?
Hiba csak azoknál a karakter kiosztásoknál létezik, ahol a backslash karakter egy multibyte karakter definició része lehet (big5, gbk). Amennyiben utf-8, latin-1 vagy latin-2 karakterkiosztást használsz a hiba téged nem érint.

Melyik verziókat érinti a hiba?
A karakter kód változtatásra a WordPress 2.2-es verziójától van lehetőség, így az annál korábbi verziók nem veszélyeztetettek, de az összes további, (beleértve a jelenlegi verziót is) igen.

Mit tudok csinálni akkor ha érint a hiba?
Jelenleg két járható út:

• adatbázis karakter készlet konverzió utf-8-ra
• amíg nem érkezik a hibára javítás a keresési lehetőséget távolítsuk el a témánkból