Acum aproximativ un an, noi, cei de la DataLine, ne-am lansat pentru a căuta și analiza vulnerabilități în aplicațiile IT. Serviciul se bazează pe soluția cloud Qualys, despre a cărei funcționare . Pe parcursul unui an de lucru cu soluția, am efectuat 291 de scanări pentru diferite site-uri și am acumulat statistici privind vulnerabilitățile comune ale aplicațiilor web.
În articolul de mai jos vă voi arăta exact ce găuri în securitatea site-ului web se ascund în spatele diferitelor niveluri de criticitate. Să vedem ce vulnerabilități a găsit scanerul mai ales, de ce ar putea apărea și cum să vă protejați.
Qualys împarte toate vulnerabilitățile aplicațiilor web în trei niveluri de criticitate: scăzut, mediu și ridicat. Dacă te uiți la distribuția după „severitate”, se pare că totul nu este atât de rău. Există puține vulnerabilități cu un nivel ridicat de criticitate, majoritatea sunt necritice:
Dar necritic nu înseamnă inofensiv. De asemenea, pot provoca daune grave.
Cele mai importante vulnerabilități „non-critice”.
- Vulnerabilitati de conținut mixt.
Standardul pentru securitatea site-ului web este transferul de date între client și server prin protocolul HTTPS, care acceptă criptarea și protejează informațiile împotriva interceptării.
Unele site-uri folosesc continut mixt: Unele date sunt transferate prin protocolul HTTP nesecurizat. Așa este cel mai des transmis continut pasiv – informații care afectează doar afișarea site-ului: imagini, stiluri css. Dar uneori așa se transmite continut activ: scripturi care controlează comportamentul site-ului. În acest caz, folosind un software special, puteți analiza informații cu conținut activ care provin de la server, puteți modifica răspunsurile din mers și puteți face ca mașina să funcționeze într-un mod care nu a fost intenționat de creatorii săi.
Versiunile mai noi de browsere avertizează utilizatorii că site-urile cu conținut mixt sunt nesigure și blochează conținutul. Dezvoltatorii de site-uri web primesc și avertismente de browser în consolă. De exemplu, așa arată înăuntru :
De ce este periculos?: Atacatorii folosesc un protocol nesecurizat pentru a intercepta informațiile utilizatorului, pentru a înlocui scripturile și pentru a trimite cereri către site în numele acestuia. Chiar dacă un vizitator al site-ului nu a introdus date, acest lucru nu îl protejează de phishing – obținerea de informații confidențiale prin metode frauduloase. De exemplu, folosind un script, puteți redirecționa utilizatorul către un site nesigur care se preface ca unul familiar utilizatorului. În unele cazuri, site-ul rău intenționat arată chiar mai bine decât originalul, iar utilizatorul poate completa singur formularul și poate trimite date confidențiale.Ce ar trebui să-și amintească un dezvoltator web: Chiar dacă administratorul site-ului a instalat și configurat un certificat SSL/TLS, poate apărea o vulnerabilitate din cauza unei erori umane. De exemplu, dacă pe una dintre pagini ai pus nu un link relativ, ci un link absolut de la http, și în plus nu ai configurat redirecționări de la http la https.
Puteți detecta conținut mixt pe un site folosind un browser: căutați codul sursă al paginii, citiți notificările în consola pentru dezvoltatori. Cu toate acestea, dezvoltatorul va trebui să joace codul pentru o lungă perioadă de timp și plictisitor. Puteți accelera procesul cu instrumente automate de analiză, de exemplu: , software gratuit Lighthouse sau software plătit Screaming Frog SEO Spider.
De asemenea, vulnerabilitatea poate apărea din cauza unor probleme cu codul moștenit - codul care a fost moștenit. De exemplu, dacă unele pagini sunt generate după un șablon vechi, care nu ține cont de trecerea site-urilor la https.
- Cookie-uri fără steagurile „HTTPOnly” și „secure”.
Atributul „HTTPOnly” protejează cookie-urile împotriva procesării de către scripturi pe care atacatorii le folosesc pentru a fura datele utilizatorilor. Indicatorul „securizat” nu permite trimiterea cookie-urilor în text clar. Comunicarea va fi permisă numai dacă se folosește protocolul securizat HTTPS pentru a trimite cookie-uri.
Ambele atribute sunt specificate în proprietățile cookie:
Set-Cookie: Secure; HttpOnlyDe ce este periculos?: Dacă dezvoltatorul site-ului nu a specificat aceste atribute, un atacator ar putea intercepta informațiile utilizatorului din cookie și s-ar putea exploata. Dacă cookie-urile sunt folosite pentru autentificare și autorizare, acesta va putea deturna sesiunea utilizatorului și va putea efectua acțiuni pe site în numele său.
Ce ar trebui să-și amintească un dezvoltator web: De regulă, în cadrele populare aceste atribute sunt setate automat. Dar totuși verificați configurația serverului web și setați steag-ul: Set-Cookie HttpOnly; Sigur.
În acest caz, atributul „HTTPOnly” va face cookie-urile invizibile pentru propriul dumneavoastră JavaScript.
- Vulnerabilități bazate pe cale.
Scanerul raportează o astfel de vulnerabilitate dacă găsește un fișier accesibil public sau un director de site-uri web cu informații potențial confidențiale. De exemplu, detectează fișierele individuale de configurare a sistemului sau accesul la întregul sistem de fișiere. Această situație este posibilă dacă drepturile de acces sunt setate incorect pe site.
De ce este periculos?: Dacă sistemul de fișiere „iese în afară”, un atacator poate cădea în interfața sistemului de operare și poate încerca să găsească foldere cu parole dacă acestea sunt stocate în text clar (nu face asta!). Sau puteți fura hash-urile parolei și parola cu forța brută și, de asemenea, puteți încerca să creșteți privilegiile în sistem și să vă aprofundați în infrastructură.
Ce ar trebui să-și amintească un dezvoltator web: Nu uitați de drepturile de acces și configurați platforma, serverul web, aplicația web astfel încât să fie imposibil să „escape” directorul web.
- Formulare pentru introducerea datelor sensibile cu completarea automată activată.
Dacă un utilizator completează frecvent formulare de pe site-uri web, browserul său stochează aceste informații folosind funcția de completare automată.
Formularele de pe site-uri web pot include câmpuri cu informații sensibile, cum ar fi parole sau numere de card de credit. Pentru astfel de câmpuri, merită să dezactivați funcția de completare automată a formularelor de pe site-ul propriu-zis.
De ce este periculos?: Dacă browserul utilizatorului stochează informații sensibile, un atacator le poate intercepta ulterior, de exemplu prin phishing. În esență, un dezvoltator web care a uitat de această nuanță își configurează utilizatorii.
Ce ar trebui să-și amintească un dezvoltator web: În acest caz, avem un conflict clasic: comoditate vs securitate. Dacă un dezvoltator web se gândește la experiența utilizatorului, el poate alege în mod conștient completarea automată. De exemplu, dacă este important să urmați – recomandări pentru accesibilitatea conținutului pentru utilizatorii cu dizabilități.
Pentru majoritatea browserelor, puteți dezactiva completarea automată cu atributul autocompete="off", de exemplu:
<body> <form action="/ro/form/submit" method="get" autocomplete="off"> <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="Credit card number"> </div> <input type="submit"> </form> </body>Dar nu va funcționa pentru Chrome. Acest lucru este ocolit folosind JavaScript, o variantă a rețetei poate fi găsită .
- Antetul X-Frame-Options nu este setat în codul site-ului.
Acest antet afectează etichetele cadru, iframe, încorporare sau obiect. Cu ajutorul acestuia, puteți interzice complet încorporarea site-ului dvs. într-un cadru. Pentru a face acest lucru, trebuie să specificați valoarea X-Frame-Options: deny. Sau puteți specifica X-Frame-Options: sameorigin, apoi încorporarea într-un iframe va fi disponibilă numai pe domeniul dvs.
De ce este periculos?: Absența unui astfel de antet poate fi folosită pe site-uri rău intenționate pentru clickjacking. Pentru acest atac, atacatorul creează un cadru transparent deasupra butoanelor și păcălește utilizatorul. De exemplu: escrocii încadrează paginile de rețele sociale pe un site web. Utilizatorul crede că face clic pe un buton de pe acest site. În schimb, clicul este interceptat și solicitarea utilizatorului este trimisă către rețeaua de socializare unde există o sesiune activă. Acesta este modul în care atacatorii trimit spam în numele utilizatorului sau câștigă abonați și aprecieri.
Dacă nu dezactivați această funcție, un atacator vă poate plasa butonul aplicației pe un site rău intenționat. El poate fi interesat de programul tău de recomandare sau de utilizatorii tăi.
Ce ar trebui să-și amintească un dezvoltator web: Vulnerabilitatea poate apărea dacă X-Frame-Options cu o valoare conflictuală este setată pe serverul web sau echilibrul de încărcare. În acest caz, serverul și echilibratorul vor rescrie pur și simplu antetul, deoarece au o prioritate mai mare în comparație cu codul backend.
Valorile de negare și aceeași origine ale antetului X-Frame-Options vor interfera cu funcționarea vizualizatorului web Yandex. Pentru a permite utilizarea iframe-urilor pentru vizualizatorul web, trebuie să scrieți o regulă separată în setări. De exemplu, pentru nginx îl puteți 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 (import de foi de stil relativ la cale).
Aceasta este o vulnerabilitate în stilul site-ului. Apare dacă link-uri relative precum href="/ro/somefolder/styles.css/" sunt folosite pentru a accesa fișierele de stil. Un atacator va profita de acest lucru dacă găsește o modalitate de a redirecționa utilizatorul către o pagină rău intenționată. Pagina va insera un link relativ în adresa sa URL și va simula un apel de stiluri. Veți primi o solicitare precum badsite.ru/…/somefolder/styles.css/, care poate efectua acțiuni rău intenționate sub pretextul unui stil.
De ce este periculos?: Un fraudator ar putea exploata această vulnerabilitate dacă găsește o altă gaură de securitate. Ca urmare, este posibil să furați datele utilizatorului din cookie-uri sau token-uri.
Ce ar trebui să-și amintească un dezvoltator web: Setați antetul X-Content-Type-Options la: nosniff. În acest caz, browserul va verifica tipul de conținut pentru stiluri. Dacă tipul este altul decât text/css, browserul va bloca solicitarea.
Vulnerabilitati critice
- O pagină cu un câmp de parolă este transmisă de la server pe un canal nesecurizat (formularul HTML care conține câmpuri de parolă este difuzat prin HTTP).
Răspunsul de la server pe un canal necriptat este vulnerabil la atacurile „Man in the middle”. Un atacator poate intercepta traficul și se poate intercepta între client și server pe măsură ce pagina se deplasează de la server la client.
De ce este periculos?: Fraudatorul va putea înlocui pagina și va putea trimite utilizatorului un formular pentru date confidențiale, care va ajunge la serverul atacatorului.
Ce ar trebui să-și amintească un dezvoltator web: Unele site-uri trimit utilizatorilor un cod unic prin e-mail/telefon în loc de o parolă. În acest caz, vulnerabilitatea nu este atât de critică, dar mecanismul va complica viața utilizatorilor.
- Trimiterea unui formular cu autentificare și parolă printr-un canal nesigur (Formularul de conectare nu este trimis prin HTTPS).
În acest caz, un formular cu autentificare și parolă este trimis de la utilizator la server printr-un canal necriptat.
De ce este periculos?: Spre deosebire de cazul precedent, aceasta este deja o vulnerabilitate critică. Este mai ușor să interceptați datele sensibile, deoarece nici măcar nu trebuie să scrieți cod pentru a face acest lucru.
- Utilizarea bibliotecilor JavaScript cu vulnerabilități cunoscute.
În timpul scanării, cea mai folosită bibliotecă a fost jQuery cu un număr mare de versiuni. Fiecare versiune are cel puțin una sau chiar mai multe vulnerabilități cunoscute. Impactul poate fi foarte diferit în funcție de natura vulnerabilității.
De ce este periculos?: Există exploit-uri pentru vulnerabilități cunoscute, de exemplu:
Ce ar trebui să-și amintească un dezvoltator web: Reveniți regulat la ciclu: căutați vulnerabilități cunoscute - reparați - verificați. Dacă utilizați biblioteci vechi în mod deliberat, de exemplu pentru a susține browsere mai vechi sau pentru a economisi bani, căutați o oportunitate de a remedia o vulnerabilitate cunoscută. - Cross-site scripting (XSS).
Cross-Site Scripting (XSS), sau cross-site scripting, este un atac asupra unei aplicații web care are ca rezultat introducerea de malware în baza de date. Dacă Qualys găsește o astfel de vulnerabilitate, înseamnă că un potențial atacator poate sau și-a introdus deja propriul script js în codul site-ului pentru a efectua acțiuni rău intenționate.XSS stocat mai periculos, deoarece scriptul este încorporat pe server și executat de fiecare dată când pagina atacată este deschisă în browser.
XSS reflectat mai ușor de realizat, deoarece un script rău intenționat poate fi injectat într-o solicitare HTTP. Aplicația va primi o solicitare HTTP, nu va valida datele, le va împacheta și o va trimite imediat. Dacă un atacator interceptează traficul și inserează un script ca
<script>/*+что+то+плохое+*/</script>atunci va fi trimisă o cerere rău intenționată în numele clientului.
Un exemplu izbitor de XSS: js sniffers care simulează pagini pentru introducerea CVC, data de expirare a cardului și așa mai departe.
Ce ar trebui să-și amintească un dezvoltator web: În antetul Content-Security-Policy, utilizați atributul script-src pentru a forța browserul client să descarce și să execute cod numai dintr-o sursă de încredere. De exemplu, script-src 'self' pune pe lista albă toate scripturile de pe site-ul nostru.
Cea mai bună practică este codul inline: permiteți numai JavaScript inline folosind valoarea unsafe-inline. Această valoare permite utilizarea js/css inline, dar nu interzice includerea fișierelor js. În combinație cu script-src 'self' dezactivăm executarea scripturilor externe.Asigurați-vă că înregistrați totul folosind report-uri și priviți încercările de implementare a acestuia pe site.
- Injectii SQL.
Vulnerabilitatea indică posibilitatea de a injecta cod SQL într-un site web care accesează direct baza de date a site-ului web. Injectarea SQL este posibilă dacă datele de la utilizator nu sunt verificate: nu sunt verificate pentru corectitudine și sunt imediat utilizate în interogare. De exemplu, acest lucru se întâmplă dacă un formular de pe un site web nu verifică dacă intrarea se potrivește cu tipul de date.De ce este periculos?: Dacă un atacator introduce o interogare SQL în acest formular, el poate bloca baza de date sau poate dezvălui informații confidențiale.
Ce ar trebui să-și amintească un dezvoltator web: Nu aveți încredere în ceea ce vine din browser. Trebuie să vă protejați atât pe partea client, cât și pe partea serverului.
Pe partea clientului, scrieți validarea câmpului folosind JavaScript.
Funcțiile încorporate în cadrele populare ajută, de asemenea, să scape de personajele suspecte de pe server. De asemenea, se recomandă utilizarea interogărilor de baze de date parametrizate pe server.
Stabiliți unde exact are loc interacțiunea cu baza de date pe aplicația web.
Interacțiunea are loc atunci când primim orice informație: o solicitare cu un id (schimbarea id-ului), crearea unui nou utilizator, un nou comentariu sau noi intrări în baza de date. Aici pot apărea injecții SQL. Chiar dacă ștergem o înregistrare din baza de date, injectarea SQL este posibilă.
recomandări generale
Nu reinventați roata - folosiți cadre dovedite. De regulă, 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 furnizorilor și actualizați regulat. Vor găsi o vulnerabilitate, apoi vor scrie o exploatare, o vor pune la dispoziția publicului și totul se va întâmpla din nou. Abonați-vă la actualizări ale versiunilor stabile de la furnizorul de software.
Verificați drepturile de acces. Pe partea de server, tratează-ți întotdeauna codul ca și cum, de la prima până la ultima literă, a fost scris de cel mai urât dușman al tău, care dorește să-ți spargă site-ul, să încalce integritatea datelor tale. Mai mult, uneori acest lucru este adevărat.
Folosiți clone, site-uri de testare și apoi folosiți-le pentru producție. Acest lucru va ajuta, în primul rând, să evitați greșelile și greșelile într-un mediu productiv: un mediu productiv aduce bani, un mediu productiv simplu este critic. Când adăugați, remediați sau închideți orice problemă, merită să lucrați într-un mediu de testare, apoi să verificați funcționalitățile și vulnerabilitățile găsite și apoi să planificați lucrul cu mediul de producție.
Protejați-vă aplicația web cu și să integreze rapoartele de la scanerul de vulnerabilități cu acesta. De exemplu, DataLine folosește Qualys și FortiWeb ca un pachet de servicii.
Sursa: www.habr.com