Diskuze: nechtěný zápis do Db
Michal Štěpánek:17.4.2018 9:45
Kdysi jsem řešil něco podobného. Měl jsem to špatně zabezpečeno a přestože jsem si to pak "dozabezpečil", dělo se to stále. Tudíž předpokládám, že to dělal nějaký "robot", který si před tím stáhnul můj script. Tak jsem do DB do tabulky přidělal další (v podstatě zbytečný) sloupec a změnil své scripty tak, aby to ukládalo správně. V tu chvíli už ten robot neměl aktuální script a toto nechtěné chování přestalo...
Děkuji za odpověď, ale jak si může robot stáhnout script? Myslel jsem že to by nemělo jít jako že kod pho je na venek neviditelný. A taky že stáhnout to lze jedině s přístupem na ftp. Navíc ty scripty co zapisují do db samy o sobě by měli být nepoužitelné. Je třeba být přihlášen na ve webovem rozhrani a dle id v session se dá zapisovat do tabulek. Jediný script, který to nepotřebuje je jeden hlavní, který běhá každé dvě hodiny a tahá si právě ty ostatní k tomu aby to zapsal co je třeba. Vaše teorie se mi líbí, je to aspon nějaké vysvětlení, ale nechapu jak to je možný. Takže teoreticky, by mělo momentálně pomoci i změna hesla do db.
Michal Štěpánek:18.4.2018 7:17
Netuším, jak si nějaký robot může stáhnout script z webu, ale asi to
nějak jít musí, když se ty věci děly. Popravdě nevím, jestli si stáhne
script, nebo je schopen nějakým způsobem použít přímo tu stránku, aby
uložil data do DB... Teoreticky by změna hesla pomoci mohla, ale...
Já zkoušel tehdá všechno možné a pomohla mi až změna struktury tabulky
(po zabezpečení samotného scriptu ve stránce - že na tu stránku se
scriptem může přistupovat pouze z určité url, že v parametru musí být
nějaké číslo nebo znaky, které si z té url přinese s sebou, apod...)
Pak jsem si čmuchnul k ASP.NET a celé PHP jsem poslal do pr...(no tam, kde se
ze zad stává sprosté slovo). A mám po problému se zabezpečováním, páč
tam si to hlídá skoro všechno samo...
Cau, udelej si trigger on update/ on insert / on select a ukladej si tam vzdycky to SQLko, ktere budes spoustet i s timestampem. Zkontroluj si taky usera, se kterym se pripojujes do databaze, jestli ti tam nekdo nedela nejaky chaos(moc privilegii). Podle toho, co pises, by to taky mohla byt injektaz. Zkus se mrknout na bezpecnost. Jakou databazi pouzivas?
maxijoey:24.4.2018 7:15
No, já ty trigery nějak zatím neumím, vím na co to je, ale ... Asi to zatím neumím udělat. Injektáž mě napadla, to jsem jsem už upravil moře kodu kvuli tomu, ale nevypadá to že by to pomohlo. Jak přes URL adresy tak většinu formů. Databázi používám MySQL.
dez1nd:24.4.2018 7:34
Nepoužíváš v té db, tabulku s userama ? nestačilo by do té tebulky přidat constraint prave na toho usera ? Tím by jsi měl zabezpečeno, že nepřihlášený uživatel ti nic nezmění ne ?
mixxy:24.4.2018 22:13
Triggeru se nemusíš bat. Je to jen kus kodu, který je(ale i nemusi) byt dobře citelny. Tady mas hinty: https://dev.mysql.com/…-syntax.html
maxijoey:25.4.2018 6:58
No mám v té db tabulku klientů a ta obsahuje názvy databází. Ale všechno se to přihlašuje přes roota do nich.
Petr Čech:25.4.2018 12:09
Ale fuj, root by se prakticky neměl používat. Udělej si pro ten web speciálního uživatele, kterému osekáš práva na minimum toho, co je třeba.
maxijoey:26.4.2018 6:09
No já vím že je to fuj. Toho se zbavím taky, nebo to plánuju, jen moc nevím co mi pomůže ten special user. V podstatě web je administrace kam si chodí moji klienti upravovat svá data. Čili on se zaloguje a aktuálně se přihlásí do DB jako root. Vím že by asi každý uživatel měl mít svuj učet v db. Ok, ale nedomyslel jsem jak to pomůže. On každý potřebuje jak čist tak zapisovat. A kron který běží na serveru potřebuje vetšinou zapisovat občas také číst. Ten se přihlašuje také jako root. Když to převedu na jednoho special usera, já v tom nevidím moc rozdíl.
Michal Štěpánek:26.4.2018 8:56
No já v tom rozdíl vidím, když pro běžnou činnost uživatelů na webu
(nebo i jinde) používáš usera "root" a někdo ti k němu změní heslo, už
se do té DB nikdy nedostaneš. Root by měl být jen pro tebe (admina) a pro
tvou "ruční" práci s databází. Ostatní uživatelé, kteří pracují na
webové stránce, by měli přistupovat do DB pod jiným účtem, který pro
tyto účely vytvoříš.
Já mám pro přístup do DB jednoho usera, přes něj pak aplikace komunikuje s
databází. Každý uživatel má pak svůj účet pro přístup na stránky
nebo do aplikace a každý ten účet má nějakou roli, která má určeno, co
může zobrazit a jak může s aplikací pracovat.
Petr Čech:26.4.2018 13:33
Existuje princip nejmenších oprávnění - vše by mělo pracovat s co
nejnižšími oprávněními, protože to dokáže podstatně limitovat škody,
pokud se něco zkazí.
To znamená, že funkční přínosy příliš neexistují, ale z pohledu
bezpečnosti je to poměrně důležité.
Root by se měl používat pouze tam, kde je to nutné, protože může všude.
Potom je dobré udělat si alespoň jednoho uživatele, co bude smět jen to, co
potřebuje - možná manipulace s jednou tabulkou/databází, třeba i
administrativní.
Určitě totiž nechceš být v situaci, kdy zjistíš, že jsi měl na webu SQL
injekci a protože to běželo pod rootem, může úplně ke všemu. Oproti
tomu, kdybys měl uživatele jen pro tuto činnost, maximálně ti vykrade jednu
databázi. Určitě ale třeba nezmění rootovské heslo a pod.
Jj, souhlas. Kazdy program by mel mit vlastniho uzivatele. Pokud to tak
nemas, tak si to tak predelej.
Ono je celkem mozne, ze v nekterem programu mas zapomenuty kod nebo neopraveny
nazev tabulky. Pak se pokosi zapisovat, kam nema a protoze ma roota, tak se mu
to i podari.
Jeste by se to dalo oddelit prejmenovanim tabulek. Pokud vsechny ty programy nepouzivaji zrovna tu samou. Treba prefixem. users -> p1_users. A opravit to v sql dotazech. Nebo, ti lepsi uz pri navrhu pocitaji s prefixem tabulky. Provozuji vic programu v jedne databazi se stejnymi nazvami tabulek.
Mno, já tam mam nekolik databází, každý klient má svou, v ní tabulky, struktura db je totožná u každého a tabulka ve ve které dochází k přepisům, se jmenovala stejně u každého, ale později jsem je přejmenoval, každá dostala sufix. Nepomohlo to. Ale snad už jsem tomu na stopě a co jsem se zde dozvěděl tak se snažím aplikovat. Jádro aplikace navíc teda přepisuju z PHP do C#, zejména ty věci volané crony. Což zatím aspon přidává na rychlosti zpracovani dat když nic. I zapomenutý kod mě napadal někde že by mohl být, ale nenašel jsem. Uvidíme po změnách co to bude dělat.
maxijoey:7.7.2018 9:04
Pomohl by mi někdo prosím s těmi Triggery? Vytvořil jsem takový malý, když proběhne nějaký update tak mi to do jiné tabulky hodí záznam o datu, uživateli, chtěl bych tam ale dostat i ten sql dotaz co to provedl. Jenže mám trochu problém. Zjistil jsem že tento kod:
INSERT INTO tracking(hodnota, datum, user, sql_dotaz)
VALUES('update',NOW(), USER(), (SELECT INFO INTO original_query FROM
INFORMATION_SCHEMA.PROCESSLIST WHERE id=CONNECTION_ID())
Mi sice přidá data, ale jen poslední dotaz což je právě vložení dat z triggeru.
Pokud zkusím toto, což by mělo fungovat, nejdřív vytáhnu poslední dotaz a pak to uložím nefunguje:
DECLARE original_query VARCHAR(1024);
SET original_query = (SELECT info INTO original_query FROM
INFORMATION_SCHEMA.PROCESSLIST WHERE id=CONNECTION_ID());
INSERT INTO tracking(hodnota, datum, user, sql_dotaz)
VALUES('update',NOW(), USER(), original_query)
Lépe řečeno phpmyadmin my ho nechce vzít. Řve na mě že mým divnou syntax. Vím že tam chybí BEGIN a END a CREATE ale to doplňuje phpmyadmin sám, jak jsem pochopil.
Jinak celé jsem to rozsekal, každý user se přihlašuje na svůj účet do DB, aplikace sama má také svůj. Zdálo se cca měsíc že byl problém vyřešen, ale onehdá, opět přepis dat. Veškeré moje scripty nebo programy co zapisují do DB jak php tak C# se vždy k záznamu podepíší a uvádí i datum úpravy. Jenže při tomhle náhodném přepisu datum úpravy chybí nebo je jiné než timestamp, který tam také dávám a podpis scriptu nikde. Proto to zkouším vypátrat takto.
Zobrazeno 16 zpráv z 16.