Samovolné vymazání tabulky v databázi

Dobrý den, dnes se mi přihodila nepříjemná věc. Po příchodu na web(spurs.xf.cz) a pokusu o komentování článku mi vyskočila chybová hláška, že neexistuje tabulka, do které se komantáře zapisují. Po přihlášení do MySQL jsem zjistil, že je skutečně vymazaná, vše jsem opravil opětovným nahráním tabulky, ovšem už bez starších komentářů. A proto se ptám, jestli to jde nějak vrátit(například zaslání zálohy od adminů wz.cz). Ale hlavně mě zajímá proč se tak stalo. Komentáře mě tolik nevadí, ale pokud by se mi vymazala několika měsíční databáze článků, byl bych velmi zklamaný. Prosím tedy o nějaké rady, jak tomu předejít.

//napadá mě, že jsem překročil limit prostoru v MySQL a tam mi to vymazalo nejvíce zabírající tabulku, žádné upozornění o překročení kapacity mi však nepřislo...

Pokud máš tabulku, která by mohla potenciálně překročit povolenou velikost, doporucil bych nejakym skriptem jeji promazavani (pripadne zalohovani nejstarsich dat nekam do souboru..)..

Dále doporučuji provest kontrolu, jestli máš formuláře dobře zabezpečeny proti sql-injection;) (nechci to zkouset a spamovat tim databazi, proto to pouze zminuji:)

Tabulka by se sama o sobě neměla mazat. To jen při poškození, ale to je vzácnost. Při překročení prostoru další záznamy zamítne.

Takže chybu bych hledal někde jinde. Většinou ve skriptech. Buď je tam zranitelné místo (SQL injection) nebo došlo tak říkajic k přetížení dotazu. To znamená, že místo smazání jednoho záznamu došlo ke smazání všech.

Tabulka se sama nesmaze. To by byla fakt vzacnost.

PHP RS jako CMS z hlediska zabezpeceni a tabulek je smejd. Z hlediska CMS je celkem dobre resene. Z hlediska komentaru a spamu je to smejd.

'Dále doporučuji provest kontrolu, jestli máš formuláře dobře zabezpečeny proti sql-injection;) (nechci to zkouset a spamovat tim databazi, proto to pouze zminuji:)'
ROZHODNE! A soucasne si projdi vsechny php formulare s tim souvisejici, je to derave, az bida. Dokonce jsem resil nejaky problem s apostrofy, protoze to v praci pouziva jedna sekce pro clanky. Nehlede na to, ze pri prevodu na jiny server jsem mazal 50MB a pozdeji 160MB spamu. Cili ted sice neodpovida pocet prohlednuti clanku, ale v databazi je tak 2MB komentaru proti puvodnim asi 270.000 zaznamum.
Nahodil jsem tam vlastni antispam pres JS. A hlidam php filtrem urcita slova a odkazy myslim taky.

Diky moc, vase rady vyzkousim...

Tedy mně se dnes večer přihodilo, že se tabulka se záznamy návštěv smázla, neb jsou tam najednou záznamy jen od deseti večer (s id nabíhajícím od 1).
Co se stalo?!

