Cat de bine isi protejeaza magazinele online clientii?
12 Iunie 2009 de Ovidiu Lixandru • 4,392 vizualizari
Scris in Analiza
Articole similare:
- Cybersquat fericit pana la adanci batraneti
- Exclusiv la eMAG vs Promotie la PCfun
- Noi n-avem promotie de Pasti?
Tag-uri articol:
eMAG, IT&C, PCfunCum arata cateva proof of concept din ultimele luni, nu prea bine. In februarie a cazut PCfun, acum eMAG.
PCfun la HackersBlog:
eMAG la AlienHackers:
Cateva lucruri ar trebui sa aiba totusi in vedere cei care se ocupa de asa ceva:
- nici un magazin din Romania nu stocheaza datele despre cartile de debit/credit pentru ca nu are de ce – procesarea platilor se face extern iar datele pot fi decat introduse de cumparator.
- continutul /etc/passwd nu foloseste la nimic de pe la sfarsitul anilor ’80, incercati cu /etc/shadow
Pentru a preveni asemenea situatii, solutiile pentru magazine sunt la indemana:
- lasati deoparte mysqli_multi_query()
- un mysql_real_escape_string() pus unde trebuie se pare ca face cat o mie de screenshot-uri cu vulnerabilitati, sau, alternativ, prepared statements
- daca folositi functii wrapper pentru interogarea bazei de date, filtrati ce nu folositi din query-ul final (de ex. keyword-ul magic “union”)
- hash-uri pentru parole sau criptarea lor
- daca folositi hash-uri, obligati utilizatorii sa foloseasca parole puternice – exista tabele rainbow
- tineti versiunile la zi, fie ele biblioteci sau programe de live support
Update: Nici Profitshare nu sta mai bine.
“daca folositi functii wrapper pentru interogarea bazei de date, filtrati ce nu folositi din query-ul final (de ex. keyword-ul magic “union”)”
La blind injection nu-ti trebuie “union”…poti filtra simbolurile de comment-out si multe altele ( ‘ sau , )
Sunt curios ce ar zice baietii de la ANSPDCP despre asta
Detaliu de exprimare:
“datele pot fi decat introduse”
corect: “datele nu pot fi decat introduse” sau “datele pot fi introduse doar..”
De altfel ultima moda, observ, ca e pacalirea functiilor de sanitizare prin schimbarea charsetului.
Un alt hint ar fi sa treceti string-urile printr-un iconv ca sa fortati conversia in utf-8 inainte de a trece prin filtre de sanitizare, chiar daca teoretic mysql_real_escape_string() ar trebui sa acopere problema de conversie, better safe than sorry.
Vezi aici http://shiflett.org/blog/2006/.....ape-string
Iar pt cine isi permite si un filtru de sql ca http://www.greensql.net/
Chiar daca nu e 100% sigur, te anunta la timp de incercari de exploit si iti spune si unde s-au incercat.
@bogdan: Exprimarea e aleasa asa pentru a intari continutul. In cazul de fata e mai important fondul decat forma.
Si cum intareste continutul o folosire incorecta a limbii romane?
Fondul nu poate decat sa capete legitimitate langa o forma corecta.
Facem un sondaj sa vedem cine a inteles sau vorbim pe subiect?
OK, spell it out for me: “Exprimarea e aleasa asa pentru a intari continutul.”. Inseamna ce?
comentati on topic va rog nu pe langa
bogdan esti pe langa subiect
nu se discuta despre gramatica limbii romane
iti recomand un alt thread, oriunde vrei tu
Ok?
Pe mine unul ma interesa subiectul , deja 3 sau 4 linii cu altceva decat ce se intelege din titlu
ayurveda, am ridicat o problema intr-un mod foarte civilizat. Nu se discuta ce ordoni tu sa se discute.
Cu obligarea clientilor sa foloseasca parole complexe nu sunt de acord. Eu am abandonat niste site-uri tocmai din cauza asta (nu stau sa inventez 10000 de parole pt fiecare site). Pt rainbow exista solutii: folosire salt unic per user.
O idee foarte buna cu salt-ul, putand fi folosite chiar mai multe constante ale utilizatorului respectiv: ID-ul de client, data inregistrarii etc.
nu cred ca datele de cc nu pot fi preluate. ca presupunem noi ca ei nu le stocheaza e altceva, de ce exista tabela cc? asta este intrebarea.
ar trebui sa existe un regulament, o lege ca sa-i verifice. orice data introdusa intr-un formular poate fi copiata daca se vrea… rusine emag
pacat ca baietii de la allienhackers nu s-au uitat sa ne zica daca sunt sau nu, acum trebuie sa-i credem doar pe cuvant…
[...] citit aici un articol despre situatia magazinelor online din Romania. Mi-a atras atentia urmatorul [...]
de ce incerci sa le gasesti scuze la magazinele astea online? Incerci sa minimizezi pericolul pt ca cu un union nu se pot scoate datele de cc. Dar cine zice ca nu pot modifica scriptul sa stocheze? Esti batut in cap omule? Daca gasesti sql injection ai sanse mari sa poti si crea fisiere (da, se poate cu sql injection!) si cine ma impiedica sa imi scriu si eu mic shell si dupa sa modific scriptul? duh!
Don’t get owned. Faptul ca nu stochezi date sensibile nu inseamna ca nu iti trec prin mana
Inca o chestie care nu ai inteles-o….chestia cu /etc/passwd. O vezi peste tot in exemplu nu pt ca fisierul este relevant pt atacator (nu m-am deranja o lista cu conturi pt bruteforce pe dictionar
dar e un fisier prezent pe orice linux/unix. Daca stii ca vulnerabilitatea exista (local file inclusion) poti sa incluzi un fisier cu adevarat relevant! De exemplul fisierul de loguri a apache-ului dupa ce in prealabil ai injectat undeva in headerul unei cereri HTTP un pic de cod PHP pe care il executi cu ocazia vizualizarii fisierului temporar 
La asta nu te-ai gandit 
Si uite asa de la un fisier nevinovat din anii 90 ajung eu la shell 
Desigur pana aflii unde este fisierul care il vrei stai vreo ora 2 si incerci. Asa ca e bine intai sa stii ca exista vulnerabilitatea.
In concluzie nu mai vorbi prostii daca nu te pricepi. Critici lumea ca foloseste chestii din anii 90 fara sa pricepi bazele.
Din pacate tu iti arati propria nestiinta in ceea ce priveste o chestie elementara in *nix: drepturile asupra unui fisier:
# ls -al /etc/passwd
-rw-r–r– 1 root root 6477 Jun 1 10:22 /etc/passwd
# ls -al /etc/shadow
-r–r—– 1 root root 4491 Jun 9 17:09 /etc/shadow
/etc/passwd e readable de catre orice user, inclusiv de catre uer-ul sub care ruleaza Apache/PHP din motivele enumerate de mine. /etc/shadow nu e. Ai fi stiut chestia asta daca intr-adevar ai fi administrat un *nix vreodata. Oricand.
Spor la citit.
@Tudor: Cine zice, ala e. De dat din gura e usor – te invit sa modifici scripturile unui magazin online pentru a stoca datele card-urilor unde vrei tu. Vorbesti in necunostinta de cauza crasa, se vede de la o posta ca nu ai facut o implementare de plata online prin Gecad ePayment de exemplu sa vezi cum decurge fluxul platii si cum nu ai acces la acele date.
Datele cardurilor nu sunt stocate de catre magazine. Datele sunt introduse pe serverele procesatorilor de plati (in cazul eMAG – Gecad Epayment).
O problema mult mai mare e cu platile repetate, majoritatea siteurilor care suporta asa ceva pastreaza datele de CC ca sa nu mai trebuiasca sa le introduca clientii de fiecare data. Uneori platile alea se fac automat (servicii cu valoare variabila) si datele trebuie tinute undeva pentru ca nu e o simpla plata recurenta gen siteuri porno cu $4.95/luna pana la anulare.
Din pacate chiar si in strainatate alternativele sunt jalnic de putine. Doar PayPal ofera un asemenea serviciu oarecum rezonabil (PayPal e relativ scump, altii sunt si mai), pentru toti ceilalti trebuie sa tii datele de CC la tine pe server…
Chiar nu a observat nimeni ca in print-screen apare Username + Parola, dar emag nu cere username? Autentificarea se face cu email si parola. Nu exista loc in site in care sa ceara username …
@Ovidiu & &Gabi: daca poti modifica fisierele unui site, poti sa iei lejer datele de card ale utilizatorilor, ba chiar daca poti face un XSS poti lua datele respective. Nu conteaza ca nu le cere MAGAZINUL, tu, ori modificand fisierele sitului ori prin XSS LE POTI CERE … si nu o sa stea toti userii sa vada daca sunt pe situl romcard sau nu.
Dar in cazul emag nu exista nici-o dovada prezentata cum ca ar putea fi modificate fisierele sitului, sau datele din DB.
lucrati in .net si asp
sunt mult mai sigure
Argumente?
Lucrati in jps/jfs…oracle, ibm… etc.. NU php,mysql…
jsp/jsf am vrut sa spun…
Petru, sfantu petru
…sunt mai sigure pentru ca nu a stat nimeni sa isi bata capu cu ele.. nu pt ca nu au buguri…