Category Archive website security

Byhackeradvisor

Cum se dezactivează Directory Listing pe un server Web

In timp ce navigam pe internet, cei mai multi dintre noi ne asteaptam sa vedem doar paginile oferite. Cu toate acestea, uneori, ajungem la o lista de fisiere care s-ar putea vizualiza ca in Windows Explorer, spre deosebire de o pagina web. Aceasta se numeste o listare de director ( Directory Listing) . Acesta metoda este folosita uneori pentru a oferi fisiere cu usurinta pe internet, dar neintentionat, poate permite unui atacator sa obtina informatii valoroase despre site-ul dumneavoastra.

 

De ce ai vrea sa elimini Directory Listing ? 

 

Listingul directorului se poate intampla in doua modalitati. In primul rand, un atacator ar putea vizualiza toate fisierele dintr-un director web. Acest lucru a permite sa vada fisierele care nu ar putea fi legate de ce ofera site-ul dvs., inclusiv fisierele care pot include informatii sensibile, cum ar fi fisiere backup script ( index.php ~ sau index.php.bak), htaccess, sau fisiere text cu note (password.txt!)

 

Cealalta metoda in schimb este mult mai periculoasa. Unele servere de web sunt de configurate, astfel incat home web este de fapt home user, astfel incat trimiterea anumitor sintaxe, in bara de adresa de web poate permite listarea unor directoare in afara structurii normale a directorului web. Acest lucru este mai periculos, deoarece un atacator poate fi capabil sa gaseasca si sa execute programe de pe server prin intermediul browser-ului.

 

Este posibil ca vulnerabilitatea Directory Listing sa ma expuna unui atac ?

 

In general, acest lucru nu este o amenintare la adresa securitatii, deoarece permite atacatorului numai sa obtina informatii. Cu toate acestea, informatiile colectate vor ajuta atacatorul sa analizeze site-ul dvs. pentru a gasi punctele slabe, si ar putea conduce la un atac de succes.Iin cel mai rau caz, aceasta vulnerabilitate ar putea permite atacatorilor sa atace serverul de web imediat folosind URL-ul.

 

In cazul in care unul sau mai multe directoare contin un fisier secret, cum ar fi un fisier de parole sau un fisier cheie, atacatorii ar putea sa-l fure. In plus, Directory Traversal poate permite uneori hackerilor sa acceseze fisiere din afara directorului web radacina, ceea ce duce la furtul de fisierele de sistem, sau poate conduce la alte atacuri.

 

Cum se dezactiveaza Directory Listings in Apache

 

Daca utilizati serverul de web Apache, puteti dezactiva navigarea prin directoare. Este recomandabil sa urmati pasii de mai jos, asta in cazul in care nu doriti sa limitati acesul utilizatorilor. In acest caz, trebuie sa activati urmatoarele de mai jos, si sa setati exceptii pentru directoarele pe care doriti sa le afisati.

 

  • Navigati la fisierul de configurare Apache (httpd.conf)
  • Deschideti fisierul de configurare cu ajutorul unui editor de text ca vi (vi httpd.conf)
  • Cauta sectiunea de director de fisier unde se afla site-ul dvs., si cuvantul cheie Optiuni.
  • Ar trebui sa arate ceva de genul:

 

 

<Directory /home/mywebuser/public_html>
	Options Indexes 
</Directory>

 

 

  • Actualizati optiunea „Indexes” din cele de mai sus, astfel incat linia ar trebui sa citeasca:

 

Options -Indexes

 

Daca fisierul de configurare arata diferit, este in regula. Singura actiune importanta,  este sa va asigurati, ca indexurile au un semn minus sau doar cuvantul  ‘None’. De fapt, daca nu aveti nevoie de alte optiuni, cel mai bine este sa-l setati la ‘None’, de la bun inceput.

 

Daca nu aveti acces la configuratia principala Apache, puteti face acelasi lucru in fiecare folder prin includerea liniei respective in fisierul .htaccess din fiecare subdirector. Acest lucru se va realiza in mod eficient aceeasi actiune, dar trebuie sa fiti atenti sa blocati, de asemenea, posibilitatea de vizualizare htaccess.

 

Resurse Suplimentare

 

Byhackeradvisor

Detectarea Integer Overflow in Site-urile Web

Ce inseamna detectarea Integer Overflow?

 

Integer Overflow este un tip de atac care dateaza inca de pe vremea primelor limbaje de programare, bazat pe limitele de intreg și pe design-ul numerelor. Limbajele de programare iau decizii bazate pe modul in care pot stoca diferite tipuri de informatii. Datele integer, spre exemplu, sunt adesea depozitate într-un anumit numar predefinit de biti și octeti. Mergand mai jos, catre codul binar, imaginați-va că aveți doar 4 biți pentru a stoca codul, din 0000 (0) 1111 (15). In cazul în care un program a folosit 15 pentru anumite date, iar apoi a adăugat un 1 pentru a obține 16, binar ar arata ca 10000. Cu toate acestea, limbajul de programare verifica numai la ultimele 4 cifre binare, astfel incât programul vede 0000 – zero!

 

In realitate, gama de cifre necesare pentru a produce un astfel de efect, este mult, mult mai mare. De multe ori, intervalul nu este format numai din numere pozitive, dar si numerele negative de asemenea. Astfel, cand o serie de numere se „rastoarna” aaa cum se vede mai sus, s-ar merge la cel mai mic număr, care poate fi negativ sau zero.

 