Tedy abych byl přesný, smázl se obsah tabulky.
Předtím měla něco přes 50 tisíc řádků (primary key bigint), to není zas tak moc, aby to snad působilo problémy..? :(

=MarK=
Nevím jaké jsou aktulně používané možnosti "zabezpečení" proti překročení velikosti v MySQL - ale dulezite je, ze velikost nezáleží na primary key, ale na všech datech - zejména na velikosti obsahu sloupců s datovým typem TEXT atd..

A 50k řádků opravdu není malo - můžes nějak logicky vysvětlit, na co máš 50k řádku v JEDNÉ tabulce?

Takové "zabezpečení" by mě tedy zajímalo. Samozřejmě chci vědět, zda a jaké má moje aplikace limity a ošetřit to.
Nicméně databáze stále ani zdaleka nedosahuje daných 20MB a o nějakém dalším datovém omezení jsem se nikde nedočetl. (pokud jsem něco přehlédl, tak mě prosím nasměrujte)
Tabulka žádné TEXT sloupce nemá, jen dva VARCHARy a dva INTy. Jde o jednoduchou statistiku, nic datově extra náročného.

Otázka. Máte ve své aplikaci možnost manipulovat s daty? A máte ji také zabezpečenou protí SQL injection? Z obou případech může totiž dojít i ke smazání dat.

Pochybuji, že by to způsobilo samotné mysql. Kdyby měl tendenci sám mazat tabulky, pak by se stal nespolehlivým a správci by od toho dali ruce pryč a přešli by třeba na postgresql. Výjimky ale mohou nastat. To když se datový soubor natolik přetíží, že tabulku znehodnotí a tím pádem je tabulka poškozená. Jenže to byste se do tabulky nedostal.

Sakra. Nevím proč se opakuji.

Autor: Tomík (tom.czweb.org)
Datum: 10. 01. 2009 17:53

Data tam dodávám sám (ne uživatel) a jsou escapovaná...

Proto si taky myslím, že to má nějakou souvislost s WZ a ne s MySQL, ale nevím jakou. Fungovalo to v pořádku po nějaké 4 mil. zobrazení a teď najednou cvak - smazáno, od začátku.

=MarK=
To, že data jsou escapovaná ještě neznamená, že je skript zabezpečen proti SQL injection..

Samotná informace, že to fungovalo nějakou dobu neznamená, že to předtím bylo v pořádku - u Adobe taky našli bezpečnostní bug ve flash přehrávači až po asi šesti letech, co tam byl. ;)

Pokud jde o překročení 20MB limitu, tak nevím jaké jsou opatření. Ale řekl bych, že je to jedno. Náhodou jsem tento limit překročil o 1,5MB a nic se nestalo. A kdyby něco, tak jsem toho názoru, že další záznamy zamítne a ne smaže.

Prostě jsou pouze dvě scénaře. Buď máte ve skriptu zranitelné místo, které provedlo smazání. Nebo se na WZ skutečně pohybuje šotek, který to provedl.

Bohužel první scénář je více reálný než ten druhý. Uživatelé si to nepřipouští a jednoduše to schvaluji na druhé. A to nemluvím do větru. Běžně slyším, že chyba je na straně WZ a nakonec zjistí, že chybu udělali sami (uživatelé).

Že je první možnost pravděpodobnější je mi jasný. Co mi jasní není je to, proč to přestalo náhle fungovat po zhruba 4 milionech použití...

Asi už to bylo ojetý...

=MarK=
Uvědom si, že než se na nějakou chybu přijde, nějakou dobu to trvá.. Že zobrazení fungovalo po x let neznamená, že dalších x let bude fungovat. Zřejmě máš ve skriptu nějakou chybu, která se dříve neprojevila - třeba nebyly podmínky pro to, aby nastala..

Vzhledem k vysokému počtu řádků a BIG INT (záleží na zpracování - například sčítání, nebo násobení mezi sebou) může docházet k přetečení nějaké proměnné, což může dál způsobovat chyby.. zauvažuj i nad tímto při kontrole skriptu ;)

... V prvni rade je treba do configu pripsat tyto 3 radky na zacatek:
@ini_set('error_reporting',E_ALL);
@ini_set("display_errors","on");
error_reporting(E_ALL);
... tim se povoli zobrazovani php chyb.

... pak radek
function sq($query,$text='') {global $SQL; $SQL['dotazy']+=1; $res = mysql_query($query) or die("<hr>MySQL Err".$text.": $query<hr>".mysql_error()); return $res;} //debug mode
... a vsechny SQL dotazy prepsat na
sq($dotaz);
... tim docilis toho, ze pri chybe zkape SQL dotaz a dal se to nedostane, na obrazovce se zobrazi chybova hlaska. Tato cast je dost pracna, protoze to znamena prepsat cely CMS phpRS.
Ale pak se dozvis pri jake akci a proc ti to zkapalo.

A jeste je tu reseni, zpristupnit to cele nekomu z venci. To zastav, proved zalohy, zkopiruj treba na jiny wz.cz ucet a dej sem hesla. Pripadne dej hesla nekomu z fora, aby to neresili 2 lide naraz.
Kdyz tu chybu nevidis, tak se to tezko resi. Predpokladam, ze adminum je tvuj nefunkcni program ukradenej :)

