Dezvoltarea web modernă are multe provocări, iar securitatea acestora este atât foarte importantă, cât și adesea subevidențiată. În timp ce astfel de tehnici precum analiza amenințărilor sunt din ce în ce mai recunoscute ca fiind esențiale pentru orice dezvoltare serioasă, există și câteva practici de bază pe care fiecare dezvoltator le poate și ar trebui să le facă, de la sine înțeles.

aplicațiilor

05 ianuarie 2017

Cade Cairns este un dezvoltator de software cu o pasiune pentru securitate. Are experiență în conducerea echipelor care creează totul, de la aplicații de întreprindere la software de testare a securității, aplicații mobile și software pentru dispozitive încorporate. În prezent, accentul său principal este să ajute la îmbunătățirea modului în care sunt abordate problemele de securitate în timpul ciclului de viață al livrării soluției.

Daniel Somerfield este lider tehnic la ThoughtWorks, unde lucrează cu clienții construind sisteme care să le satisfacă nevoile de afaceri și să fie rapide, flexibile și sigure. Daniel este un avocat al infrastructurii imuabile și al automatizării în cloud ca vehicul pentru a avansa starea livrării sigure și agile la ThoughtWorks și în industria în general.

Cuprins

  • Încredere
  • Respingeți introducerea neașteptată a formularului
    • Intrare de încredere
    • Validare intrare
    • In practica
    • În concluzie
  • Codificați ieșirea HTML
    • Riscuri de ieșire
    • Codare ieșire
    • Atenționări și avertismente
    • În concluzie
  • Parametrii de legare pentru interogările bazei de date
    • Micile Mese Bobby
    • Legarea parametrilor la salvare
    • Cod curat și sigur
    • Concepții greșite comune
    • Funcții de legare a parametrilor
    • În concluzie
  • Protejați datele în tranzit
    • HTTPS și Transport Layer Security
    • Obțineți un certificat de server
    • Configurați-vă serverul
    • Folosiți HTTPS pentru orice
    • Folosiți HSTS
    • Protejați cookie-urile
    • Alte riscuri
    • Verificați configurația
    • În concluzie
  • Hash and Salt Parolele utilizatorilor dvs.
    • Trăind periculos
      • Riscurile
    • Pot Hash Passwordz
    • Un strop de sare
    • Folosiți un hash care merită sarea
    • Încă o dată cu Hashing
    • Sfaturi finale
    • În concluzie
  • Autentificați utilizatorii în siguranță
    • Înțelegeți opțiunile dvs.
    • Autentificați din nou pentru acțiuni importante
    • Ascundeți dacă există utilizatori
    • Prevenirea atacurilor de forță brută
    • Nu utilizați acreditări implicite sau codificate în mod dur
    • În cadre
    • În concluzie
  • Protejați sesiunile utilizatorilor
    • Generați identificatori de sesiune siguri
    • Nu expuneți identificatorii de sesiune
    • Protejați-vă cookie-urile
    • Gestionarea ciclului de viață al sesiunii
    • Verifică-l
    • În cadre
    • În concluzie
  • Autorizați acțiuni
    • Autorizați pe server
    • Refuză implicit
    • Autorizați acțiuni privind resursele
    • Utilizați politica pentru a autoriza comportamentul
      • Implementarea RBAC
      • Implementarea ABAC
    • Alte modalități de modelare a politicii
    • Considerații privind implementarea
    • În concluzie

Barele laterale

Dezvoltatorul de software modern trebuie să fie ceva de genul unui cuțit elvețian. Desigur, trebuie să scrieți cod care să îndeplinească cerințele funcționale ale clienților. Trebuie să fie rapid. În plus, vă așteptați să scrieți acest cod pentru a fi ușor de înțeles și extensibil: suficient de flexibil pentru a permite natura evolutivă a cerințelor IT, dar stabil și fiabil. Trebuie să puteți stabili o interfață utilizabilă, să optimizați o bază de date și să configurați și să întrețineți adesea o conductă de livrare. Trebuie să poți face aceste lucruri până ieri.

Undeva, în josul listei de cerințe, în spatele, rapid, ieftin și flexibil este „sigur”. Adică, până când ceva nu merge bine, până când sistemul pe care îl construiți este compromis, atunci brusc securitatea este, și a fost întotdeauna, cel mai important lucru.