Imaginați-va un scenariu de atac în cazul în care un site cere unui utilizator sa faca o plata pentru o anumita suma de bani. Atacatorul stie ca site-ul va scadea valoarea platii din balanta pentru a obtine valoarea finala. Un atacator ar putea crea un numar special, care va profita de aceasta rasturnare, pentru a crea o balanta negativa, fara sa plateasca nimic!

 

In aplicatie utilizatorul introduce valori integer pentru a initia anumite actiuni, cum ar fi citirea si scrierea memoriei pe un sistem. Totodata, daca site-ul dumneavoastra trimite valori integer definite de catre utilizator catre un sistem de operare, acel program ar putea fi vulnerabil catre aceste tipuri de atacuri integer, care pot duce la comprimiterea sistemului, si ar trebui evitate cu atentie.

 

Cum afecteaza asta securitatea mea ?

 

Integer Overflows sunt mult mai greu de exploatat decat alte vulnerabilitati scanate pe site-ul dvs.

Totusi, sunt alte vulnerabilitati mult mai serioase, care pot fi folosite pentru compromite intregul sistemul sau chiar modificarea datelor intr-un mod nedorit.

 

Prevenirea Integer Overflow

 

Multe limbaje web sunt securizate impotriva integer overflow. Ele se comportă asa cum te-ai aștepta – returnarea valorii maxime a unui intreg în cazul în care suma este prea mare, in locul unui roll over. Cel mai bun mod de a preveni aceste tipuri de atacuri este de a menține biblioteca software actualizata.

 

Daca acest lucru nu este posibil, și o scanare a site-ului returneaza vulnerabilitati integer overflow, atunci ar trebui să analizeze cu atenție atat intrarile primite de la utilizator cat și operațiunile relizate pe el. Definirea unei valori maxime și minime care ar avea sens pentru site-ul dumneavoastră este prim pas. In cazul platilor, nici o plată de mai mare de o mie de lei nu este acceptată, și nimic nu sub 0. Prevenirea ca utilizatorii sa nu introduca alte valori integer in sistem ar impiedica orice atac de tip integer overflow asupra datelor utilizatorului.

 

Resurse Suplimentare

Byhackeradvisor

Divizarea raspunsului header-ului HTTP

Divizarea raspunsului header-ului HTTP este un atac menit sa fure datele utilizatorilor de pe un site. Poate fi folosit pentru a executa atacuri de tip cross site scripting, pentru furtul datelor utilizatorilor sau pentru alterarea design-ului unui site, astfel incat sa para ca asa a fost creat de catre proprietar.

 

Cat de serioasa este divizarea raspunsului HTTP ?

 

De fiecare dată când un browser solicită o pagină web, informații cunoscute sub numele de header-e sunt trimise de la pagina cate browser. Acestea îndeplinesc funcții importante, cum fi, sa transmita browser-ului ce limbă ar trebui să afișeze, în cazul în care ar trebui să fie executate anumite actiuni, precum și modul în care site-ul a fost scris. Spre exemplu, aici este un antet de probă de la Google:

 

http://www.google.com/
GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive

In timpul scrierii codului site-ului, exista multe situatii in care ati vrea sa actualizati dau sa setati dvs. header-ul. De exemplu, o actiune uzuala, este de a stabili antetul referrer în PHP. Ca o simplă ilustrare de divizare a răspunsului, sa presupunem ca ati avut un cod care a stabilit un antet folosind un parametru găsit în URL-ul (un parametru GET):

<?php
header("Location: ".$GET['redirect']);
?>

Acest cod va seta header-ul cu locația pentru pagina ta. O persoană rău intenționata ar putea recunoaște acest lucru, și ar putea să încerce să modifice header-ele trimise de pagina ta. Dacă observați header-ul de exemplu (pagina de Google) fiecare tip de header începe de pe o linie nouă. Un atacator ar putea modifica modul în header-ul este setat prin schimbarea adresei URL:

www.mysite.com/page1.php?redirect="www.a badsite.com"

 

Dar acest exemplu nu este cel mai rău lucru care se poate întâmpla. Dat fiind faptul ca sfârșiturile de linie vin intre antete, un atacator ar putea schimba chiar intregul mod de afisare al site-ului dvs.:

www.mysite.com/page1.php?redirect=\r\nContent-type:text/html\r\n<html>new site!</html>

Acest lucru ar introduce un header nou (content type) și un cod HTML, care va fi plasat în partea de sus a paginii, ca si cand ar fi trebuit sa fie acolo. URL-ul introdus de mai sus nu este un atac complet (ar fi necesare mai multe header-e) dar ilustrează modul în care funcționează un atac de acest fel.

 

Cum afecteaza asta securitatea mea ?

 

Divizarea de header este la fel de periculoasa ca si orice alt atac menit sa fure informatii de utilizatorii de pe site.

Indemnarea unui utilizator sa faca click pe aceste adrese speciale nu este atat de dificil pe cat pare, din moment ce un atacator poate posta o astfel de adresa pe un forum popular, in tag-uri html <img>. Sunt multe alte modalitati de a pacali utilizatorul sa acceseze o anumita adresa.

Prin urmare, divizarea antetelor ar trebui sa fie considerata la fel de periculoasa ca si orice alta modalitate de furt al datelor de utilizator cum ar fi cross site scripting.

 

Prevenirea Divizarii Raspunsului

 

