A WordPress-nek van egy hivatalos konfigurációkövetelménye, amelyet ha betartunk a használat során, akkor nem merül fel semmilyen probléma. A gondok ott (is) kezdődhetnek, ha a használt szerver ezen elvárásoknak nem felel meg.

De nem csak a WordPress, hanem pl. az egyes bővítmények is “megkövetelhetik” a szerveren használt php verzió minimumát.

Ha valamelyik bővítmény nem működik tökéletesen, első körben semmi gond: van egy remek bővítmény, amellyel az összes aktív és inaktív (bár ezeket inkább töröld!) bővítményt le lehet tesztelni különféle php verziókkal való kompatibilitás szerint. Ha találsz olyan bővítményt, ami a használt php verzióval nem működik tökéletesen, akkor két dolgot tehetsz: vagy megválsz a bővítménytől, vagy olyan php verzióra válta(t)sz, amellyel kompatibilis (ha ez nem okoz gondot más bővítménynél és/vagy nem tartalmaz biztonsági rést).

Bonyolultnak tűnik?
Nem az! Egy közel 6 perces videón megmutatom a fentieket a gyakorlatban.

    

GYORSHÍR!
Megjelent egy fontos frissítés, amely visszamenőleg – a 3.7-es WordPress verzióig – minden verzióban megtalálható sérülékenységet javít. Érdemes tehát frissíteni a szokásos módon.

További részletek:
wordpress.org/news/2018/07/wordpress-4-9-7-security-and-maintenance-release/

A vírusírtás alapok című cikkemben körbejártam, hogy mit kell tenni akkor, ha már megtörtént a baj. Azóta (2018. májusában) történt egy olyan eset, amely mellett nem tudok szó nélkül elmenni. Az egyik ügyfelemnek (ráadásul TOP20-as ügyfélről van szó) megfertőzték a weboldalát, de olyan módon, hogy az ékezetes karakterek helyére (mind helyére ugyanaz) kriksz-krakszok kerültek, és azokat hexaeditorral sem lehetett normális módon helyreállítani.

Mi vezetett idáig, mi volt a megoldás? Miért volt extrán peches az ügyfél? Hogyan lehetett volna enyhíteni a károkat előrelátó módon?

A helyreállítás sokkal könnyebb lehetett volna, ha pár helyen szerencsésebben alakulnak a körülmények. De ahogy a sportban sincs “ha”, úgy itt sem volt sajnos.

Azonnali jelzés – FONTOS!

Az első és legfontosabb hasonló esetben, hogy AZONNAL jelezni kell azt, ha ilyet tapasztalunk a weboldalon. Sokszor volt már olyan, hogy “azt hittem csak ideiglenes hiba, és megoldódik”. Magától az esetek többségében nem fog megoldódni a probléma, sőt, csak nagyobb bajt okozunk vele. Mint itt is. Amikor az ügyfél jelezte, hogy mi van az oldallal, mondta, hogy már 2-3 hete ilyen az oldal, akkor szóltak neki. Csak a gond ezzel az volt, hogy a tárhelyszolgáltatónak 2 hétre visszamenőleg volt mentése, így a tartalmak – azonnali jelzés esetén – 100%-osan helyreállíthatóak lettek volna. De így pont akkor lett jelezve a baj, amikor már a tárhelyesnek is csak vírusos állapotról volt mentése.

Itt volt még egy kör a tárhelyessel, mert azt mondta, hogy minden év végén készítenek egy biztonsági mentést, és azt egy széfben tárolják. Erre több mint két hetet vártunk (részben azért, mert nem fért hozzá, részben azért, mert pont szabadságra mentem egy hétre), amikor kiderült, hogy 2017 végén nem készült ilyen mentés, csak 2016-ban.

Amíg ez ki nem derült (illetve amíg szabadságra mentem), egy 2017. márciusi állapotot állítottunk vissza.

Miért kellett biztonsági mentés, nem lehetett volna leírtani a vírust az oldalról?

