Unul dintre avantajele de a fi specialist în securitate este lucrul cu numeroase echipe. După un audit, specialiștii în securitate vor avea posibilitatea de a lucra cu administratorii și analiștii bazelor de date. Pentru ca o aplicație să funcționeze corect și în siguranță, aceste echipe încearcă să facă față vulnerabilităților de securitate care au o bază comună. Dialogurile dintre aceste echipe ridică unele probleme cu IP real.
Concepte de proxy și IP real
Aplicațiile web de astăzi rulează pe mai multe servere de aplicații și sisteme de baze de date. Imaginează-ți două servere de aplicații care partajează același cod sursă. Solicitările de la utilizator sunt gata să fie îndeplinite de oricare dintre aceste servere, în funcție de situația de încărcare. Mecanismul de echilibrare a încărcăturii, care gestionează cererile HTTP în fața serverelor de aplicații, decide ce cerere să redirecționeze către ce server de aplicații. Aceasta ridică o mare întrebare pentru administratorii de sisteme middleware și dezvoltatorii de software: care este adresa IP reală a utilizatorului?
Proxy-ii sunt responsabili de transmiterea datelor între două sisteme. Echilibratorul de încărcare este mecanismul responsabil de proxy. Cu alte cuvinte, un singur sistem comunică atât cu utilizatorul, cât și cu serverul de aplicații. În ceea ce privește traficul de rețea, serverele web A sau web B comunică întotdeauna cu adresa IP a echilibratorului de încărcare. Același lucru se poate spune despre utilizatori. Pentru profesioniștii în securitate, echilibratorii de încărcare cauzează probleme serioase în atacurile cu injecție SQL bazate pe timp. Cu exceptia principalul obiectiv aici este falsificarea IP.
X-Forwarded-For și relația IP
Luați în considerare relația dintre X-Forwarded-For, dezvoltator și middleware. De exemplu, să presupunem că sarcina dezvoltatorului unei aplicații este să înregistreze toate activitățile, cum ar fi încercările de parole incorecte ale utilizatorilor, cu adresele lor IP. La început, dezvoltatorul va determina adresa IP a utilizatorului atunci când cererea HTTP este îndeplinită cu oportunitatea oferită de limbajul de programare pe care îl folosește și va încerca să utilizeze în continuare aceste date în aplicarea.
Deoarece adresa sa IP va fi fixată pe tot parcursul procesului de dezvoltare, va vedea întotdeauna aceeași adresă în timpul testelor, deoarece, în general, computerele utilizatorilor din rețelele corporative funcționează cu IP static peste adresa MAC. Unitatea va efectua unele teste de acceptare; cu toate acestea, vor exista probleme cu acestea. Unitatea de testare va transmite această problemă dezvoltatorului de software.
În această etapă, dezvoltatorul poate scrie un controler în mediul de dezvoltare și poate vedea cererea HTTP transmisă aplicației în formă brută, deoarece toată lumea are aceeași adresă IP. Acest lucru va duce la lucrul cu X-Forwarded-For.
Informații din antet numit X-Forwarded-For va fi trimis la serverul de aplicații. În această etapă, dezvoltatorul de software își va vedea adresa IP, pe care o controlează cu ipconfig, nu echilibrul de încărcare pe care îl vede în jurnale. Mulți programatori cred că pot rezolva această problemă cu un bloc de cod ca acesta:
funcţiegetIPaddress() {
$ipKeys = matrice(
„HTTP_CLIENT_IP”,
„HTTP_X_FORWARDED_FOR”,
„HTTP_X_FORWARDED”,
„HTTP_X_CLUSTER_CLIENT_IP”,
„HTTP_FORWARDED_FOR”, „HTTP_FORWARDED”,
„REMOTE_ADDR”
);
pentru fiecare ($ipKeys la fel de $key) {
dacă (array_key_exists($key, $_SERVER) Adevărat) {
pentru fiecare (exploda(',', $_SERVER[$key]) la fel de $ip) {
$ip = trim($ip);
dacă (validate_ip($ip)) {
întoarcere $ip;
}
}
}
}
întoarcereisset($_SERVER[„REMOTE_ADDR”])? $_SERVER[„REMOTE_ADDR”]: fals;
}
Acest lucru nu va fi suficient - dezvoltatorul trebuie să verifice dacă valoarea primită este o adresă IP validă.
Totul de mai sus a aparținut părții gestionate de dezvoltator. Dar pentru ca o aplicație să funcționeze corect și în siguranță, echipele — lucrând împreună în teorie, dar în realitate, în puncte extreme unul față de celălalt — încercați să faceți față vulnerabilităților de securitate care au a bază comună. Acum încercați să priviți problema din perspectiva persoanei responsabile de configurarea echilibratorului de încărcare.
Administratorii de sistem ar putea crede că dezvoltatorii înregistrează informații precum X-Forwarded-For, deoarece datele din cererea HTTP nu pot fi de încredere. Acei administratori transmit adesea X-Forwarded-For; cu toate acestea, ei transmit, de asemenea, adresa sursă TCP a sistemului care a trimis cererea ca a doua valoare de antet. Structura True-Client-IP este un bun exemplu în acest sens.
Când puneți toate aceste lucruri împreună, două unități diferite urmează căi diferite pentru aceeași problemă, cunoscută sub numele de falsificarea IP a clientului. Rezultatul este o problemă critică în care nu vor funcționa înregistrarea IP și autorizarea bazată pe IP.
Cum este detectată falsificarea IP a clientului în testele de penetrare?
Majoritatea testerilor de penetrare folosesc Firefox pentru verificările lor de securitate. Ei configurează Firefox cu un simplu add-on, X-Forwarded-For: 127.0.0.1 pentru toate solicitările HTTP. Și astfel, crește posibilitatea de a detecta astfel de vulnerabilități în toate testele de penetrare. Efectuarea unui audit conform Lista de verificare OWASP vă asigură că verificați astfel de vulnerabilități. Cu toate acestea, pentru a detecta vulnerabilitatea X-Forwarded-For, aveți nevoie de un modul în aplicație care să vă afișeze adresa IP sau acțiunile întreprinse.
Cum se rezolvă vulnerabilitatea X-Forwarded-For
Organizațiile au nevoie de un document obligatoriu de dezvoltare a aplicațiilor securizate pentru toate echipele de software și companiile de externalizare. De exemplu, dacă aveți nevoie de o adresă IP de utilizator, compania ar trebui să planifice din timp și să facă din aceasta o regulă cu privire la informațiile din antet pe care le va folosi aici. În caz contrar, echipe diferite vor produce soluții diferite. Dacă o astfel de situație nu poate fi rezolvată, vor intra în joc aplicațiile de externalizare, ceea ce face dificilă măsurarea codurilor sursă. În general, companiile nu vor să urmeze o astfel de cale.
Dar pentru a rezolva această problemă, puteți folosi următoarea regulă F5:
când HTTP_REQUEST {
HTTP:: șterge antetul X-Forwarded-Pentru
HTTP:: inserare antet X-Forwarded-Pentru [IP:: adresa_la distanță]
}
Aceasta elimină câmpul X-Forwarded-For din cererea HTTP din lumea exterioară. Apoi transmite cererea prin adăugarea adresei IP a sistemului care i-a trimis cererea. În acest fel, se creează o listă de încredere pentru software-ul care acționează conform X-Forwarded-For.
Pentru a rezuma, cel mai mare obiectiv aici este de a efectua unele verificări asupra solicitărilor HTTP și de a crea un mediu de încredere. Blocul de cod de mai sus este un exemplu bun pe care îl puteți folosi pentru aceasta.
Cadre de securitate cibernetică și documentație pentru întreprinderi
Unitățile care par a fi independente unele de altele sunt de fapt părți ale unui întreg. De aceea totul trebuie să funcționeze sistematic. Regulile stabilite în prealabil trebuie aplicate între fiecare unitate. Dacă un astfel de sistem de lucru nu este adoptat, pot apărea multe probleme, cum ar fi vulnerabilitatea X-Forwarded-For. Pentru aceasta, totul ar trebui luat în considerare în prealabil și ar trebui utilizată o documentație cât mai cuprinzătoare posibil.
Și fiecare unitate din acest sistem mare trebuie să adopte și să implementeze cadre de securitate cibernetică. Punctul dvs. de plecare ar trebui să fie să cercetați și să învățați logica de lucru a acestor cadre.