Ca multe alte atacuri, acesta se bazează pe datele transmise de către utilizator, sau care pot fi modificate de către utilizator. De fiecare dată cand setați informațiile de headet în interiorul aplicatiei dumneavoastră, asigurați-vă că datele nu pot fi modificate de catre un utilizator, sau ca sunt securizate corespunzator. Acest lucru se poate face pentru informațiile din header prin verificarea cu atenție a datelor de intrare, si a lungimii lor.

Chiar daca datele sunt verificate, nu există o soluție universala pentru orice atac posibil, dar verificarea datelor este un prim pas. Elimina caracterele cum ar fi Line Feed (\ r, sau LF, și alte variante) șau New Line (\ n, CR, precum și alte variante).

In cele din urma, asigurati-va ca serverul dvs. și codul web scripting sunt actualizate. PHP incepand cu versiunea 5.1.2 a adaugat mecanisme de aparare pentru divizarea header-ului, daca se utilizează codul de header descris mai sus. Pastrarea tuturor aspectelor legate de serverului dvs. actualizate poate ajuta la blocarea celor mai comune forme de atac.

 

Resurse Suplimentare

 

HTTP Response Splitting How To
Response Splitting Examples

 

Cauta Setarile necorespunzatoare pe serverul tau

HackerAdvisor.com  include scanari numeroase si diferite, care te vor ajuta sa-ti securizezi site-ul, inclusiv te vor ajuta sa desscoperi daca esti divizarea header-ului HTTP.

Byhackeradvisor

Directory Traversal

Directory Traversal este abilitatea de a trece de la un director la altul. Servere web seteaza de obicei un singur subdirector pentru a fi accesat public, prin browserele web, iar restul de directoare sa fie cu acces limitat.

Atacurile Directory Traversal

 

Daca sunteti autentificat pe server ca si utilizator, ati putea rula comenzi pentru a va deplasa in directoare pe server:

 

[username:/export/home/user/public_html/] cd ..
[username:/export/home/user/]

Atacurile de tip Directory Traversal (cunoscute si sub numele de atacuri „dot dot slash”) cauta sa exploateze aceasta comanda text, si sa gaseasca vulnerabilitati in implementarea programelor sau scripturilor pentru a accesa date sau fisiere in afara directorului web setat ca fiind public.

 

Cea mai veche modalitate de a executa acest atac, este direct din fereastra de tastare URL-uri a browser-ului web in sine. Daca ar fi sa navigam in bara de tastare URL-uri, am putea cere browser-ului sa afiseze un director mai mare.

www.mysite.com/index.html -> maps to /export/home/user/public_html/index.html


stim ca un fisier special, numit showSecrets.php este in directorul inaccesibil /export/home/user/secrets, asa ca vom incerca sa pacalim browser-ul sa afiseze fisierul prin accesarea urmatorului URL:

www.mysite.com/../secrets/showSecrets.php -> maps to /export/home/user/secrets/showSecrets.php

 

Daca serverul web nu este securizat impotriva acestui tip de atac, va afisa showsecrets.php!

 

O alta metoda mai putin cunoscuta, foloseste date de intrare pentru a cere site-ului dvs., sa returneze fisiere. Imaginati-va ca ati avea implementate unele functionalitati pentru a prelua fisiere dintr-un anumit director, si sa afiseaza o lista a acestor fisiere utilizatorilor. Cand un utilizator da click pe fisier, vei trimite anumite date catre o noua adresa URL, pentru a afisa fisierul.

URL:

www.mysite.com/getFile?fileName.txt

 

Codul PHP pentru a gasi si afisa fisierul:

 

<?php
$filename=$_GET["getFile"];	//get the filename from the URL
$fh = fopen("/export/home/user/public_html/files/".$filename, "R");	//open file for reading
echo fread($fh, filesize($filename));	//read and display contents
?>

 

Un atacator poate observa acest lucru, si sa modifice URL-ul pentru a solicita un fisier secret, similar cu ceea ce am vazut mai sus:

www.mysite.com/getFile?../../secrets/showSecrets.php

Site-ul afiseaza acum continutul fisierului secret atacatorului! Fisierul PHP se deschide si ar arata asa:

/export/home/user/public_html/files/../../secrets/showSecrets.php -> maps to /export/home/user/secrets/showSecrets.php

 

Cum afecteaza asta securitatea mea ?

 

Directory traversal poate fi foarte periculos, dat fiind faptul ca expune informatii private pe internet. Atacatorii pot folosi acest acaesta metoda pentru a descarca fisiere personale, sau pentru a ataca in diferite moduri sistemul dumneavoastra. In functie de modul in care fisierele sunt accesate folosind aceasta metoda, atacatorii pot fi in masura sa execute procese pe server, pot descarca fisiere cu parole sau pot a expune codul sursa pentru analize suplimentare, in vederea lansarii de noi atacuri.

 

Prevenirea Directory Traversal

 

Pentru atacuri bazate pe browser (punerea … / in URL-ul browser-ului), actualizarea software-ul serverului ar trebui sa corecteze vulnerabilitatea la acest atac. Recent serverele web, inclusiv IIS si Apache, ofera protectie impotriva acestui tip de atac Directory Traversal.

Atacul de tip Directory Traversal este mai greu de identificat si prevenit. Cea mai buna aparare impotriva lui este filtrarea datelor introduse de utilizator. Aceste date pot proveni din cookie-uri, din formulare de intrare (POST si GET), din URL-uri, precum si orice alte surse de date care pot fi influentate de catre un utilizator. Directory Traversal poate surveni in diverse forme. Asigurati-va ca verificati cel putin urmatoarele substitute, sau mai bine puneti intr-un whitelist toate intrarile posibile ale utilizatorilor.

  • ..
  • %2e%2e urmat de / or %2f
  • %c1%1c si similar Unicode strings care s-ar translata la  ../