A tartalmak olyan mértékben sérültek, hogy erre sajnos nem volt mód.

Legyen havi biztonsági mentésed!

• A következő dolog, hogy legalább havonta készüljön biztonsági mentés a weboldalról.
• Amikor elkészül egy biztonsági mentés, az legyen elmentve tömörítve és kicsomagolva is. Ezt korábban nem kommunikáltam eléggé, ezért frissült az erre vonatkozó levelem is, hogy erre külön felhívjam a figyelmét a mentést kapó ügyfeleknek.
• Ha készül egy újabb mentés, a RÉGI mentések AKKOR SE legyenek törölve.

Itt bonyolította a dolgot, hogy tavaly novemberben készült biztonsági mentés az oldalról, de az ügyfél hibásan tárolta (nem futott végig a kicsomagolás, és az általam küldött zip fájlt pedig törölte – ergo használhatatlan volt).

A mentéseket én 7 napig tárolom, így nálam sem volt meg a novemberi mentés. Ha lett volna havi mentés, akkor max. egy hónapnyi tartalom veszik el és/vagy sokkal könnyebb a helyreállítás.

De szerencsére volt egy 2018. márciusi mentés, abból lett helyreállítva a weboldal váza. Azért írom így, mert az azóta eltelt több mint 400 napban számtalan cikket írt az ügyfél, és rengeteg módosítást is eszközöltünk a weboldalon. 60+ oldalas levelezést gyűjtöttem össze az ügyféltől ezen 400 napról, ezen (mint fejlesztési lista) végig kellett rágnom magam a tökéletes helyreállításhoz.

A havi mentések készítése plusz pénz (vagy egyszer meg kell tanulni, és becsülettel elvégezni havonta), de ha szükség van rá, akkor rengeteg időt és pénzt lehet megspórolni a felhasználásukkal.

Mi történjen két mentés között?

Ha havonta készül biztonsági mentés, mondhatjuk, hogy akkor történhet adatvesztés. Ennek megelőzésére, saját oldalaknál a következőt alkalmazom: Ha írok egy cikket, akkor a HTML nézetből (hogy a formázás is meglegyen) ki szoktam másolni a forráskódot egy jegyzettömbbe, és elmentem. Ez azért jó, mert a tartalom hiánytalanul rendelkezésre áll később. Ha kép is került a cikkbe, azt is egy külön mappában (“backupig” a neve) tárolom a következő biztonsági mentés készítéséig.

Kinézet megmentése:

A kinézetben végzett módosítások egy export-import fájllal menthetőek voltak, így ez nem volt nagy gond.

Tartalmak megmentése: 

A legfontosabb szempont ilyen esetben mindig a tartalmak megmentése. A tartalom nélkül nem ér semmit a weboldal, és azt a legnehezebb rekonstruálni (újraírni). A korábbi cikkek (157 db), oldalak (13 db) tartalma végül 95,3%-osan helyre lett állítva. Ahhoz képest, hogy 400+ napos mentés állt rendelkezésre, szerintem nem rossz arány. A helyreállítás során több helyről lettek kinyerve adatok: részben korábbi mentésekből, részben archive.org oldal használatával, részben pedig a WordPress revision fájljaiból való kimazsolázással. 8 olyan cikk volt, amit sehonnan nem tudunk megmenteni, ezért azokat újra kell gépelni. Illetve a meglévő cikkek, oldalak 400 napja eszközölt változtatásai elvesztek, és kb. 30-40 cikk formázása, címkézése, kategorizálása, SEO-zása (vegyesen, hol mi, attól függ, honnan lett helyreállítva) is odalett. Ezeket ismét be kell majd állítani.

Mivel úgy volt, hogy a tárhelyesnek van év végi mentése, ezért csak az idei megmenthető cikkeket mentettem le a weboldalról. Amikor kiderült, hogy mégsincs ilyen, akkor a vírusos verziót egy másik tárhelyen össze kellett raknom, hogy további tartalmakat menthessek onnan.

Mi volt a probléma?

