Luați măsuri în dezvoltare pentru a întări și a vă asigura securitatea web.


Întreprinderile mici, băncile și multe industrii depind de aplicațiile web. Din momentul în care se construiește o aplicație web, este esențial să fie sigur că există protocoale pentru a verifica vulnerabilitățile pe măsură ce evoluția evoluează pentru a evita încălcările de securitate, scurgerile de date și problemele financiare..

Cele mai periculoase atacuri web sunt cele care apar pe partea serverului unde datele sunt stocate și analizate.

Ce este Backend?

O aplicație web este împărțită în două părți – Frontend și Backend.

  • Frontend-ul este de partea clientului, este partea cu care utilizatorul interacționează. De obicei, este construit cu HTML, CSS și Javascript.
  • Backend-ul este de partea serverului. Practic este modul în care funcționează aplicația, aplică logica de afaceri, modificările și actualizările. Unele dintre cele mai populare stive tehnologice din partea serverului implică PHP, NodeJS, Java, Ruby, C, Python, baza de date, securitate (autentificare, control acces, etc.), structură și gestionarea conținutului.

O mică amintire înainte de a începe – autentificare, control acces & managementul sesiunii

Este comun ca noi să confundăm termenii. Așadar, să o lămurim rapid:

  • Autentificarea se referă la dovedirea identității utilizatorului (de ex. Parola, numele de utilizator, securitatea întrebărilor, amprentele digitale)
  • Controlul accesului se referă la ce utilizatorul poate accesa aplicația. Acesta aplică politica conform căreia utilizatorii nu pot acționa în afara permisiunilor prevăzute.
  • Managementul sesiunii se referă la răspunsuri și la solicitarea tranzacțiilor asociate cu același utilizator. Este un mecanism de schimb care este utilizat între utilizator și aplicație după ce s-a autentificat cu succes.

Să explorăm următoarele pentru o mai bună securitate web.

Defecte de injecție

Din 2010, OSWAP a clasificat injecția drept cel mai periculos risc de aplicație web.

Defectele de injecție permit utilizatorului să furnizeze date care conțin cuvinte cheie care vor modifica comportamentul întrebărilor construite pe baza de date. De exemplu, să presupunem că avem un script SQL care verifică dacă există o intrare potrivită în baza de date.

uname = request.POST [‘nume de utilizator’]
passwd = request.POST [‘parolă’]
sql = "SELECTA id din utilizatorii WHERE username = ‘" + uname + "’ȘI parola =’" + passwd + "’"
database.execute (sql)

Un atacator poate manipula acum câmpul de parolă folosind injecția SQL, de exemplu, introducând parola „OR 1 =” 1, ceea ce duce la următoarea interogare SQL:

sql = "SELECTEAZĂ id-ul utilizatorilor WHERE nume utilizator = ” ȘI parola = ‘parolă’ SAU 1 = ‘1’

Procedând astfel, atacatorul poate accesa toate tabelele utilizatorilor bazei de date, parola fiind întotdeauna valabilă (1 = ‘1’). Dacă se autentifică ca administrator, pot face orice modificări dorește.

Cum să o preveniți?

Este foarte UŞOR pentru a evita defectele de injecție.

Cea mai bună și simplă modalitate de a verifica dacă nu există defecte de injecție este o revizuire completă a codului sursă manuală pentru a verifica dacă întrebările din baza de date se fac prin declarații pregătite. De asemenea, puteți utiliza instrumente pentru a verifica vulnerabilitățile.

Și ar trebui să faceți și următoarele.

  • Utilizați ORM (Instrumente de mapare relațională obiect).
  • Evitați toate intrările. Un câmp de date nu ar trebui să aibă niciodată altceva stocat în ele, cu excepția datelor.
  • Izolați-vă datele astfel încât să fie păstrate doar acele lucruri care ar trebui accesate dintr-o anumită locație.
  • Scrieți codurile de eroare de manipulare bune. Nu faceți baza de date sau backend-ul dvs. prea verosimile.