De asemenea, puteti testa ca lungimea path-ului catre fisier trebuie sa fie de o lungime exacta. In exemplele date anterior, calea catre:

/export/home/user/public_html/files/

contine exact 36 de caractere. Orice altceva diferit de aceasta valoare, este invalid.

Resurse Suplimentare

Wikipedia Directory Traversal

 

Cauta Setarile necorespunzatoare pe serverul tau

HackerAdvisor.com  include scanari numeroase si diferite, care te vor ajuta sa-ti securizezi site-ul, inclusiv te vor ajuta sa desscoperi daca esti vulnerabil la Directory Traversal.

 

Byhackeradvisor

Vulnerabilitatile Format String

 

Ce inseamna atacurile impotriva vulnerabilitatilor Format String ?

 

Limbajele de programare in mod uzual permit utilizatorilor să formateze afisarea sau prezentarea în diverse moduri, sau de a introduce o sectiune de date in alta, printr-un șir formatat. Un exemplu comun în sistemele de programare este afișarea output-ului a unui utilizator. Spre exemplu, am putea avea o funcție pe o linie, care afiseaza ceva date pe ecranul utilizatorului :

 

printf("Welcome %s!", username);

 

Dacă utilizatorul introduce ceva de genul John, am vedea următoarea ieșire de pe ecran: „Bine ai venit, John!”. Cu toate acestea, in conditiile in care variabila username (numele de utilizator) nu este validata, atunci un atacator poate executa, ceea ce este cunoscut ca fiind un atac Format String. Funcția printf indicata mai sus, permite o serie de caractere de control (cum ar fi %), pentru a defini formatul datelor așteptate. În cazul în care un atacator poate insera caractere de control suplimentare in șir, printf poate cauta date pentru a le introduce intre placeholdere, facand posibila accesarea a diferite locatii ale memoriei, sau chiar executarea unor coduri arbitrare.

 

Cele mai multe discutii legate de atacurile Format String au fost purtate in comunitatea desktop software, în care comenzile mai vechi C cum ar fi printf erau mai frecvente. Totusi aceste functii au migrat de asemenea si pe net, si majoritatea exemplelor de Format String sunt mai ascunse decat cele de mai sus.

 

Cum afecteaza asta securitatea mea ?

 

Atacurile Format String pot conduce catre atacuri de tipul denial of service, si in anumite cazuri sunt folosite pentru a afecta memoria serrver-ului (care conduc ca serverul dvs. web, cum ar fi IIS sau Apache sa se blocheze). In anumite cazuri, atacurile Format String pot fi folosite pentru a fura date, sau chiar pentru a executa coduri arbitrare. Executarea de cod arbitrar ar putea permite unui atacator să preia controlul asupra server-ului web.

 

Prevenirea atacurilor asupra vulnerabilitatilor Format String

 

Atacurile de tip Format String apar datorita ne-sanitizarii datelor utiilizator trimise catre o functie care foloseste formatari string. Asta nu inseamna neaparat date catre sunt trimise inapoi catre utilizator sau catre afisaj, ar putea fi date care apeleaza interogari in baza de date, functii de log-are, sau functii de sistem. De obicei semnul (%) este folosit pentru a indica un formator string, deci eliminarea acestuia este un prim pas.

 

In general, funcțiile de sistem sunt securizate impotriva vulnerabilitatilor de tip Format String pe masura ce sunt descoperite. In PHP, de exemplu, cele mai recente actualizări pot oferi protectie impotriva celor mai recent descoperite vulnerabilitati de tip string format. Actualizarea versiunii limbajului de programare, la cea mai recentă, va va oferi cea mai mare protecție împotriva acestor tipuri de atacuri. De mentionat este ca totusi, aceste upgrade-uri la codul de bază ar putea necesita modificări in site-ul dvs., astfel încât ar trebui să fie testate temeinic inainte de implementare.

 

Resurse Suplimentare

 

Format String Vulnerabilities in Various Programming Languages
Format String Examples

 

HackerAdvisor.com  include scanari numeroase si diferite, care te vor ajuta sa-ti securizezi site-ul, inclusiv te vor ajuta sa descoperi daca esti vulnerabil la atacuri de tip Format String.

Byhackeradvisor

Evitarea atacurilor posibile prin vulnerabilitatile URL

Site-urile pot trimite dinamic utilizatorii către alte pagini web folosind redirecționări. În cazul în care nu au fost validate în mod corespunzător, un atacator poate folosi acest lucru pentru a redirectiona utilizatorii care vizitează un site de încredere catre site-ul atacatorului. Acest lucru nu afectează imediat site-ul dvs., dar permite atacatorilor să folosească utilizatorii care au încredere în site-ul dvs. pentru a-i convinge să viziteze site-uri infectate sau site-uri phishing aflate sub controlul atacatorilor.

 

Cum poate un atacator sa redirecteze userii folosind vulnerabilitatile URL

Atacatorul poate furniza un link care pare de încredere pentru un utilizator obisnuit. Imaginați-vă o bancă on-line cu datele de conectare clientului, care oferă un url cum ar fi:

 

 www.bank.com?next=login.html

 