Co se tyce PHP / SQL injection a pod, uz jsem psal, ze phpRS je deravy. To, ze poresis escapovani jeste nevyresi to, ze mu muzes odeslat formularem PHP kod. Navic to pouziva globalni promnenne. Proste to chce cele zabezpecit.
formular $aaa = 'ahoj';
phprs $bbb .= $aaa;
phprs eval($bbb);
A kdyz misto ahoj posles " '; echo 'bububu'; die(); " , tak mas nabourane phpRS. A vzhledem k free kodu utocnik zna jmeno promenne pro admina a misto echo 'bububu' da echo $psw; nebo neco tak.

Peta. Nic ve zlým, ale tady jsi už úplně mimo.

Toto vlákno řeší jeden problém, ale připojil se tu další uživatel (Mara). Původní uživatel odpovědi od nás získal, a to i od tebe, a akceptoval je. A tím to pro něj skončilo. Tečka.
Připojil se tu však další uživatel (MarK) se stejným problémem, ale v jiném kontextu. Chybu způsobila jeho aplikace (nebo WZ?) a ne phpRS. Takže tvoje nová reakce je o ničem.

Příště než začneš něco psát, tak si ty příspěvky pořádně přečti, ať víš vo co go. Takto si děláš ze sebe jen blbce. Což s prominutím už dávno jsi.


Toto vlákno už nemá co nového říct, takže je zbytečné sem něco psát.

Tomík (tom.czweb.org)
Jak resi problem tvuj prispevek obema lidem? Off-topic.
Pokud si moderator mysli, ze to sem nepatri, smaze to sam.
"Pane uciteli, uz je cas, uz musime jit."

phpRS je programove smejd. Mas jiny nazor? Podel se, proto se to jmenuje forum.
Abys mohl zjistit, co tam ma za chybu, musis ji umet vypsat. Ani jeden z lidi neresi vypsani chyby.

...
Autor: Freeze (dreamer.kvalitne.cz)
Datum: 31. 01. 2009 18:43
A 50k řádků opravdu není malo - můžes nějak logicky vysvětlit, na co máš 50k řádku v JEDNÉ tabulce?
...
Tomík (tom.czweb.org): odpoved na to byla statisticke udaje. Z toho opet vime skoro nic. Treba struktura tabulky? Idealne proste, co vypise php/mysql za chybu, pokud nejakou vypise?
Pripadne zkusit do scriptu davat echo "aaaaa"; a hledat, kde se to vypise se zpozdenim.

Jinymi slovy, zatim stale hadame, kde je problem. Zda se, ze ty jsi hodne chytry a uz to vis. Proc nam to tajis? Rekni, sim, siiim :)


Freeze (dreamer.kvalitne.cz)
50k radku muze byt normalni statistika IP, komentare. Myslim, ze posledne jsem z phpRS photorevue.com odstranoval 100mb spamu nez jsem provedl upgrade a nahodil tam rucne antispam, protoze uz mi dosli nervy :)

Jsem namol nebo to co psal peta vůbec nedává smysl?

=Tomík=
Moc nedáva.. :)

=peta=
Vím, že 50k řádků není moc - sám jsem měl v databázi logy z mailserveru -toho je ještě výrazně víc ...

Ale máš pravdu, že přesnou odpověď nikdo nedal - ostatně, s tak málo informacemi ji nikdy nenajdeš.. znáš sice strukturu tabulky, ale ne skripty (a možné vstupy), které s vybranou tabulkou pracují..

Tvé způsoby řešení jsou ale úplně zcestné - problém není v jednom skriptu, který by data mazal. Problém je, že se někde část ztratila a teď se snaží zjistit kde - opravdu mu v tomto pomůže echo 'muhehe';?

Zmínil jsem, že vzhledem k množství dat a používání BIG INTu může u některých proměnných docházet k přetečení (např při násobení at) a tedy chybám, chce to prostě zkontrolovat ;) - na toto mi zatím odpovězeno nebylo, a.. upřímně řečeno.. bez odpovědi "majitele" skritpu mu neporadíme ;)