Troia Vânătoare a primit un curs strălucit la injecția SQL. Dacă sunteți interesat, puteți explora asta.

Autentificare spartă

Așa cum am menționat anterior, autentificarea se ocupă cu datele de acreditare furnizate. Este linia de apărare împotriva accesului fără restricții. Cu toate acestea, implementarea necorespunzătoare și nerespectarea politicii de securitate pot duce la autentificarea stricată.

Autentificarea spartă se întâmplă mai ales prin trei tipare:

  • Materiale de acreditare: în cazul în care atacatorul are o listă de nume de utilizator și parole valide și poate automatiza atacul pentru a se înțelege că datele de acreditare sunt valide.
  • Atac Bruteforce: în cazul în care aplicația permite parole slabe pentru utilizatori sau administratori.
  • Deturnarea sesiunii: unde aplicația expune ID-ul sesiunii, adresa URL sau nu se rotește după autentificare.

În toate cazurile, atacatorul poate avea acces la un cont important și poate depinde de afacerea care poate provoca spălare de bani, furt de identitate sau dezvăluirea informațiilor protejate legal, foarte sensibile.

Cum să o preveniți?

Înainte de a implementa sistemul de autentificare, întrebați-vă – ce ar putea realiza un atacator dacă sistemul de autentificare este compromis?

Și în funcție de răspuns, puteți face următoarele.

  • Implementați autentificarea cu mai mulți factori pentru a preveni atacurile automatizate.
  • Încurajează (sau obligă) utilizatorul să adopte o politică de parolă bună.
  • Limitați autentificările eșuate.
  • Utilizați hash algoritm eficient. Când alegeți un algoritm, luați în considerare lungimea maximă a parolei.
  • Testați sistemul de întrerupere a sesiunii și asigurați-vă că simbolul sesiunii este invalidat după deconectare.

Control de acces rupt

Controlul accesului există pentru a vă asigura ce este permis utilizatorul autentificat. Autentificarea și gestionarea sesiunii sunt regulile de bază sau control de acces. Dar, atunci când aceste reguli nu sunt bine stabilite, acest lucru poate duce la probleme semnificative.