Sajnos erre nem derült fény. Nagyrészt teljesen azonos konfigurációt használ sok más, érintetlen weboldallal.

• De más tárhelyen van a weboldal, lehet, hogy ott volt valamilyen gond.
• Az ügyfél telepített jópár olyan bővítményt, ami már elavult.
• Néhány admin felhasználónak “kismacska” szintű gyenge jelszava volt.

Ezeket orvosoltam, és már van az oldalon WordFence is, valamint egyéb biztonsági bővítmény is, így hasonló esetnél sokkal gyorsabban fogunk tudni reagálni. Illetve lett feltelepítve olyan bővítmény, amivel az ügyfél egy kattintásra tud biztonsági mentést készíteni a weboldalról.

Lehetett volna nagyobb baj?

Igen, ha nincs ~400 napos biztonsági mentés, akkor sokkal nagyobb baj lett volna. De így is több, mint 13 munkaórám ment el a teljes helyreállításig. Igaz, ez a nagy szám annak is betudható, hogy az elmúlt 400 nap fejlesztéseit is újra végig kellett csinálnom.

Tegnap adták ki a WordPress 4.9.5 verziót, amely egy fontos biztonsági és karbantartó frissítés. Olyan sérülékenységet is javít, amely egészen a WordPress 3.7 verzióig visszamenőleg minden verzióban megtalálható.

Összesen 3 biztonsági hiba és 25 egyéb apróság lett javítva. Erről több infót itt találsz.

Érdemes tehát felkeresni a “Vezérlőpult” => “Frissítések” menüpontot, és elvégezni a frissítést. Előtte érdemes biztonsági mentést készíteni.

Forrás, részletek:
https://wordpress.org/news/2018/04/wordpress-4-9-5-security-and-maintenance-release/

Véleményem szerint minden weboldal tulajdonos egyik rémálma az, ha megfertőzik a weboldalát. Ilyenkor jön a pánik, a kétségbeesés, hogy mit tegyek? Mi veszett el? Van mentés? Mutatom a kiutat a bajból!

Helyreállítás biztonsági mentésből

Ha van biztonsági mentésed, szerencséd van. Vagy csak lehet. Miért? Mert lehet, hogy olyan biztonsági mentésed van, amely már a szintén fertőzött weboldalról készült. Vagy régi a mentésed és/vagy sok módosítás történt a weboldalon, amelyet nem akarsz elveszíteni egy mentésből történő visszaállítás során. Ha sikerült ez alapján helyreállítani a weboldaladat, jöhet a védelem megerősítése!

Ha nincs biztonsági mentésed…

Ha ez az eset áll fenn, akkor manuálisan kell eltávolítani a vírusokat a weboldalról. Ez sajnos nem minden esetben olyan egyszerű, mert van olyan, hogy rengeteg, egymástól független helyen elérhető fájlokat is megfertőz a vírus.

Mik egy vírusos weboldal ismérvei?

• Lehet, hogy a tárhelyszolgáltatód értesít, hogy spamelésre használják a weboldaladat.
• Lehet, hogy egy biztonsági bővítmény (pl.: WordFence) értesít a fertőzésről.
• Lehet, hogy pl. a Google vagy a Facebook hirdetési rendszere utasítja el a hirdetésedet, mellette jelezve, hogy ennek oka az, hogy a weboldal vírusos.
• Lehet, hogy a Google kiírja, hogy nem biztonságos meglátogatni az oldalt.
• Lehet, hogy a Google Search Console-tól kapsz értesítést, hogy vírusos a weboldalad.
• Lehet, hogy a böngésződ írja ki, hogy vírusos a weboldal, és nem is engedi megnyitni.
• Lehet, hogy nem tudsz belépni az admin felületre.
• Lehet, hogy nem is érhető el a weboldal.
• Lehet, hogy teljesen törlésre került a weboldal.
• Lehet, hogy minden oldallekéréskor más weboldalra irányítódik át a látogató a weboldaladról. Ennek a “sunyibb” verziója, amikor csak akkor kerül át a látogató más weboldalra, ha a Google-ből (vagy éppen ha mobilról nézik az oldalt) érkezik az oldalra. Ezt nehezebb azonosítani, mert egy weblap tulajdonos általában nem a Google-ből nyitja meg a weboldalát.
• Spam szövegek, viagra reklámok jelennek meg a weboldalon. Akár az eredeti tartalom mellett, vagy annak a helyén.
• Az IP címed feketelistára kerül, és a kiküldött e-mailjeid sem érkeznek meg a címzettnek.