Site-ul bancii se asteapta ca utilizatorul sa fie redirectionat catre o pagina de autentificare. Un atacator ar putea publica o adresa (prin email sau internet) catre:

 

 www.bank.com?next=attackersite.html

 

Acest link va directiona de fapt utilizatorii care fac clic pe el catre site-ul atacatorului, chiar dacă URL-ul pare autentic. Site-ul atacatorului ar putea fi făcut să arate identic cu site-ul băncii reale, astfel incat se pot fura datele de autentificare ale utilizatorilor in momentul in care încearcă să se log-eze.

 

Impactul Redirect-arii

 

Vulnerabilitatea care permite atacul de redirecționare poate fi utilizata în alte tipuri de atacuri cross site scripting, catre site-ul dvs., care pot fi mult mai periculoase pentru site sau utilizatori. In unele cazuri, motoarele de cautare (google) pot decide ca site-ul tau este periculos pentru securitatea utilizatorului, si ii vor miscora nota acestuia sau il vor bloca in rezultatele de cautare.

Mai grav, utilizatori sunt expusi riscurilor sa isi piarda conturile sau anumite informatii. Revenind la exemplul de mai sus, in cazul în care clientul bancii se astepta la un formular de autentificare, iar atacatorul creează un formular de autentificare fals, identic sau asemanator cu cel real, atunci orice client legitim care încearcă să se conecteze pentru utilizarea site-ului, ii va dezvalui atacatorul numele de utilizator și parola. Afacerea dvs. online ar putea fi inchisa in urma unei astfel de brese de securitate, din cauza neincrederii si pagubelor create utilizatorilor.

Prevenirea Atacurilor efectuate prin redirect-area URL-urilor

 

Cauza principala a unui astfel de atac de redirectare, este validarea în mod necorespunzător la intrare a solicitarilor GET sau POST, care este apoi transformata într-o comandă de redirecționare. În PHP, s-ar putea vedea următorul cod care este vulnerabil la un atac de redirecționare:

<?PHP
header('Location: ',$_GET['myurl']);
?>

Comanda GET indica datele trimise in URL, astfel incat site-ul tau sa aiba o adresa URL valida pentru clienti, de genul:

http://www.mysite.com?myurl=see_products.html

Un atacator ar putea în schimb convinge utilizatorii să folosească link-ul următor, care i-ar directiona catre un site de atacatori:

http://www.mysite.com?myurl=http://www.doing_evil.com/infect_this_pc


Același lucru poate fi realizat si cu parametrii POST, dar site-ul atacatorul nu va apărea in URL, ceea ce l-ar face mai greu de detectat de catre pentru utilizatori (codul PHP de mai sus ar include POST in loc de GET, în acest caz).

Pentru rectificarea acestei probleme, este nevoie sa valitate parametrii GET sau POST sa contina numai adrese la care vreti sa ajunga userii.

Există trei moduri principale de a remedia acest tip de atac:

  1. Crearea unei Whitelist in care sa se adauge modele de intrare pentru URL-uri legitime, in care aveți încredere, sau mai simplu, folosirea unei liste explicite de URL-uri permise.
  2. Creați o cartografiere a unor identificatori unici pentru URL-uri. De exemplu, ID-1 ar putea mapa mysite.com/page1, apoi acceptă numai de intrare, care este conform cu un număr cunoscut, și care sa refuze orice alta intrare.
  3. Setarea redirectarilor, astfel incat in situatia in care se intampla, sa notifice utilizatorii ca vor fi trimisi catre un alt site, si ei sa confirme ca sunt de acord cu acest lucru.

Resurse suplimentare

URL Redirector Abuse
HTTP Response Splitting
URL Redirection to Untrusted Site (Analysis)

Cauta setarile necorespunzatoare pe site-ul tau

HackerAdvisor.com  include scanari numeroase si diferite, care te vor ajuta sa-ti securizezi site-ul, inclusiv te vor ajuta sa descoperi daca ai setari facute necorespunzator care te fac vulnerabil la atacuri prin URL.

Byhackeradvisor

Securitatea Web Cache pentru Site-ul tau

Caching-ul este o metoda prin care continutul site-urilor este stocat local, in alt loc decat cel in care site-ul este gazduit. Acesta este de obicei un proxi rulat de catre ISP pentru imbunatatirea performantei utilizatorului final si scaderea cerintelor de banda.

 

Directivele Web Cache si Riscurile Asociate

 

Caching-ul poate oferi o imbunatatire de performanta semnificativa site-ului dvs., dat fiind faptul ca vizitatorii vad continutul de pe proxy-urile fizice mai aproape de ei, usurand server-ul dvs. de aceasta sarcina, sau prin afisarea de continut care a fost deja vizualizat.

Anumite tipuri de continut, pot fi compromise daca nu sunt cache-uite corect. Imaginati-va urmatorul scenariu:

Maria viziteaza un site de intalniri si vede un mesaj de la cineva. Cateva secunde mai tarziu, Alex, primeste aceeasi instiintare dar vede ca mesajul este destinat catre Maria. Ce s-a intamplat ? ISP-ul local a stocat o copie a paginii Mariei si atunci cand Alex a incercat sa o vada, proxy-ul local i-a trimis lui Alex o copie a paginii lui Maria crezand ca totul este in regula. Astfel, datele Mariei au fost compromise !

 

