Arhivă autor hackeradvisor™

dehackeradvisor™

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:

 

https://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.

dehackeradvisor™

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.

 

dehackeradvisor™

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.

dehackeradvisor™

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:

https://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:

https://www.mysite.com?myurl=https://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.

dehackeradvisor™

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.

dehackeradvisor™

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=’https://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.

dehackeradvisor™

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.

dehackeradvisor™

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.

dehackeradvisor™

Setarea incorecta a credentialelor unui Website


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:password@url.com

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.