Kik és miért fertőzik meg a weboldaladat?

A legritkább esetben állnak konkurensek egy ilyen támadás mögött, tehát felesleges is feltenni a következő kérdést: “Kis cég vagyunk, ugyan ki törné fel a weboldalunkat?” Ugyanis a támadások többsége mögött automatizált támadás áll, amely minden olyan weboldalt feltör és megfertőz, ahol felleli az éppen aktuálisan tesztelt sérülékenységet, kiskaput. A támadások célja sokszor a spammelés, de néha egyszerűen csak egy magát próbálgató kezdő hacker is lehet a háttérben.

Mi lehet a támadások forrása?

• Tárhelyszolgáltató hanyagsága. Ez akkor fordulhat elő, ha pl. nem megfelelő a tárhely védelme és/vagy a tárhelyen lévő domainekhez tartozó weboldalak nincsenek egymástól jól elkülönítve, így akár az is lehet, hogy emiatt egy másik weboldalon keresztül fertőzik meg a te weboldaladat. De további probléma lehet a szoftverek elavultsága, vagy éppen a rendszergazdai jogosultságok nem megfelelő őrizete is.
• Nem frissített WordPress, bővítmény és kinézetek. Írtam erről egy cikket, összeszedtem pár olyan végeredményt, amelyet el lehetett volna kerülni, ha frissítik a weboldalakat.
• Torrentről letöltött kinézeteken vagy bővítményeken keresztül. Érdemes megvenni 20-100$-ért azt a kinézetet, amelyet használsz!
• A felhasználók hanyagsága, pl.: nem megfelelő jelszó, vagy annak nem megfelelő tárolása. Vagy éppen olyan személyre bízása, aki nem szolgált rá erre a bizalmas jogkörre.
• Az előzőekből több szempont együttes kombinációja is vezethet vírusos weboldalhoz.

Hogyan állj neki a vírusírtásnak? Mik a főbb lépések a tiszta weboldalhoz?

