Bezpečnosť dát bez DB

9. 1. 2011 15:26:43

Zdravím.

Moja stránka má administráciu, registráciu, všetko čo k takému menšiemu "portálu" patrí, no nevyužíva databázu, ale jednoduché vpisovanie informácií do súborov.

Povedzme že je zložka "nastavenia". Vnútri je .htaccess ktorý nedovoľuje nikomu prístup a zároveň súbory nieco.set s nastaveniami užívateľa.

Na koľko sú dáta v bezpečí? Je možné ich nejako získať/zmeniť/zmazať? Skúšal som ich prečítať z iného webu a nebolo to mozné...

Okrem toho, keď pripojím aj zaheslovanie zložky (htpasswd)?

Ďakujem za odpovede, ohľadom bezpečnosti nie som expert :)

9. 1. 2011 15:26:43

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598270

(20 hodnocení)

9. 1. 2011 15:46:09

teoreticky ty data nikdo neziska, ale na serveru kde tit o bezi muze bezet treba nejaka jina aplikace ktrea bude dovolovat cist soubory na serveru a pri spatnem chrootovani to pak znamena problem i pro tebe... pripadne pokud by nejaka takova chyba byla u tebe :) ale jinak jsou data vcelku v bezpeci... ono to ze pouzivas databazi hned neznamena ze jsou data jakkoliv vic v bezpeci, databaze je o to nachylnejsi ze spousta "programatoru" opomiji sql injections ;)

9. 1. 2011 15:46:09

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598269

Smarty

(3 hodnocení)

9. 1. 2011 19:57:53

Vďaka teda, to ma upokojilo :)

Myslím že žiadna chyba / aplikácia by tam nemala byť.

9. 1. 2011 19:57:53

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598268

Kamil Tomšík

(3 hodnocení)

15. 1. 2011 08:42:30

pokud ten tvuj system umoznuje vkladani dat od uzivatele (napriklad komentare), tak je pro tebe nejvetsi nebezpeci atomicita operaci

(tzn. ze pokud 2 lide vlozi komentar ve stejny okamzik, mohou data dojit k urazu)

soubory totiz nejsou atomicke - alespon v php dost tezko, databaze ti garantuje, ze update/insert probehne vzdy jen jeden v jeden okamzik

a navic ti poskytuje transakce pro vicedotazove operace.

no a jinak co se zabezpeceni tyce - sql injection se te netyka, ale vse ostatni ano - xss, xsrf, session injection, clickjacking, ...

15. 1. 2011 08:42:30

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598267

Smarty

(3 hodnocení)

16. 1. 2011 11:22:01

Napsal vedouci;614946
pokud ten tvuj system umoznuje vkladani dat od uzivatele (napriklad komentare), tak je pro tebe nejvetsi nebezpeci atomicita operaci
(tzn. ze pokud 2 lide vlozi komentar ve stejny okamzik, mohou data dojit k urazu)

soubory totiz nejsou atomicke - alespon v php dost tezko, databaze ti garantuje, ze update/insert probehne vzdy jen jeden v jeden okamzik
a navic ti poskytuje transakce pro vicedotazove operace.

no a jinak co se zabezpeceni tyce - sql injection se te netyka, ale vse ostatni ano - xss, xsrf, session injection, clickjacking, ...

Týmto si ma zarazil...

Dáta môžu alebo určite prídu k úrazu? Keď tak budem musieť zapracovať systém do SQL...

16. 1. 2011 11:22:01

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598266

Kamil Tomšík

(3 hodnocení)

16. 1. 2011 11:44:29

no kdyz dva lide odeslou komentar zhruba ve stejny okamzik a apache je zpracuje skoro zaroven, tak se jeden komentar urcite ztrati,

to je ta lepsi situace - teoreticky je mozne, ze se zapise pul jednoho komentare a pul druheho, ale to se mi nikdy nestalo

16. 1. 2011 11:44:29

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598265

Smarty

(3 hodnocení)

16. 1. 2011 12:41:41

Nakoľko som s týmto nerátal, hostingový balíček ktorý som kúpil nepodporuje SQL, takže neviem čo teraz...

Strata komentára by bola najmenej, ale tie xss, xsrf, session injection ako spomínaš, nakoľko sa ma týkajú? Nezabráni tomu heslovanie zložiek?

16. 1. 2011 12:41:41

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598264

Kamil Tomšík

(3 hodnocení)

16. 1. 2011 14:58:52

xss je cross site scripting - kdekoliv pouzivas a promennou nacitas z $_POST, $_GET, $_COOKIE, $_REQUEST nebo obecne od uzivatele, tam mas xss diru

xsrf je napriklad adresa "users/delete/5", pokud jsi prihlaseny a nekdo ti posle takovy odkaz (nebo bude v img src), tak vymazes uzivatele s id=5

session injection probiha tak, ze ti nekdo posle /users/login?sessid=mojesess, ty se prihlasis a cekas, co se bude dit, nebude se dit nic, jenom jsi prave prihlasil sessionu, no a utocnikovi pak staci pouzit stejnou adresu - /users/whatever?sessid=mojesess a je prihlaseny (aniz by musel vedet heslo nebo uziv. jmeno)

clickjacking je o tom, ze kliknes na normalne vypadajici tlacitko a pod nim je schovany zly iframe, ktery typicky obsahuje formular, ktery chce utocnik odeslat...