Securitatea este o preocupare multifuncțională un pic ca Performanța. Și puțin diferit de Performanță. La fel ca Performanța, proprietarii de afaceri știu adesea că au nevoie de securitate, dar nu sunt întotdeauna siguri cum să o cuantifice. Spre deosebire de Performanță, de multe ori nu știu „suficient de sigur” când o văd.

Deci, cum poate un dezvoltator să lucreze într-o lume cu cerințe de securitate vagi și amenințări necunoscute? Pledarea pentru definirea acestor cerințe și identificarea acestor amenințări este un exercițiu demn, dar care necesită timp și, prin urmare, bani. De cele mai multe ori dezvoltatorii vor funcționa în absența unor cerințe specifice de securitate și, în timp ce organizația lor se luptă cu găsirea de modalități de a introduce probleme de securitate în procesele de admisie a cerințelor, vor construi în continuare sisteme și vor scrie cod.

  • subliniază zonele comune dintr-o aplicație web pe care dezvoltatorii trebuie să le conștientizeze în mod deosebit riscurile de securitate
  • oferiți îndrumări despre cum să abordați fiecare risc pe stive web comune
  • evidențiați greșelile obișnuite pe care le fac dezvoltatorii și cum să le evitați

Securitatea este un subiect masiv, chiar dacă reducem domeniul de aplicare doar la aplicații web bazate pe browser. Aceste articole vor fi mai aproape de un „best-of” decât un catalog cuprinzător cu tot ceea ce trebuie să știți, dar sperăm că va oferi un prim pas direcționat pentru dezvoltatorii care încearcă să accelereze rapid.

Încredere

Înainte de a sări în piulițele de intrare și ieșire, merită menționat unul dintre cele mai importante principii fundamentale de securitate: încrederea. Trebuie să ne întrebăm: avem încredere în integritatea cererii care vine din browserul utilizatorului? (indiciu: noi nu). Avem încredere că serviciile din amonte au făcut treaba pentru ca datele noastre să fie curate și sigure? (indiciu: nu). Avem încredere că conexiunea dintre browserul utilizatorului și aplicația noastră nu poate fi modificată? (indiciu: nu complet.). Avem încredere că serviciile și magazinele de date de care depindem? (indiciu: am putea.)

Desigur, la fel ca securitatea, încrederea nu este binară și trebuie să ne evaluăm toleranța la risc, criticitatea datelor noastre și cât trebuie să investim pentru a ne simți confortabil cu modul în care ne-am gestionat riscul. Pentru a face acest lucru într-un mod disciplinat, probabil că trebuie să trecem prin procesele de modelare a riscurilor și amenințărilor, dar acesta este un subiect complicat care trebuie abordat într-un alt articol. Deocamdată este suficient să spunem că vom identifica o serie de riscuri pentru sistemul nostru, iar acum că acestea sunt identificate, va trebui să abordăm amenințările care apar.

Respingeți introducerea neașteptată a formularului

Formularele HTML pot crea iluzia controlului intrărilor. Autorul marcării formularului ar putea crede că, deoarece restricționează tipurile de valori pe care un utilizator le poate introduce în formular, datele se vor conforma acestor restricții. Dar fii sigur, nu este altceva decât o iluzie. Chiar și validarea formularului JavaScript din partea clientului nu oferă absolut nicio valoare din perspectiva securității.

Intrare de încredere

În ceea ce privește încrederea noastră, datele provenite din browserul utilizatorului, indiferent dacă furnizăm formularul sau nu, și indiferent dacă conexiunea este protejată prin HTTPS, sunt efectiv zero. Utilizatorul ar putea modifica foarte ușor marcajul înainte de al trimite sau poate utiliza o aplicație de linie de comandă precum curl pentru a trimite date neașteptate. Sau un utilizator perfect nevinovat ar putea trimite fără să vrea o versiune modificată a unui formular de pe un site web ostil. Aceeași politică de origine nu împiedică trimiterea unui site ostil către punctul dvs. final de gestionare a formularului. Pentru a asigura integritatea datelor primite, validarea trebuie gestionată pe server.

Dar de ce datele malformate reprezintă o problemă de securitate? În funcție de logica aplicației și de utilizarea codificării de ieșire, invitați posibilitatea unui comportament neașteptat, scurgeri de date și chiar furnizarea unui atacator cu o modalitate de a sparge limitele datelor de intrare în cod executabil.