• Minden, az oldallal kapcsolatos jelszavadat változtasd meg. (FTP, cPanel, WP admin [minden felhasználónak!], MySQL, e-mail cím, stb.)
• Ha volt mentésed, ha nem, mindenképpen készíts egy biztonsági mentést a weboldalról. Igen, így, a fertőzött állapotról. Lehet, hogy jól jön még.
• Ha nem tudod, hogy mit kell eltávolítani a weboldalról, futtass egy keresést a Sucuri SiteCheck eszközzel, valamint a Virustotallal. Ezek sok esetben megmondják, hogy mi a gond az oldallal.
• A WordPress telepítőjével manuálisan írd felül (illetve először töröld a régi fájlokat, mappákat, és utána másold fel az újat) a tárhelyen lévő WordPress fájljait.
• Ellenőrizd a root könyvtárat, hogy nincs-e olyan fájl ott, amely nem odavaló.
• Ellenőrizd a wp-config.php és .htaccess fájlokat, hogy nincs-e olyan sor (akár base64-el kódolva) benne, amely nem odavaló.
• A wp-config.php fájlban változtasd meg a titkosító kulcsokat. Generátor ehhez.
• Ellenőrizd a kinézet és bővítmények fájljait, hogy nem módosították-e valamelyiket az eredeti verzióhoz képest.
• Töröld az összes nem használt kinézetet és bővítményt.
• Ellenőrizd a teljes wp-content mappát. Igen, ez sziszifuszi munka, de sokszor itt is vannak vírusos fájlok.
• Az előző pontokhoz: érdemes lehet figyelni a tárhelyen lévő fájlok módosítási dátumát. Sokszor ezt vizsgálva szembetűnnek a módosított fájlok. Más esetben pedig nem mész semmire ezzel a módszerrel, mert vannak már olyan vírusok, amelyek véletlenszerűen megváltoztatják a fájlok módosítási idejét, így ez alapján nem fogod tudni kiszűrni az utoljára módosítottakat.
• Ha nem tudod, hogy mit nézz benne, állítsd vissza az oldal eredeti .htaccess fájlt. Ha valamelyik bővítmény módosította már, az adott bővítmény beállításait ismét el kell végezni.
• Ha be tudsz lépni az oldalra, ellenőrizd, hogy nincsenek-e olyan felhasználók, akikről nem tudsz. Ha vannak, töröld mindet.
• Nézd meg a bejegyzéseket és oldalakat, hogy csak olyan tartalmak vannak-e, amelyeket te hoztál létre.
• Nézz bele a tartalmakba is. Van olyan, hogy oldalak vagy bejegyzések html nézetébe kerül be kártékony kód.
• Ellenőrizd, hogy a használt bővítmények nem szerepelnek-e a WPSCan Vulnerability Database-ben. Ha valamelyiket megtalálod itt, azonnal töröld.
• Nézd át a logfájlokat.
• Ha nagyon tönkretették a weboldalt és/vagy nincs biztonsági mentés, jobb döntés lehet a fenti procedúra helyett, ha egy friss WordPress telepítésbe beimportálod a tartalmakat, és újra felépíted a weboldalt.

Amire ide eljutsz, jó eséllyel vírusmentessé tetted a weboldaladat. Ha mégsem és/vagy visszafertőződik az oldal, akkor nem volt teljes körű a munka, ismét mindent el kell végezni.

Ezek után ne felejtsd el a Search Console-on keresztül jelezni a Google-nek, hogy megtetted a weboldal vírusmentesítéséhez szükséges lépéseket.

További ellenőrzőeszközök:

• A bővítmények ellenőrzéséhez: Anti-Malware Security and Brute-Force Firewall
• WordFence: átfogó ellenőrzőeszköz. Sok oda nem illő dolgot meg lehet vele találni. Képes jelezni a fájlmódosításokat, így az utólagos védelemben is nagy szerepe lehet.
• All in One WordPress Security and Firewall plugin: én ezt használom, rengeteg biztonsági szempont szerint állítható a weboldal védelme. (fontosak, pl.: belépő oldal átnevezése, regisztrációk manuális engedélyezése, login captcha, belépési próbálkozások korlátozása, fájlrendszer monitorozása, stb.)

Amire még érdemes általánosságban figyelni:

• Ne “admin” és ne a weboldal címe legyen az adminisztrátori hozzáférés felhasználóneve.
• Mindig min. 13 karakteres, kis- és nagybetűt, számot és speciális karaktert is tartalmazó jelszót használj minden helyen.
• Egy jelszó ne legyen két helyen használva.
• Max. 30 naponta változtass mindenhol jelszót.
• A számítógépedet is védd a vírusoktól.
• Ne tört Windows-t használj.
• Ne tárold Total Commanderben az FTP jelszót.
• Töröld az xmlprc.php fájlt a tárhelyről.
• A wp-config.php fájl ne legyen elérhető kívülről!
• Ha nem használod, kapcsold ki a hozzászólás funkciót.
• A fájlok, mappák jogosultságát megfelelően állítsd be!
• Töröld az admin felületről a bejelentkezési hibaüzeneteket.
• Egy adatbázist csak egy WordPress oldal használjon. Más se használja ugyenezt az adatbázist.
• Ne wp_ legyen a táblák előtagja. (bár szinte mindegy, mert nem emiatt fogják feltörni az oldalt)
• Ne tárold böngészőben a weboldal jelszavát.
• Minél kevesebb, és megbízható forrásból származó bővítményt használj a weboldaladon!
• A mappák listázása ne legyen engedélyezve a szerveren.
• Ne a felhasználónév legyen a felhasználóknál a megjelenő név a weboldalon.
• Használj min. 7.2-es php verziót a weboldalhoz.
• Tüntesd el a forráskódból a WordPress verziót megmutató részeket. (csak laikusok ellen véd, enélkül is meg lehet mondani egy oldalról, hogy milyen WP verziót használ)
• Ha webshopod van, használj https tanúsítványt is.
• Legyen letiltva a forráskód-szerkesztési lehetőség az admin felületen.