Un scenariu cu pontential de risc mai ridicat, implica caching-ul incorect al cookie-urilor. Imaginati-va un scenariu similar cu cel de mai sus, dar de data aceasta nu doar pagina a fost cache-uita, ci si cookie-urile de autentificare care au fost trimise catre Maria. Acum, Alex, doar prin solicitarea acelei pagini, este autentificat ca si Maria. Cum se poate intampla asta ? Similar povestii de mai sus, proxy-ul local, a considerat faptul ca cookie-urile ar trebui cache-uite si returnate catre Alex fara sa realizeze ca aceastea erau cook-iurile unei sesiuni, folosite pentru a determina cine este utilizatorul.

 

Pierderea datelor si a Conturilor

 

Asa cum este ilustrat si mai sus, acesta problema de securitate poate avea un impact moderat, conducand la posibila pierdere a datelor utilizatorului sau un risc mare, conducand la pierderea completa a contului.

Poate fi clasificata ca fiind cu risc mare de securitate, daca detaliile cache-uite sunt cookie-urile sesiunii de utilizator si de imapact moderat daca datele pierdute nu sunt cookie-urile. In acest caz, pot fi dezvaluite datele contului sau identitatea utilizatorului poate fi furata. Dezvaluirea datelor cu caracter personal sau detaliile unui cont, poate genera o bresa de incredere a utilizatorilor in securitatea oferita de site, iar aceasta situatie ar trebui corectata imediat.

 

Prevenirea Web Caching-ului incorect

 

Aceasta vulnerabilitate, vine impreuna cu cache-uirea gresita a directivelor header. Daca activati cache-ingul Apache implicit, este posibil ca Apache sa decida cum sa fie cache-uita fiecare bucatica de continut. Este de datoria administratorului de site sa se asigure ce date nu ar trebui cache-uite. Definirea elementelor care sa nu fie cache-uite este un proces simplu.

Pentru prevenirea cacheing-ului, setati urmatoarele directive header pentru fiecare bucata de continut care nu ar trebui cache-uita:

Expires: Fri, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
Cache-control: no-cache, must-revalidate

De asemenea, se poate seta acest lucru si in PHP, folosind directive header, astfel :

<?php
  header("Cache-Control: no-cache, must-revalidate"); 	 // HTTP/1.1
  header("Pragma: no-cache");   			 // Just in case
  header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); 	 // Date in the past
?>

Poti lua in considerare de asemenea setarea cache-ului ca si privat (pentru a fi stocat doar in calculatorul utilizatorului final) pentru a avea anumite beneficii cache, in timp ce iti protejezi site-ul impotriva proxy-urilor care trimit continutul paginii tale catre alti utilizatori. Cititi anumite articole din sectiunea “resurse” pentru a intelege mai bine anumite directive si cum poti fi ele utilizate pentru cresterea securitatii datelor utilizatorului.

 

Resurse Suplimentare

Apache Caching
Caching How to & Security considerations
Caching with PHP
HTTP Caching RFC

 

Cauta Setarile necorespunzatoare pe serverul tau

HackerAdvisor.com  include scanari numeroase si diferite, care te vor ajuta sa-ti securizezi site-ul, inclusiv te vor ajuta sa desscoperi daca ai setari facute necorespunzator pe serverul web, atat legate de web caching cat si alt gen de setari.

Byhackeradvisor

Prevenirea Atacurilor de Tip Cross Site Scripting (Atac CSRF)

XSRF, cunoscut si sub numere de cross site request forgery sau CSRF, poate fi folosit pentru a pacali un utilizator autentificat sa faca anumite modificari neintentionate pe site. Profita de increderea pe care o ofera site-ul tau utilizatorilor deja autentificati.

 

Ce inseamna Cross Site Request Forgery?

 

Pentru ca un astfel de atac sa fie realizat cu succes, site-ul tau trebuie sa identifice utilizatorii inregistrati cu ajutorul cookie-urilor, si acestia trebuie sa fie autentificati la momentul vizitei pe site sau sa acceseze link-ul pe care atacatorul l-a pus la dispozitie.

Adesea, atacatorul nu are neaparat nevoie sa convinga utilizatorii sa dea click fizic pe link-ul care declanseaza atacul. Exista o multime de modalitati prin care un utilizator poate sa “acceseze” link-ul atacatorului. De exemplu, orice site la care atacatorul are acces, cum ar fi un forum sau un site de socializare, poate include anumite tag-uri pe imagine care duc catre link-ul atacatorului. Link-ul poate fi construit astfel incat sa forteze browser-ul web al utilizatorului, sa execute o anumita actiune folosindu-se de sesiunea deja deschisa pe site, impreuna cu alte riscuri care vin cu accesarea acelei adrese web. In acest fel, cand pagina este incarcata, este ca si cand utilizatorul a accesat intentionat link-ul, iar autentificarea si executatea acelei actiuni se va face fara a se mai solicita re-autentificarea utilizatorului.

 

Daca utilizatorul vizat pentru atac se intampla sa fie administratorul, acest atac ar putea garanta atacatorului controlul complet asupra intregului site.

 

Imaginati-va urmatorul scenariu:

 

  1. Boby navigheaza pe mysite.com, si este autentificat ca si utilizator legitim.
  2. Mysite.com are un buton, care atunci cand este apasat, va trimite automat un e-card la toate contactele lui Boby salvate, automat cu un link.
  3. In timp ce Boby navigheaza, are o intrebare despre anumite functii, si merge pe forumul favorit cu informatii despre mysite.com – mysiteforums.com
  4. El deschide un articol interesant al unui alt utilizator. Acesta contine o eticheta cu imagine care arata in felul urmator:  <img src=’http://www.mysite.com/send-e-cards’/>
  5. Browserul lui Boby incearca sa incarce imaginea, si trimite datele de autentificare ale lui Bob impreuna cu solicitarea pentru mysite.com/send-e-cards.
  6. Mysite.com primeste cererea de la Bob pentru trimiterea e-card-ului, si o trimite.
  7. Atacul a fost realizat cu succes, chiar daca Bob nu a apasat niciodata butonul send.

