24.4.08

Lectii de vulnerabilitate cu magazinele online romanesti (1)

Notă din 9.01.2009: Postul de mai jos e din 24.04.2008. Între timp MRex a ajuns la varianta 2.5, a mai adunat peste 100 de clienţi şi am scos şi varianta MRex System. Îmi pare sincer rău dacă succesul nostru îi supără pe atâţia confraţi. Dar tocmai pentru că nu avem nimic de ascuns şi consider că publicul trebuie să ştie toată istoria acestui script, bună şi rea, nici măcar nu încerc să le răspund tuturor celor care ne denigrează aiurea. Fiecare acţionează şi îşi tratează clienţii şi concurenţii după cum îi dictează caracterul.

--

Am zis că în ediţia actuală de MRex, adică v.2.0,  am urmărit să închidem unele breşe de securitate pe care, din fericire, nu le descoperise încă nimeni, mai puţin stimabilul domn Barbu, care s-a şi apucat, în nici un caz din prietenie, să ne facă praf... în public, pe blogul propriu.

Recunosc cinstit că la vremea creării v1 nu am dat nici o atenţie (şi când zic nici o atenţie zic ZERO, NIMIC!) problemelor de securitate, pentru că eram ferm convins că scriptul va fi cumpărat numai de mam & dad care vor avea 100 de vizitatori pe săptămână.  

Având în spate experienţa a peste 100 de magazine online, pot să spun că am inventariat până acum aproximativ 25 de puncte direct vulnerabile ale unei platforme de comerţ virtual.

Atunci când ai în vedere securitatea unui magazin online trebuie să ai în vedere că dacă un hacker bun vrea să ţi-l spargă, ţi-l va sparge. Dar poţi măcar să închizi breşele simple, pe care le-ar putea accesa orice fraier, inclusiv concurenţii. Cele 25.

În ordinea vulnerabilităţii platformele ar sta cam aşa:
  1. platformele open-source: sunt cele mai vulnerabile deoarece codul-sursă e la liber, procedurile de lucru sunt la vedere, informaţia despre breşe circulă rapid pe internet; cu toate acestea o platformă open-source bine securizată are acele 25 de puncte acoperite cu grijă. Magento, de exemplu, e o platformă securizată ireproşabil. Ceva mă face să cred totuşi că dacă se apucă cineva să ia la puricat codul din spate va descoperi breşele.
  2. platformele custom: sunt dezavantajate de lipsa de experienţă a oamenilor din spatele lor. Totuşi, dacă firma din spatele lor are oameni cu experienţă, atunci platformele sunt ok. UltraShop-ul, de exemplu, creat de AvantajNet, are, alături de Emag, una dintre cele mai bine securizate platforme. De aceea morala ar fi: dacă vreţi un magazin virtual custom, măcar făceţi-l cu cineva care are experienţă. În episoadele următoare vom vedea exemple de magazine româneşti care lasă "la liber" lista de clienţi, comenzile etc.
  3. platformele proprietare la cheie (cum e şi MRex): sunt cele mai sigure deoarece a) beneficiază de o experienţă care se îmbogăţeşte continuu şi b) codul lor nu e la liber pe internet. Responsabilitatea e foarte mare, însă, deoarece aceste platforme prezintă de obicei demo-uri publice care pot fi studiate de oricine. Chiar dacă nu se vede codul din spate un ochi versat ştie ce să caute...
În general o platformă de comerţ virtual trebuie să prevină următoarele situaţii:
  • intruziunile directe în aria de administrare;
  • furtul conturilor de client;
  • furtul listei de comenzi;
  • compromiterea procesului de preluare a comenzilor.
Chestiile astea se pot fura fie prin intruziune directă în admin, fie prin simulări (phishing) (nu are rost să vorbim de atacuri brutale de tip flood, care nu ţin de platformă ci de server). Dar chiar şi phishingul poate fi favorizat de micile breşe de securitate. În MRex 2.0, de exemplu, am putut imagina în decursul testării un scenariu care ar fi putut duce la următoarele acţiuni:
  1. obţinerea de către atacator a parolelor de administrare, urmată de
  2. intrarea în admin a atacatorului, urmată de
  3. descărcarea listei de clienţi, urmată de
  4. phishing pentru descoperirea parolelor de cont, urmată de
  5. comenzi false, nu multe, dar măcar 6-7 laptopuri a 4000 de RON bucata, urmată de
  6. falimentarea magazinului, datorită unei pagube de 25000-30000 de RON, suficientă să pună pe butuci chiar şi un magazin pe care în trafic.ro îl vezi pe la 20-25.000 de vizitatori unici.
Tocmai de aceea am căutat să închidem orice posibilă breşă. Şi da, există situaţii în care nici protejarea adminului cu .htaccess nu v-ar ajuta. Mai multe în episodul viitor. Nu vă aşteptaţi însă la exemple concrete (adică să zic cum se face).

Un comentariu:

  1. Anonim15:28

    M-ai spart cu ascunsul codului. Daca si aia e securitate ...

    RăspundețiȘtergere