Arhivă autor hackeradvisor

dehackeradvisor

Hacker + Phishing= fraudă

Hackerii sunt experţi în informatică, la fel de buni sau chiar mai buni decăt programatorii, decât dezvoltatorii de programe informatice complexe, decât experţii CIA, devreme ce îi surclasează adesea, aceştia ( hacker-ii) fiind capabili să infecteze zeci de mii de pagini web parolate, protejate prin antiviruşi,  aparţinâd unor instituţii de stat, bănci, agenţii de securitate, ţări, etc. Phshingu-ul, adică încercarea  de a fura informaţiile şi datele cuiva, începând de la utilizatori simpli până la utilizatori de anvergură, cum ar fi  agenţiile guvernamentale, este practicat astăzi cu asupra de măsură la nivel mondial, punând sub semnul întrebării siguranţa programelor informatice complexe, ameninţate şi din alte părţi, ( cutremure, uragane, dereglări climatice sau magnetice, cataclisme, etc.) creând un val de neîncredere general. Nimic nu mai este  sigur pe lumea aceasta! Ebola, de exemplu , pare o nimic toată pe lângă viruşii creaţi şi răspândiţi, la scară planetară, de către hackeri. Giganţi ai internetului precum Yahoo sau Google, servere ale guvernelor, ale poliţiiilor naţionale, băncilor sau chiar ale armatelor, au fost şi sunt atacate permanent, provocând pagube importante şi nelinişe. Societăţile secrete ale userilor nemulţumiţi, transformate  în societăţi de  phishing, controlate de hackeri, precum Anonymus, şi declarate antisistem, antiautoritate, trec la acţiuni concertate împotriva sistemelor corupte, societăţii de consum, inegalităţii, politicului, în general, proferând  ameninţări, atacând informatic sau creând, pur şi simplu, panică  printre oameni. Anonymus aminteşte de congregaţia catolică de pietate, recunoscută chiar de Vatican, Opus Dei, printre fondatorii căreia se numără Sir Isaac Newton, Sandro Botticelli, Victor Hugo şi Leonardo da Vinci, care utilizase, acum aproape patru sute de ani tehnici de constrăngere inimaginabile  de spălare a creierilor, ducând la aşa-zisa „mortificare corporală”, societate anonimă care există şi astăzi.

dehackeradvisor

Protectie site folosind servicii de monitorizare a securitatii

Era internetului a ajutat la dezvoltarea afacerilor online si a facut achizitionarea de produse si servicii mai usoara si mai convenabila. Totusi exista factori de risc care, inevitabil vin la pachet cu o afacere online. Orice afacere deschisa si derulata online se poate confrunta cu un atac al hackerilor profesionisti. Acestia pot cauza pagube semnificative la site-uri, care in ansamblu pot afecta buna functionare a afacerii. Pentru a fi ferit de astfel de riscuri, verificarea securitatii site-ului este esentiala pentru afacerea ta online.

Hackerii profesionisti sunt experti cu vaste cunostinte despre functionarea site-urilor si sistemelor. Totusi, acesti profesionisti isi folosesc talentul intr-un mod negativ producand pagube afacerilor online. Hackerii tin sub observatie site-urile diverselor afaceri online incercand sa gaseasca puncte slabe de acces. Odata descoperite vor viza tranzactiile financiare pentru a putea extrage banii si distruge sistemul. Sunt multe masuri de prevenire care pot asigura site-ul in cazul unor atacuri. Verificarile de securitate si folosirea sigiliilor permit companiilor online sa-si pastreze afacerea securizata cu tranzactii fara probleme si clienti multumiti. Verificarile de securitate te ajuta in protejarea site-ului, iar sigiliile de securitate instiinteaza clientii ca se afla pe un site securizat.

Cateva moduri de protectie si securizare a site-ului:
– Parolele de logare ale utilizatorilor nu ar trebui sa fie citibile in baza de date, in caz contrar dau o sansa hackerului sa acceseze un cont si sa-l foloseasca.