Acest tip de atac a fost utilizat cu succes in raspandirea virusilor, atat prin intermediul MySpace, cat si Facebook. Atacurile de aceasta natura, faciliteaza autopropagarea, deoarece ataca site-uri unde utilizatorii isi stocheaza informatii personale.

 

Impactul asupra site-ului tau si a bazei de utilizatori

 

Impactul XSRF poate minim sau critic in functie de natura site-ului tau. Este clasificat ca si un caz cu risc minim in timpul scanarii noastre din cauza lipsei de informatii suplimentare necesare pentru evaluarea completa a securitatii, care poate fi facuta numai de proprietarii site-urilor.

XSFR poate fi folosit pentru orice tip de atac, de la pacalirea unui utilizator pentru schimbarea parolei si pana la retragerea de fonduri, daca site-ul permite tranzactii cu banca. Exista posibilitatea prevenirii atacurilor XSRF prin respectarea recomandarilor din sectiunea solutii.

 

Cum sa previi atacurile CSRF ?

 

Prevenirea CSRF presupune modificarea modalitatii de functionare a cererilor de tip GET si POST pe site, pentru a te asigura ca utilizatorii care fac astfel de cereri sunt cei ce le-au facut cu adevarat si ca nu au fost pacaliti in trimiterea acestor cereri. Din cauza modului de operare al atacurilor XSRF, atacatorul nu are niciodata acces la datele din cookie-urile stocate pe calculatoarele tinta si acest lucru poate fi folosit in construirea unui mijloc de aparare.

Profitand de acest lucru, proprietarii de site-uri, pot genera valor unice pentru fiecare formular, astfel incat un atacator sa nu poata ghici aceste valori, inainte ca cererile de tip POST si GET sa fie trimise. Aceasta se numeste nonce sau valoare unica aleatorie.

Pentru implementarea acesteia, trebuie sa incluzi cateva layere logice in site-ul tau :

1. Introdu un camp ascuns in toate formularele de pe site-ul tau, care sunt necesar atunci cand un utilizator se autentifica. De exemplu, in aceasta situatie, il vom numi nonce.

2. Include valoarea nonce in variabilele sesiunii de utilizator, astfel incat utilizatorii sa aiba o copie.

3. Dupa ce toate evaluarile POST sau GET sunt securizate, asigura-te ca variabila nonce din browser (sesiunea) este aceeasi cu variabila nonce din formular (valoarea GET/POST).

4. Daca ele nu conincid, cererea ar putea fi inaintata fraudulos (XSRF).

5. Variabila nonce, poate fi generata pentru fiecare formular nou sau stocata pe server, intr-o baza de date. De retinut este faptul ca, daca este generata una noua de fiecare data, o sa intampinati dificultati cu functionalitatea back din browserele utilizatorilor, sau browserele cu taburi multiple.

 

Aici este un exemplu de cod PHP, care nu salveaza valorile intr-o baza de date:

Prima Pagina ( formularul )

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

Pagina unde  userul face click pe buton

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


Prevent CSRF on Your Website

HackerAdvisor.com  include scanari numeroase si diferite, care te vor ajuta sa-ti securizezi site-ul, inclusiv te vor ajuta sa descoperi amenintari legate de Cross Site Scripting Forgery, sau alte tipuri de atacuri cross site scripting.

Byhackeradvisor

Detalii despre Server – Securitatea Informatiilor transmise prin Headerul HTTP

Serverele web,  de obicei, transmit informatii legate de versiunea de software implicit. Aceasta poate insemna ca transmit informații cum ar fi: sistemul de operare (Linux, Windows, etc), versiunea sistemului de operare, ce fel de server de web se execută (IIS, Apache, etc), și, în unele cazuri, modulele de server web instalate.

 

De ce reprezinta Headerul HTTP un risc pentru securitate ?

 

Aceste informatii depre software sunt stocate in HTTP, si trimise impreuna cu fiecare cerere catre pagina web efectuata de catre un utilizator care viziteaza pagina ta. Ca urmare, este foarte usor pentru oricine, sa afle ce setari foloseste un server sau ce versiune.

Desi aceasta informatie este aparent infensiva, poate dezvalui anumite informatii, legate de configuratia site-ului. Un atacator poate folosi aceste informatii pentru a gasi si crea atacuri specifice pentru sistemul dvs., sau, prin atacuri automatizate, poate cauta configuratii specifice pentru a ataca. Desi este dificil sa impiedici un anumit utilizator sa gaseasca aceste informatii, folosind alte metode, dezactivarea antetelor HTTP, reduce substantial probabilitatea unui atac asupra site-ului.

 

Cum afecteaza aceasta securitatea site-ului meu ?

 

Un atacator poate afla aceste informatii prin diferite metode, insa cele mai multe nu pot fi prevenite cu usurinta. Izolate, aceste informatii reprezinta o valoare mica pentru un atacator.