De exemplu, imaginați-vă că avem un formular cu un buton radio care permite utilizatorului să selecteze o preferință de comunicare. Codul nostru de gestionare a formularelor are logică de aplicație cu un comportament diferit în funcție de acele valori.

Acest cod poate fi sau nu periculos, în funcție de modul în care este implementată metoda sendError. Avem încredere că logica din aval procesează corect conținutul care nu este de încredere. S-ar putea. Dar s-ar putea să nu fie. Suntem mult mai bine dacă putem elimina în totalitate posibilitatea unui flux de control neprevăzut.

Deci, ce poate face un dezvoltator pentru a reduce la minimum pericolul ca intrarea de încredere să aibă efecte nedorite în codul aplicației? introduce validare intrare.

Validare intrare

Validarea intrărilor este procesul de asigurare a datelor de intrare în concordanță cu așteptările aplicației. Datele care nu se încadrează în setul de valori așteptat pot determina aplicația noastră să producă rezultate neașteptate, de exemplu, încălcând logica de afaceri, declanșând erori și chiar permițând unui atacator să preia controlul asupra resurselor sau asupra aplicației în sine. Intrarea care este evaluată pe server ca cod executabil, cum ar fi o interogare în baza de date, sau executată pe client ca HTML JavaScript este deosebit de periculoasă. Validarea intrării este o primă linie importantă de apărare pentru a proteja împotriva acestui risc.

Dezvoltatorii construiesc adesea aplicații cu cel puțin o validare de intrare de bază, de exemplu pentru a se asigura că o valoare este nulă sau că un număr întreg este pozitiv. Gândirea la modul de a limita în continuare intrarea la doar valori acceptabile din punct de vedere logic este următorul pas către reducerea riscului de atac.

Validarea intrărilor este mai eficientă pentru intrările care pot fi limitate la un set mic. Tipurile numerice pot fi de obicei limitate la valori dintr-un anumit interval. De exemplu, nu are sens ca un utilizator să solicite transferul unei sume negative de bani sau să adauge câteva mii de articole în coșul de cumpărături. Această strategie de limitare a intrării la tipuri acceptabile cunoscute este cunoscută sub numele de validare pozitivă sau listă albă. O listă albă ar putea să se limiteze la un șir al unui anumit formular, cum ar fi o adresă URL sau o dată a formei „aaaa/ll/zz”. Ar putea limita lungimea de intrare, o singură codificare acceptabilă a caracterelor sau, pentru exemplul de mai sus, numai valorile disponibile în formularul dvs.

Un alt mod de a gândi validarea intrărilor este că este aplicarea contractului pe care codul dvs. de gestionare a formularului îl are cu consumatorul său. Orice încălcare a contractului este invalidă și, prin urmare, respinsă. Cu cât contractul dvs. este mai restrictiv, cu atât este mai agresiv aplicat, cu atât mai puțin probabil ca aplicația dvs. să cadă pradă vulnerabilităților de securitate care decurg din condiții neprevăzute.

Va trebui să faceți o alegere cu privire la exact ce să faceți atunci când intrarea eșuează validarea. Cea mai restrictivă și, probabil, cea mai de dorit este să o respingem în totalitate, fără feedback și să ne asigurăm că incidentul este notat prin înregistrare sau monitorizare. Dar de ce fără feedback? Ar trebui să oferim utilizatorului nostru informații despre motivul pentru care datele sunt dezactivate? Depinde puțin de contractul tău. În exemplul de formă de mai sus, dacă primiți orice altă valoare decât „e-mail” sau „text”, se întâmplă ceva amuzant: fie aveți o eroare, fie sunteți atacat. Mai mult, mecanismul de feedback ar putea oferi punctul de atac. Imaginați-vă că metoda sendError scrie textul înapoi pe ecran ca un mesaj de eroare de genul „Nu putem răspunde cu tipul de comunicare”. Totul este în regulă dacă tipul de comunicare este „porumbel purtător”, dar ce se întâmplă dacă arată așa?

V-ați confruntat acum cu posibilitatea unui atac XSS reflexiv care fură cookie-urile de sesiune. Dacă trebuie să oferiți feedback utilizatorului, cel mai bine vă va fi oferit un răspuns predefinit care să nu revină la datele de utilizator de încredere, de exemplu „Trebuie să alegeți e-mail sau text”. Dacă într-adevăr nu puteți evita redarea intrării utilizatorului înapoi la acestea, asigurați-vă absolut că este codată corect (a se vedea mai jos pentru detalii despre codarea ieșirii).