Hogyan védekezz a jövőbeli vírusok ellen?

• Mindig minden frissítést végezz el! WordPress, bővítmény, kinézet: mindet!
• Mindig legyen biztonsági mentésed a weboldalról! Ezt lehet akár automatizált eszközzel is végezni, bár én jobban hiszek a manuális mentésben. Soha nem mondd azt, hogy nem csinálsz mentést, mert a tárhelyes úgyis csinál! És ha nem? És ha nem lehet használni? Akkor elveszett az évek munkájával felépített weboldalad? Ne ezen múljon!

Ha a fentiek után sem boldogulsz, keress meg, és segítek a vírusírtásban!

Tegnap megjelent a legújabb WordPress alverzió, a 4.9.2-es. Mindenkinek kiemelten fontos frissítenie a weboldalát, mert a WordPress 3.7-es ágáig visszamenőleg minden verziót érintő sérülékenységet (+21 apróságot) javít.

XSS sérülékenységet találtak a MediaElement könyvtárban. A MediaElement új verzióját, amely tartalmazza a javítást, el lehet érni a a MediaElement Flash Fallbacks bővítmény [letöltés] telepítésével is. (de ajánlott inkább frissíteni rendszert)

Frissítés előtt készíts biztonsági mentést a weboldaladról, majd a Vezérlőpulton, a Frissítés menü alatt végezd el a frissítést.

Verzió információk:
https://codex.wordpress.org/Version_4.9.2

Az alábbi posztot azért hozom létre, hogy legyen egy hely, ahol megnézheted a legújabb, WordPress-t érintő sérülékenységeket és a megoldásukat. Időről-időre frissíteni fogom, ha lesz újabb sérülékenység.

Sokszor kiderül, hogy egy-egy bővítményben találtak olyan kódot, amivel kárt tudnak tenni a weboldalban. Ezekről nem tudok mindig külön cikket írni, de ezt a cikket egy perc alatt tudom bővíteni, így ezen sérülékenységekről is hírt fogok tudni adni.

A sérülékenységeket alapvetően 3 módon lehet megszüntetni:

• Frissíteni kell a sérülékenységet tartalmazó bővítményt (vagy WordPress-t) olyan verzióra, amely már nem tartalmazza a hibát.
• Vagy törölni kell (nem elég kikapcsolni!) a bővítményt, és helyette keresni egy alternatívát. Miért kell törölni az ilyen bővítményeket? Mert erre szakosodott eszközökkel egy pillanat alatt megtalálni a kikapcsolt bővítményeket is.
• Komplett vírusírtással. Ha súlyos fertőzés érte a weboldalt, akkor csak ez segít. Ha szükséged van ilyenre, vedd fel velem a kapcsolatot!

Honnan értesülhetsz sérülékenységekről?

• WPScan Vulnerability Database – itt meg tudod nézni, hogy a weboldaladon használt bővítmények között van-e olyan (vagy olyan verzió), amelyben sérülékenység található.
• CVE Details
• Wordfence blog
• Jelen cikkből. Igaz, itt nem fogok mindenről beszámolni, azaz csak a nagyobb tömegeket érintő biztonsági résekről fogok írni.

Legújabb, sokak által használt WordPress bővítményekkel kapcsolatos sérülékenységek:

2017.12.19. – Captcha plugin