Cea mai comuna metoda de folosire a acestor informatii, este incercarea de automatizare a atacurilor, cautand pe Google configuratii specifice de server cunoscute pentru vulnerabilitatea lor, sau automatizarea unor atacuri care sunt cunoscute sa functioneze impotriva configuratiilor similare site-ului dvs. Inlaturarea acestor valori transmise prin antetele de server, va preveni aparitia acestor tipuri de atac automatizate.

 

Solutii

Desi nu este neaparat posibil sa previi in totalitate aceste informatii din a fi descoperite, este posibil sa le faci mai greu de indentificat pentru un atacator.  Fiecare server de web va avea nevoie  de o configurare diferita, insa urmeaza sa va prezit cele mai comune setari de configurare (Apache) mai jos. Aceste modificari vor elimina antetele HTTP care transmit date despre configuratia serverului si alte informatii despre tip, contribuind la securitatea site-ului dvs.

Modificari Apache pentru a preveni divulgarea nedorita a informatiilor despre server :

Pentru a modifica configuratia Apache, exista cativa pasi ce trebuiesc urmati. Administratorul va avea nevoie de acces la dosarul de configurare Apache de pe server, si cateva momente pentru a reporni serviciile de web dupa ce se face o schimbare.

  1. Navigati la fisierul httpd.conf. Acesta este situat in etc/httpd/conf sau /etc/apache2  sau /etc/apache.
  2. Deschideti fisierul de configurare folosund un editor de text. Pe Unix, cel mai comun este VI (comanda: vi httpd.conf)
  3. Gasiti linia ServerTokens (in cazul in care utilizati comanda VI, puteti identifica textul in /ServerTokens)
  4. Daca exista linia, actualizati-o astfel incat sa citeasca ServerTokens Prod
  5. Daca linia nu exista, se adauga in partea de jos a fisierului
  6. Asigurati-va ca nu exista alte caractere precum # (indicand un comentariu) care se afla in fata liniei de comanda
  7. Gasiti o linie care sa includa ServerSignature in acelasi fisier
  8. Actualizati aceasta linie, astfel incat sa citeasca ServerSignature Off (asigurati-va de faptul ca linia nu este comentata #)
  9. Daca linia nu exista, o puteti adauga la sfarsitul fisierului
  10. Salvati fisierul de configurare (daca folositi VI, comanda este: WQ)
  11. Reporniti Apache. De obicei httpd restart.

 

Resurse Suplimentare

 

Find Insecure Settings on your Webserver

HackerAdvisor.com include scanari numeroase si diferite, care te vor ajuta sa-ti securizezi site-ul, inclusiv te vor ajuta sa descoperi inclusiv deficientele de configurare ale server-ului web.

Byhackeradvisor

Seturile de caractere si securitatea

Seturile de caractere transmit browserelor ce tip de text primesc de la site-ul dvs., de exemplu, textul în limba engleză sau text în limba chineză. Fiecare document sau pagină de pe site-ul dvs. ar trebui să includă un set de caractere bine definite. Cum ar fi UTF-8 sau USASCII.

 

Cum sunt utilizate in site seturile de caractere?

Prin omiterea unui set de caractere poate duce la situatia in care unele browsere sa fie nevoite sa „ghiceasca” setul corect de caractere. Dacă ele ghicesc în mod incorect, un atacator ar putea genera un script cross site împotriva utilizatorilor. În general, acest lucru nu este o amenințare decât dacă utilizatorii au acces la modificarea sau încărcarea de conținut pe site-ul dumneavoastră.

Folosind un set de caractere incorect este potențial mai rău decât nefolosirea nici unui set de caractere. Un set de caractere incorect poate permite unui atacator să creeze un conținut special pentru a fi trimis catre site-ul dvs., știind dinainte cum va fi interpretat, generand vulnerabilitati de tip cross site scripting.

Cum afecteaza aceasta securitatea mea?

Seturile de caractere incorecte sau lipsa lor ridica gradul de risc al securitatii de la unul cu risc scăzut la unul cu risc ridicat. În cazurile cu impact redus, setul de caractere necorespunzătoare este foarte puțin probabil să conducă la o vulnerabilitate de securitate, dar poate avea un impact pentru utilizatorii din diferite țări, în moduri diferite. Unele browsere pot ghici caracterul setat incorect, conducand ca site-ul dvs. să apară ca și cum ar fi scrias într-o altă limbă. Prin urmare,este indicat ca toate seturile de caractere să fie setat corect, pentru a maximiza gradul de utilizare al site-ului.

Setările pentru seturile de caractere cu grad mai mare de risc sunt stabilite pe renderables, cum ar fi o imagine. Un caracter incorect setat aici poate declansa atacuri cross site scripting, și poate duce la pierderea de date și de informatii private.

Solutii

 

Asigurați-vă că fiecare pagină care conține un text, include de asemenea un set de caractere, și asigurați-vă că setul de caractere este setat corect pentru continutul dvs. În aproape toate cazurile, setul de caractere UTF-8 este o alegere bună pentru text, cu toate acestea pentru fiecare caz specific poate varia. Pentru a seta setul de caractere de pe pagina dvs., includeti tag-uri HTML în partea de sus a fiecărei pagini pentru a rezulta ceva similar cu textul de mai jos. Rețineți faptul că seturile de caractere sunt de multe ori stabilite în același timp, si ca tip de conținut.

<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″>

 

Resurse Suplimentare

Gaseste Setari necorespunzatoare pe Web serverul dvs

 

Hackeradvisor.com, include in procesul de scanare, diferite setari de test, care te vor ajuta sa reduci expunerea site-ului la atacuri, inclusiv impotriva setarilor Setului de Caractere.