– Functiile de upload trebuie verificate atent. Daca admin-ul permite incarcarea de fisiere pe server, hackerii obtin o sansa de a-si incarca un fisier de acces backdoor. Cel mai bine este ascunderea fisierelor prin redenumire pentru a fi protejate de hackeri.
– In cazul in care site-ul tau este spart, veti observa o scadere drastica a numarului de vizitatori deoarece Google urmareste astfel de pagini care sunt puse sub risc si este oprit accesul spre ele. Acest lucru poate cauza probleme afacerii tale. Este indicat sa faceti un test de penetrare a site-ului pentru a-l putea asigura corespunzator.
– Chiar si pentru o problema minora aparuta este bine sa fie oprit site-ul pana ce va fi complet remediata. Daca nu este rezolvata in timp util, poate duce mai tarziu la probleme serioase pentru site.

 

Sunt foarte multi furnizori in lume, recunoscuti pentru serviciile de securizare a site-urilor. Provensec este unul dintre furnizorii premium pentru servicii de securitate web in Statele Unite. In Romania, oferim solutii excelente de securitate pentru companiile online la preturi foarte mici. Serviciile oferite de companie sunt de incredere, iar afacerea ta este asigurata si protejata de hackeri.

dehackeradvisor

SEO si securitatea Site-urilor

Munca pe care ai depus-o pentru optimizarea unui site este inutila, daca un hacker compromite securitatea site-ului si deraiaza traficul pentru care ai luptat atat de mult.

Un prejudiciu comun pe care un hacker poate sa il faca, este sa injecteze pe site-ul tau un cod, in scopul de a fura trafic, sau pur si simplu pentru a dauna imaginii acestuia. Trebuie sa fii foarte atent. Hackerii pot instala link-uri daunatoare site-ului, pe care nimeni nu le poate vedea. Cu toate acestea, doar motoarele de cautare vor detecta astfel de link-uri si, involuntar, proprietarul site-ului ar putea fi penalizat.

Atunci cand un hacker instaleaza link-uri daunatoare pe un site, de cele mai multe ori, el face prin acest lucru un efort de a face bani prin furt de trafic. Astfel, tot efortul depus de campaniile de promovare SEO este compromis. Asadar, acorda o atentie sporita, pentru a vedea daca site-ul tau se comporta intr-un mod ciudat. Prin urmare, trebuie sa verifici in mod regulat site-ul pentru a evita unele incalcari ale securitatii acestuia. Daca detii un site web, esti pana la urma persoana responsabila de integritatea lui si ai obligatia de a-l verifica periodic impotriva intrusilor. Evitarea unui astfel de prejudiciu se face prin mentinerea plugin-urilor actualizate. Pentru orice gauri de securitate cunoscute vor fi patch-uri, si, prin urmare, site-ul este protejat (cel putin pentru moment, pentru ca hackerii vor fi mereu in cautarea unei noi vulnerabilitati). In utilul Google Webmaster Tools, proprietarii de site-uri pot verifica dreptul de proprietate asupra site-urilor lor si pot stabili cine este autorizat sa efectueze modificari pe ele si cine nu. Aici, proprietarii de site-uri pot monitoriza, de asemenea, setarile site-urilor pentru a se asigura ca nu fost facute modificari nedorite.

Astfel de practici ale hackerilor duc adesea la pierderea traficului propriului site cat si la primirea de avertismente de malware, care vor descuraja cu siguranta increderea potentialilor vizitatori ai site-ului. Prin urmare, proprietarii de site-uri trebuie sa fie in alerta, pentru a evita eliminarea din indexul motoarelor de cautare, pierderea imginii cat si a gradului de incredere asupra site-ului lor.

Mai multe informatii despre SEO gasiti pe www.skyranking.ro.

dehackeradvisor

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

 

dehackeradvisor

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

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:

 

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.

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:

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.

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.