Aproximativ acum un an, am lansat la DataLine un serviciu pentru căutarea și analiza vulnerabilităților în aplicațiile IT. La baza serviciului se află soluția cloud Qualys, despre care . Într-un an de utilizare a soluției, am efectuat 291 de scanări pentru diferite site-uri și am acumulat statistici privind vulnerabilitățile comune în aplicațiile web.
În articolul de mai jos, voi arăta ce tipuri de slăbiciuni în securitatea site-urilor se ascund în spatele diferitelor niveluri de criticitate. Să vedem ce vulnerabilități a descoperit scannerul mai des, de ce pot apărea și cum ne putem proteja.
Toate vulnerabilitățile aplicațiilor web sunt împărțite de Qualys în trei niveluri de criticitate: scăzut, mediu și ridicat. Dacă ne uităm la distribuția în funcție de „seriozitate”, pare că lucrurile nu sunt chiar atât de grave. Vulnerabilitățile cu un nivel ridicat de criticitate sunt puține, majoritatea sunt non-critice:
Dar non-critice nu înseamnă inofensive. Acestea pot cauza daune serioase.
Topul vulnerabilităților „non-critice”
- Vulnerabilități legate de conținutul mixat.
Standardul de securitate pentru site-uri este transferul de date între client și server prin protocolul HTTPS, care suportă criptarea și protejează informațiile de interceptare.
Unele site-uri folosesc conținut mixat: transmit o parte din date prin protocolul nesecurizat HTTP. Adesea, astfel sunt transmise conținutul pasiv – informații care afectează doar afișarea site-ului: imagini, stiluri CSS. Dar uneori, astfel sunt transmise și conținutul activ: scripturi care controlează comportamentul site-ului. În acest caz, cu ajutorul unui software special, se poate analiza informația venită de la server cu conținut activ, modifica răspunsurile în timp real și determina mașina să funcționeze altfel decât a fost gândită de creatorii săi.
Browserele versiunilor recente îi avertizează pe utilizatori că site-urile cu conținut mixat nu sunt sigure și blochează conținutul. De asemenea, dezvoltatorii de site-uri primesc avertizări din partea browserului în consola acestuia. De exemplu, iată cum arată în :
Ce este periculos: Atacatorii folosesc un protocol nesecurizat pentru a intercepta informațiile despre utilizator, a substitui scripturile și a trimite solicitări către site în numele său. Chiar dacă vizitatorul site-ului nu a introdus date, acest lucru nu îl protejează de phishing – extragerea de informații confidențiale prin metode frauduloase. De exemplu, cu ajutorul unui script, utilizatorul poate fi redirecționat către un site nesigur, care se maschează ca fiind unul cunoscut. În anumite cazuri, site-ul malițios arată chiar mai bine decât originalul, iar utilizatorul poate completa de bunăvoie formularul și transmite informațiile confidențiale.Ce trebuie să țină cont un dezvoltator web: Chiar dacă administratorul site-ului a instalat și configurat un certificat SSL/TLS, vulnerabilitatea poate apărea din cauza factorului uman. De exemplu, dacă pe una dintre pagini a fost inserată un link absolut cu http, în loc de unul relativ, și în plus nu au fost configurate redirecționări de la http la https.
Se poate detecta conținut mixt pe site cu ajutorul browserului: căutând în codul sursă al paginii, citind notificările din consola developer-ului. Totuși, dezvoltatorului i se va îngădui să scotocească îndelung în cod. Procesul poate fi accelerat cu ajutoare automatizate de analiză, de exemplu: , software gratuit Lighthouse sau software plătit Screaming Frog SEO Spider.
De asemenea, vulnerabilitatea poate apărea din cauza problemelor cu legacy-code – codul care a fost moștenit. De exemplu, dacă unele pagini sunt generate printr-un șablon vechi, unde nu s-a ținut cont de trecerea site-urilor la https.
- Cookie-uri fără flag-uri „HTTPOnly” și „secure”.
Atributele „HTTPOnly” protejează fișierele cookie de procesarea prin scripturi, pe care atacatorii le folosesc pentru a fura datele utilizatorilor. Flag-ul „secure” nu permite transmiterea cookie-urilor în mod nesecurizat. Schimbul de date va fi permis doar dacă pentru trimiterea cookie-urilor se folosește un protocol securizat HTTPS.
Ambele atribute sunt definite în proprietățile cookie-urilor:
Set-Cookie: Secure; HttpOnlyCe este periculos: Dacă dezvoltatorul site-ului nu a specificat aceste atribute, atacatorul poate intercepta informațiile utilizatorului din cookie-uri și le poate folosi. Dacă cookie-urile sunt folosite pentru autentificare și autorizare, el va putea fura sesiunea utilizatorului și va acționa pe site în numele său.
Ce trebuie să țină cont un dezvoltator web: În general, în framework-urile populare, aceste atribute sunt setate automat. Totuși, verificați configurația serverului web și activați flagul: Set-Cookie HttpOnly; Secure.
Atributul „HTTPOnly” va face cookie-urile invizibile chiar și pentru propriul dvs. JavaScript.
- Vulnerabilități bazate pe cale.
Scanerul raportează o astfel de vulnerabilitate dacă găsește un fișier sau un director accesibil public al site-ului cu informații potențial confidențiale. De exemplu, descoperirea fișierelor separate cu configurația sistemului sau accesul la întreaga sistem de fișiere. Astfel de situații pot apărea dacă permisiunile de acces pe site sunt configurate incorect.
Ce este periculos: Dacă sistemul de fișiere este „expus”, un atacator poate accesa interfața sistemului de operare și poate încerca să găsească foldere cu parole, dacă acestea sunt stocate în format deschis (nu faceți asta!). Sau se pot fura hash-urile parolelor și se poate încerca să se găsească parola prin forță bruta, de asemenea, se pot încerca creșterea privilegiilor în sistem și avansarea în cadrul infrastructurii.
Ce trebuie să țină cont un dezvoltator web: Nu uitați de permisiunile de acces și configurați platforma, serverul web, aplicația web astfel încât să nu se poată „evada” din directorul web.
- Formulare pentru introducerea datelor confidențiale cu funcția de autocompletare activată.
Dacă utilizatorul completează frecvent formulare pe site-uri, browserul său salvează aceste informații folosind funcția de autocompletare.
Formele de pe site-uri pot include câmpuri cu informații confidențiale, cum ar fi parolele sau numerele de carduri de credit. Pentru astfel de câmpuri, ar trebui să dezactivați funcția de autocompletare pe site.
Ce este periculos: Dacă browserul utilizatorului va salva informații confidențiale, un atacator le poate intercepta ulterior prin metode precum phishing-ul. Practic, un dezvoltator web care a uitat de acest aspect expune utilizatorii săi.
Ce trebuie să țină cont un dezvoltator web: În acest caz, avem un conflict clasic: confort vs securitate. Dacă dezvoltatorul web se gândește la confortul utilizatorului, ar putea alege în mod conștient autocompletarea. De exemplu, dacă este important să se respecte – recomandări pentru accesibilitatea conținutului pentru utilizatorii cu dizabilități.
Pentru majoritatea browserelor, funcția de autocompletare poate fi dezactivată prin atributul autocompete="off", de exemplu:
<body> <form action="/ro/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Numărul cardului de crédit"> </div> <input type="submit"> <input type="hidden" name="trp-form-language" value="ro"/></form> </body>Dar pentru Chrome, aceasta nu va funcționa. Se ocolește acest lucru prin JavaScript, iar o variantă a rețetei poate fi găsită. .
- În codul site-ului nu a fost setat antetul X-Frame-Options.
Acest antet influențează etichetele frame, iframe, embed sau object. Cu ajutorul acestuia, se poate interzice complet integrarea site-ului în interiorul unui frame. Pentru aceasta, este necesar să se specificze valoarea X-Frame-Options: deny. Sau se poate specifica X-Frame-Options: sameorigin, atunci integrarea în iframe va fi disponibilă doar pe domeniul dumneavoastră.
Ce este periculos: Absența unui astfel de antet poate fi utilizată pe site-uri dăunătoare pentru clickjacking. Într-un astfel de atac, infractorul creează un frame transparent deasupra butoanelor și păcălește utilizatorul. De exemplu: bandiții plasează într-un frame pe site-ul paginile rețelelor sociale. Utilizatorul crede că dă clic pe un buton de pe acest site. În schimb, clicul este interceptat și trimite solicitarea utilizatorului către rețeaua socială, unde există o sesiune activă. Astfel, infractorii trimite spam în numele utilizatorului sau cresc numărul de abonați și aprecieri.
Dacă nu se interzice această posibilitate, infractorul poate plasa butonul aplicației dumneavoastră pe un site dăunător. El poate fi interesat de programul dumneavoastră de referință sau de utilizatorii dumneavoastră.
Ce trebuie să țină cont un dezvoltator web: Vulnerabilitatea poate apărea dacă X-Frame-Options cu o valoare conflictuală este setat pe serverul web sau pe un echilibror de încărcătură. În acest caz, serverul și echilibrorul de încărcătură vor pur și simplu suprascrie antetul, deoarece au o prioritate mai mare comparativ cu codul părții de backend.
Valorile deny și sameorigin ale antetului X-Frame-Options vor împiedica funcționarea webvizorului Yandex. Pentru a permite utilizarea iframe-ului pentru webvizor, este necesar să scrieți o regulă separată în setări. De exemplu, pentru nginx, se poate configura astfel:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Vulnerabilități PRSSI (Path-relative stylesheet import).
Aceasta este o vulnerabilitate în stilurile site-ului. Ea apare dacă pentru accesarea fișierelor de stil se folosesc linkuri relative de tip href="/somefolder/styles.css/". Infractorul va profita de acest lucru, dacă găsește o modalitate de a redirecționa utilizatorul către o pagină dăunătoare. Pagină va substitui linkul relativ în url-ul său și va imita accesarea stilurilor. Se va genera o solicitare de genul badsite.ru/.../somefolder/styles.css/, care sub măsura unui stil poate desfășura acțiuni dăunătoare.
Ce este periculos: Un escroc va putea profita de această vulnerabilitate dacă găsește o altă breșă de securitate. Ca urmare, se pot fura datele utilizatorilor din cookie-uri sau tokenuri.
Ce trebuie să țină cont un dezvoltator web: Setați antetul X-Content-Type-Options: nosniff. În acest caz, browserul va verifica tipul de conținut pentru stiluri. Dacă tipul diferă de text/css, browserul va bloca cererea.
Vulnerabilități critice
- Pagina cu câmp pentru parolă este livrată de pe server printr-un canal nesecurizat (HTML form containing password field(s) is served over HTTP).
Răspunsul de la server pe un canal necriptat este vulnerabil la atacuri de tip «Man in the middle». Un atacator poate intercepta traficul și se poate interpu între client și server, când pagina este trimisă de la server la client.
Ce este periculos: Un escroc va putea înlocui pagina și trimite utilizatorului un formular pentru datele confidențiale, care vor fi trimise pe serverul atacatorului.
Ce trebuie să țină cont un dezvoltator web: Unele site-uri în loc de parolă trimit utilizatorilor un cod unic pe email/telefon. În acest caz, vulnerabilitatea nu este atât de critică, dar mecanismul va complica viața utilizatorilor.
- Trimiterea formularului cu numele de utilizator și parola printr-un canal nesecurizat (Login Form Is Not Submitted Via HTTPS).
În acest caz, de la utilizator pe server, printr-un canal necriptat este trimis un formular cu numele de utilizator și parola.
Ce este periculos: Spre deosebire de cazul anterior, aceasta este deja o vulnerabilitate critică. Este mai ușor să se intercepteze datele confidențiale, deoarece nu este nevoie să scrieți niciun cod pentru aceasta.
- Utilizarea bibliotecilor JavaScript cu vulnerabilități cunoscute.
În timpul scanării, cea mai utilizată bibliotecă a devenit jQuery, cu un număr mare de versiuni. Fiecare dintre aceste versiuni are cel puțin una sau mai multe vulnerabilități cunoscute. Impactul poate fi variat – depinde de natura vulnerabilității.
Ce este periculos: Pentru vulnerabilitățile cunoscute există exploatative, de exemplu, cele:
Ce trebuie să țină cont un dezvoltator web: Revenirea periodică la ciclu: căutarea vulnerabilităților cunoscute - rezolvarea - verificarea. Dacă utilizați biblioteci învechite conștient, de exemplu pentru a sprijini browserele mai vechi sau pentru a economisi bugetul, căutați posibilitatea de a elimina vulnerabilitățile cunoscute. - Scripturi intersite (XSS).
Cross-Site Scripting (XSS), sau scripturi între site-uri, reprezintă atacuri asupra aplicației web, prin care în baza de date apare un cod malițios. Dacă Qualys găsește o astfel de vulnerabilitate, înseamnă că un potențial atacator poate injecta sau a injectat deja un script js în codul site-ului pentru a desfășura acțiuni malițioase.XSS stocate (Stored XSS) sunt mai periculoase, deoarece scriptul este injectat pe server și este executat de fiecare dată când se deschide pagina atacată în browser.
XSS reflectate (Reflected XSS) sunt mai simple de realizat, deoarece un script malițios poate fi injectat în cererea HTTP. Aplicația primește cererea HTTP, nu verifică datele, le împachetează și le trimite imediat. Dacă atacatorul interceptă traficul și inserează un script de tipul
<script>/*+что+то+плохое+*/</script>atunci un request malițios va pleca în numele clientului.
Un exemplu elocvent de XSS: js-snifferi care imită pagini pentru introducerea CVC, date de expirare a cardului etc.
Ce trebuie să țină cont un dezvoltator web: În antetul Content-Security-Policy, utilizați atributul script-src pentru a permite browserului clientului să încarce și să execute doar cod dintr-o sursă de încredere. De exemplu, script-src 'self' listează în mod acceptat toate scripturile numai de pe site-ul nostru.
Cea mai bună practică este codul inline: permiteți doar javascript inline folosind valoarea unsafe-inline. Această valoare permite utilizarea js/css inline, dar nu interzice conectarea fișierelor js. În combinație cu script-src 'self', interzicem executarea scenariilor externe.Asigurați-vă că înregistrați toate cererile prin report-uri și monitorizați tentativele de injectare pe site.
- Injecțiile SQL.
Vulnerabilitatea indică posibilitatea injectării pe site a unui cod SQL, care se adresează direct bazei de date a site-ului. O injecție SQL este posibilă dacă datele utilizatorului nu sunt escapate: nu sunt verificate pentru corectitudine și sunt utilizate imediat în cerere. De exemplu, acest lucru se întâmplă dacă un formular de pe site nu verifică conformitatea introducerii cu tipul de date.Ce este periculos: Dacă un atacator introduce o cerere SQL în acest formular, poate provoca căderea bazei de date sau poate dezvălui informații confidențiale.
Ce trebuie să țină cont un dezvoltator web: Nu aveți încredere în ceea ce vine din browser. Trebuie să vă protejați atât pe partea clientului, cât și pe partea serverului.
Pe partea clientului, scrieți verificări ale câmpurilor folosind JavaScript.
Funcțiile încorporate în cadrele populare ajută de asemenea la escaparea caracterelor suspicioase pe server. Este recomandat să folosiți interogări parametrizate către baze de date pe server.
Determinați exact unde are loc interacțiunea cu baza de date în aplicația web.
Interacțiunea apare atunci când obținem informații: o solicitare cu id (schimbare id), crearea unui nou utilizator, un nou comentariu – înregistrări noi în baza de date. Aici pot apărea injecții SQL. Chiar dacă ștergem o înregistrare din bază, o injecție SQL este posibilă.
Recomandări generale
Nu inventați bicicleta – utilizați cadre testate.. În general, cadrele populare sunt mai sigure. Pentru .NET – ASP.NET MVC și ASP.NET Core, pentru Python – Django sau Flask, pentru Ruby – Ruby on Rails, pentru PHP – Symfony, Laravel, Yii, pentru JavaScript – Node.JS-Express.js, pentru Java – Spring MVC.
Urmăriți actualizările furnizorului și actualizați regulat.. O vulnerabilitate va fi găsită, apoi va fi scris un exploit, va fi făcut public, și totul se va repeta. Abonați-vă la actualizările versiunilor stabile de la furnizorul de software.
Verificați drepturile de acces.. Din perspectiva serverului, tratați întotdeauna codul dumneavoastră ca și cum totul, de la prima până la ultima literă, ar fi fost scris de cel mai detestat inamic al vostru, care vrea să spargă site-ul și să compromită integritatea datelor dumneavoastră. Mai ales că, uneori, chiar așa este.
Folosiți clonuri, medii de testare, și abia apoi lansați în producție.. Aceasta va ajuta, în primul rând, să evitați erorile și problemele în mediul de producție: mediul de producție generează venituri, iar oprirea lui este critică. Când adăugați, corectați sau închideți orice problemă, ar trebui să efectuați lucrările într-un mediu de testare, să verificați funcționalitatea și vulnerabilitățile găsite, apoi să planificați lucrările cu mediul de producție.
Protejați aplicația web prin și integrați rapoartele de la scannerul de vulnerabilități cu acesta.. De exemplu, în DataLine se utilizează Qualys și FortiWeb ca legătură de servicii.
Sursa: habr.com