Defectele comune de control de acces includ:

  • Configurare CORS greșită care permite accesul neautorizat la API.
  • Manipularea metadatelor pentru accesul direct la metode.
  • Navigare forțată: atacatorul va încerca o adresă URL, va modifica căile (de exemplu, http: //website.domain/user/ către http: //website.domain/admin) și poate chiar descoperi fișiere importante.

Cum să o preveniți?

În mare parte, defectele de acces rupte apar din necunoașterea cu privire la cerințele esențiale ale unui management eficient al accesului.

  • Refuză implicit, cu excepția resurselor publice.
  • Dezactivați listarea directorilor serverului și asigurați-vă că fișierele de rezervă nu sunt prezente.
  • Votați accesul la limitele API pentru a reduce impactul atacurilor automatizate.
  • Invalidați token-urile JWT după deconectare pe partea backend.

Expunerea datelor

De asemenea, denumită încălcări de date, expunerea datelor este o amenințare cibernetică care amenință întreprinderile și clienții lor.

Se produce atunci când aplicația nu protejează în mod adecvat informații, cum ar fi datele de acreditare sau datele sensibile, cum ar fi cardurile de credit sau înregistrările medicale. Sunt peste 4000 de înregistrări a încălcat în fiecare minut.

Impactul asupra afacerilor este mare din partea financiară: O încălcare medie poate costa 3,92 milioane USD, potrivit IBM.

Cum să o preveniți?

Ca dezvoltator backend, ar trebui să vă întrebați care sunt informațiile care necesită protecție.

Și apoi pentru a preveni astfel de defecte:

  • Criptați datele sensibile: pentru datele de la REST, criptați totul. Pentru datele aflate în tranzit, asigurați-vă că utilizați gateway-uri sigure (SSL)
  • Identificați datele care necesită o protecție suplimentară și limitați accesibilitatea la o mulțime de utilizatori legitimi numai prin aplicarea criptare bazată pe cheie.
  • Evitați algoritmul slab de criptare: utilizați date actualizate și algoritmi puternici.
  • Aveți un plan de rezervă sigur.

Deserializare nesigură

Serializarea și deserializarea sunt concepte utilizate atunci când datele sunt convertite în format obiect pentru a fi stocate sau trimise către o altă aplicație. Serializarea constă în conversia datelor în format obiect, cum ar fi XML sau JSON, pentru a le folosi. Deserializarea este doar procesul invers.

Atacurile împotriva deserializatorilor pot duce la atacuri de refuz de serviciu, control de acces și execuție de cod de la distanță (RCE) dacă există clase care pot fi modificate pentru a schimba comportamentul.

Al doilea exemplu de document OWASP top 10 oferă o bună ilustrare a serializatorului obiectelor PHP:

a: 4: {i: 0; i: 132; i: 1; s: 7:"Mallory"; I: 2; s: 4:"utilizator";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Acesta este un supercookie care conține informații precum ID-ul utilizatorului, nivelul utilizatorului și parola de salvare.

Un atacator poate schimba obiectul serializat pentru a avea acces la privilegiile de administrare:

a: 4: {i: 0; i: 1; i: 1; s: 5:"Alice"; I: 2; s: 5:"admin";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Cum să o preveniți?

Este crucial să nu acceptați obiecte serializate din surse de încredere.

Ar trebui, de asemenea:

  • Nu aveți încredere în introducerea utilizatorului.
  • Validați datele: dacă aplicația dvs., cu excepția unei șiruri, asigurați-vă că este o șir înainte de a o utiliza
  • Folosiți un control pentru a vă asigura că datele nu au fost schimbate. Este util să trimiteți date între două surse de încredere (de exemplu, stocarea datelor din partea clientului).

Server XSS

Server XSS (Scripturi cross-site) este un tip de injecție atunci când un atacator folosește o aplicație web pentru a trimite cod rău intenționat diferiților utilizatori. Se produce atunci când atacatorul postează unele date conținute conținând un cod rău intenționat pe care aplicația îl stochează. Această vulnerabilitate este de partea serverului; browserul redă pur și simplu răspunsul.

De exemplu, într-un forum, postările utilizatorilor sunt salvate într-o bază de date, adesea fără verificare. Atacatorii profită de această ocazie pentru a adăuga postări cu scripturi rău intenționate. Ulterior, alți utilizatori primesc acest link prin e-mail sau văd postarea în cauză și fac clic pe ea.

Cum să o preveniți?

După identificarea principală a tuturor operațiunilor cu potențial risc de XSS și care trebuie protejate, trebuie să luați în considerare următoarele.

  • Validați intrarea: verificați lungimea de intrare, utilizați potrivirea regex și permite doar un anumit set de caractere.
  • Validați ieșirea: Dacă aplicația copiază în răspunsurile sale la orice element de date provenit de la un utilizator sau de la o terță parte, aceste date ar trebui codate HTML pentru a igieniza caracterele potențial dăunătoare.
  • Permiteți limita HTML: de exemplu, dacă aveți un sistem de bloguri de comentarii, permiteți doar utilizarea anumitor etichete. Dacă puteți, utilizați un cadru adecvat pentru marcarea HTML furnizată de utilizator pentru a încerca să vă asigurați că nu conține niciun mijloc de executare a JavaScript.

Concluzie

Faza de dezvoltare este crucială pentru securitatea aplicațiilor web. Și, ar trebui să luați în considerare includerea unui scaner de vulnerabilități de securitate în ciclul de viață al dezvoltării, astfel încât problemele identificate să fie rezolvate înainte de producție.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me