300 000 weboldalon használt bővítmény a Captcha. Backdoort találtak benne (a 4.3.6 verziótól a 4.4.4-es verzióig érintettek a felhasználók), amely jelen esetben azt jelenti, hogy a bővítményben talált sérülékenység miatt adminisztrátori hozzáférést tud szerezni az, aki ismeri a hibát, és tudja, hogy az adott weboldalon fent van ez a bővítmény. Azonnal töröld ezt a bővítményt! A probléma onnan fakadt, hogy a bővítmény eredeti tulajdonosa átadta másnak a fiókját, aki feltételezhetően szándékosan helyezte el a kártékony kódot a bővítményben, amely a frissítéssel minden weboldalra települt. A WordPress fejlesztői korlátozták a bővítmény tulajdonosának fiókját, és kiadtak egy olyan verziót (4.4.5), amely nem tartalmazza a hibát. És elvileg a bővítmény tulaja mostantól csak ellenőrzés után tud friss verziót kiadni a bővítményből. Én ettől függetlenül – a fentiek miatt – azt javaslom, hogy töröld ezt a bővítményt, és ha a szerzőtől (pl.: Covert me Popup, Death To Comments, Human Captcha, Smart Recaptcha, Social Exchange) használsz más bővítményeket, azokat is! Ajánlott alternatívák: Math Captcha | Captcha Code | Részletek, forrás

További alternatívák, amelyeket még nem használtam, de szimpatikusnak tűnnek első ránézésre:

• https://wordpress.org/plugins/login-recaptcha/
• https://wordpress.org/plugins/wp-conditional-captcha/
• https://wordpress.org/plugins/wp-captcha-booster/

2017.11.15. – YOAST SEO

XSS sebezhetőség az 5.7.1-es verzióban, és a korábbiakban. Frissíteni kell min. 5.8-as verzióra. Forrás

2017.11.07. – Duplicator bővítmény.

Az 1.2.29 előtti verziókban XSS sebezhetőség van. Érdemes frissíteni min. 1.2.29-es verzióra. Forrás

Kiadták a WordPress 4.8.2 verziót, amely minden korábbi verziót érintő sérülékenységet (főleg XSS és SQL injektálás terén) javít, így mindenképpen érdemes frissíteni a weboldaladat a “Vezérlőpult” => “Frissítések” menüpont alatt. A verzió 9 biztonsági frissítést, és 6 karbantartó frissítést tartalmaz.

Mi történhet, ha nem frissíted a weboldaladat?

Itt leírtam.

A befoltozott biztonsági rések:

Forrás: https://wordpress.org/news/2017/09/wordpress-4-8-2-security-and-maintenance-release/

Módosított fájlok:

1. wp-admin/about.php
2. wp-admin/edit-tag-form.php
3. wp-admin/includes/class-wp-plugins-list-table.php
4. wp-admin/includes/file.php
5. wp-admin/includes/template.php
6. wp-admin/install.php
7. wp-admin/js/widgets/text-widgets.js
8. wp-admin/js/widgets/text-widgets.min.js
9. wp-admin/plugin-editor.php
10. wp-admin/plugins.php
11. wp-admin/setup-config.php
12. wp-admin/theme-editor.php
13. wp-admin/user-edit.php
14. wp-includes/class-wp-customize-manager.php
15. wp-includes/embed.php
16. wp-includes/formatting.php
17. wp-includes/js/mce-view.js
18. wp-includes/js/mce-view.min.js
19. wp-includes/js/tinymce/plugins/wplink/plugin.js
20. wp-includes/js/tinymce/plugins/wplink/plugin.min.js
21. wp-includes/js/tinymce/wp-tinymce.js.gz
22. wp-includes/js/twemoji.js
23. wp-includes/js/twemoji.min.js
24. wp-includes/js/wp-emoji-loader.js
25. wp-includes/js/wp-emoji-loader.min.js
26. wp-includes/js/wp-emoji-release.min.js
27. wp-includes/js/wplink.js
28. wp-includes/js/wplink.min.js
29. wp-includes/script-loader.php
30. wp-includes/version.php
31. wp-includes/widgets/class-wp-widget-text.php
32. wp-includes/wp-db.php