pokud to shrnu, tak se pust do studia vsech tech pojmu na wikipedii a pak googluj a googluj, nic jako bezpecny internet neexistuje, existuje jenom zabezpeceni a to utocnikum komplikuje praci. tyto zranitelnosti se tykaji vsech webovych aplikaci - sql injection se tyka jenom tech, co pouzivaji sql - jestlize mas pocit, ze kdyz nebudes pouzivat sql, budes mit bezpecnejsi web, tak ses na omylu.

16. 1. 2011 14:58:52

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598263

Lukenzi

28. 1. 2011 02:45:14

Co se týče toho ukládání dat do souboru...nedávno sem tohle vyřešil tím, že stačilo kontrolovat jestli soubor není v době zápisu otevřen (logicky pokud jiný uživatel zrovna zapisuje data tak soubor musí otevřít) a když otevřen byl, script jen v cyklu několikrát po sobě neustále kontroloval "otevřenost" souboru (samozřejmně né do nekonečna) a až zjistil že soubor je už zavřený tak data zapsal. Může se zdát že to je časově náročné, ale opak je pravdou, při testování nešlo viditelně poznat že script "na něco čeká" a taky pravděpodobnost že do jednoho souboru bude ve stejnou chvíli chtít zapisovat třeba 10 lidí najednou je velmi malá a i kdyby tak časově je zdržení úplně minimální.

Jenže s tímhle je spousta zbytečného psaní navíc a můžeš to použít jen akurát tak na nějaký blog. Na hodně navštěvovaných stránkách jedině DB.

28. 1. 2011 02:45:14

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598262

Kamil Tomšík

(3 hodnocení)

28. 1. 2011 12:17:12

Promazal jsem ty blaboly - to snad neni mozny...

28. 1. 2011 12:17:12

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598261

Lukenzi

28. 1. 2011 13:44:59

Napsal vedouci;619482
protoze script muze overit, ze soubor neni otevreny, zjisti, ze neni a chce pokracovat dal,
ale scheduler ho zrovna prepne a dostane se ke slovu jina instance scriptu

nedostane se ke slovu další instance scriptu pokud kontrolu "jestli se dá do souboru data zapsat" umístíš do cyklu, který se neustále opakuje dokať data nebude moct zapsat. Script pak teoreticky v případě neustále otevřeného souboru může běžet pořád dokola dokať ho netípne server (což samozřejmně v realu musíš ošetřit). Jiná instance pak příjde ke slovu až poté co se data zapíšou jinak ne. Jak sem řekl tohle je ale možné jen na málo navštěvovaném webu.

Na tomhle principu fungoval jeden web který sem kdysi měl na starost (už bohužel není jinak bych hodil link) a i přesto, že mněl denně zhruba 500 návštěv nebyl s tím nikdy problém.

28. 1. 2011 13:44:59

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598260

Smarty

(3 hodnocení)

29. 1. 2011 12:19:06

Napsal Lukenzi;619515
nedostane se ke slovu další instance scriptu pokud kontrolu "jestli se dá do souboru data zapsat" umístíš do cyklu, který se neustále opakuje dokať data nebude moct zapsat. Script pak teoreticky v případě neustále otevřeného souboru může běžet pořád dokola dokať ho netípne server (což samozřejmně v realu musíš ošetřit). Jiná instance pak příjde ke slovu až poté co se data zapíšou jinak ne. Jak sem řekl tohle je ale možné jen na málo navštěvovaném webu.
Na tomhle principu fungoval jeden web který sem kdysi měl na starost (už bohužel není jinak bych hodil link) a i přesto, že mněl denně zhruba 500 návštěv nebyl s tím nikdy problém.

Nakoniec som to vyriešil použitím Nette Frameworku, ktorý mi poradili na DJPW a žiadny problém nebol tiež :)

29. 1. 2011 12:19:06

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598259

Pavel Mička

29. 1. 2011 12:40:33

Jak pise vedouci...zapisovat do souboru neni rozumne, protoze s tim vznika strasny mnozstvi veci, ktery se muzou podelat...

checkovani otevreni je blbost, jak uz nekdo psal, protoze scheduler muze prepnout vlakna po pruchodu podminkou, nechat zapsat pulku dat, prepnout do puvodniho a zase ho nechat zapsat kus dat na misto, kde uz je pul jinyho prispevku...

jedinym resenim je zavirat ten zdroj (soubor) zamkama (mutexama)...cimz se ale pomerne brzo dostanes do situace, kdy budes mit zamknutej soubor a 100 pozadavku bude cekat, nez se to zamknuty vlakno vykokta...

proste pouzij databazi, kde je to osetreno lepe, nez kdokoliv z nas je schopen vymyslet (natoz naprogramovat...)

29. 1. 2011 12:40:33

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598258

Lukenzi

29. 1. 2011 15:07:36

Napsal malejpavouk;619764

checkovani otevreni je blbost, jak uz nekdo psal, protoze scheduler muze prepnout vlakna po pruchodu podminkou, nechat zapsat pulku dat, prepnout do puvodniho a zase ho nechat zapsat kus dat na misto, kde uz je pul jinyho prispevku...

jde vidět že plácáš něco co sis nikdy v praxi neověřil (nebo taky záleží na tom co si představuješ pod pojmem "checkování otevření").

IMHO existují kopy CMS založené jen na práci se soubory bez použití DB (umožňují taktéž registraci, přidávání článků a komentářů), fungují na nich weby s relativně velkou návštěvností a dost z nich vůbec mutexy nepoužívá. Jak je potom možné že fungují a problémy se zápisem dat nejsou? Můžeš mi to vysvětlit třeba...

29. 1. 2011 15:07:36

https://webtrh.cz/diskuse/bezpecnost-dat-bez-db/#reply598257

(20 hodnocení)

29. 1. 2011 15:09:53