Forrás: https://codex.wordpress.org/Version_4.8.2

Gyorshír – 2017/05/17
Megjelent a WordPress 4.7.5, amely minden korábbi verziót érintő sérülékenységeket javít.

Mielőbb keresd fel a “Vezérlőpult” => “Frissítések” menüpontot, és végezd el a frissítést!

Módosított fájlok:

• wp-admin/includes/file.php
• wp-admin/js/common.js
• wp-admin/js/common.min.js
• wp-admin/js/customize-controls.js
• wp-admin/js/customize-controls.min.js
• wp-admin/js/updates.js
• wp-admin/js/updates.min.js
• wp-admin/about.php
• wp-admin/customize.php
• wp-content/plugins/akismet/_inc/img/logo-full-2x.png
• wp-content/plugins/akismet/_inc/akismet.css
• wp-content/plugins/akismet/_inc/akismet.js
• wp-content/plugins/akismet/akismet.php
• wp-content/plugins/akismet/class.akismet.php
• wp-content/plugins/akismet/readme.txt
• wp-includes/js/plupload/handlers.js
• wp-includes/js/plupload/handlers.min.js
• wp-includes/js/wp-api.js
• wp-includes/js/wp-api.min.js
• wp-includes/class-http.php
• wp-includes/class-wp-customize-manager.php
• wp-includes/class-wp-xmlrpc-server.php
• wp-includes/taxonomy.php
• wp-includes/version.php

A WordPress 4.7 és 4.7.1-es verziójában található súlyos sérülékenység egy megújított funkcióra, a REST API-ra vezethető vissza (részletek, konkrét biztonsági kockázat a fenti cikkben). Ezért (is) érdemes letiltani ezt a funkciót a weboldalunkon, hasonlóan az xmlrpc.php fájlhoz.

Mi az a REST API?

Fejlesztői eszköz, amelynek az elődje a WordPress 4.4 óta a rendszer része. Ezt a funkciót főleg fejlesztők szokták használni (segítségével a megszokottnál könnyebben lehet adatokat lekérni a rendszerből), de sok weboldalon kihasználatlan marad, ezért felesleges az engedélyezése.

A DDoS támadások kedvelt kiinduló célpontja valamelyik REST API által elérhető url.

Adatlistázás példa, ha nincs tiltva a REST API:
A weboldalunk címe mögé ezt: /wp-json/wp/v2/users, vagy ezt: wp-json/wp/v2/users?page=1&per_page=10 írva ki lehet listázni a weboldal felhasználóit.

Továbbiak:

• /wp-json
• /wp-json/wp/v2/posts
• /wp-json/wp/v2/pages
• /wp-json/wp/v2/media
• /wp-json/wp/v2/types
• /wp-json/wp/v2/statuses
• /wp-json/wp/v2/taxonomies
• /wp-json/wp/v2/categories
• /wp-json/wp/v2/tags
• /wp-json/wp/v2/settings

A REST API funkció tiltása

Fel kell telepíteni a Disable REST API bővítményt, majd aktiválni kell. Nincs semmilyen további teendő, a funkció (tiltás) működik is. Ha pl. beírod a webcímed mögé a /wp-json kiegészítést, már nem lesznek elérhetőek az adatok.

Figyelmeztetés!

Előfordulhat, hogy a Contact Form 7 bővítmény nem működik (nem mennek el a küldendő levelek) a Disable REST API bővítménnyel együtt! Ebben az esetben az egyik bővítmény használatáról le kell mondani. Tipp: Én a Contact Form 7-et mindenképpen használnám, és a cikkben bemutatott Disable REST API-t törölném.

További részletek a REST API mibenlétéről:

• Kézikönyv: https://developer.wordpress.org/rest-api/
• Általános bemutató: https://www.toptal.com/wordpress/beginners-guide-wordpress-rest-api
• Példák: https://forum.ait-pro.com/forums/topic/wp-rest-api-block-json-requests-to-users-comments-routes/