Arhivă autor hackeradvisor™

dehackeradvisor™

Securitatea feed-urilor de date JSON

JSON este o modalitate de a trimite date între diferitele componente ale unei aplicații utilizând date care pot fi serializate, sau sa transformat într-o serie de perechi key-value. Unele aplicații folosesc această metodă pentru a trimite date din aplicație la browser.

Cum pot fi furate sau compromise datele JSON ?

Problema apare atunci când aceste informații sunt sensibile de la sine. Un atacator poate construi un alt site și a crea o pagină care include sursa de cod JSON care cere browser-ului sa il considere JavaScript, cum ar fi :

<script src="https://www.mysite.com/secret-data.json" type="text/javascript"></script>

Pagina de atac poate include acum un JavaScript suplimentar pentru a citi acest răspuns JSON, și trimite datele inapoi catre atacator. Un cod cum ar fi următorul, va transforma raspunsul JSON într-un vector, care citeste raspunsul pentru acțiuni in continuare.

 

<script type="text/javascript">
  var json_data;
  Array=function() { json_data=this;};	//turns JSON into an array!
</script>
<script src="https://www.mysite.com/secret-data.json" type="text/javascript"></script>
<script type="text/javascript">
  Var i=0;
  While(json_data[i++]){
  	Alert("Found secret data! "+json_data[i];
  }
</script>

Pasul final al acestui atac este de a convinge utilizatorul vizat pentru a vizita site-ul atacatorului în timp ce este conectat la mysite. În cazul în care utilizatorul este conectat la mysite, datele de autentificare vor fi trimise de către browser împreună cu cererea de date JSON, iar atacatorul va putea vizualiza informațiile secrete. Utilizatorii pot fi pacaliti in a face acest lucru printr-o varietate de moduri, de la simpla vizitare un post pe un forum unde atacatorul a postat, la vizualizarea comentariilor pe blog, sau chiar printr-un click direct pe un link-ul infectat.

 

Astfel, un rezumat al acestui tip de atac:

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

 

Cat de sigure sunt datele trecute prin JSON?

 

Marea majoritate a utilizărilor JSON nu vor fi afectate, deoarece majoritatea datelor trimise prin JSON nu sunt considerate a fi date critice. In plus, noile browsere, inclusiv Firefox 3 și mai sus, sau IE8 și mai sus au blocat metode comune de folosirea acestui atac, limitand impactul.

Cu toate acestea, este inca posibil ca un site atacator sa aiba posibilitatea de a fura date sensibile de la un utilizator în cazul în care datele sunt transmise prin JSON, deci ar trebui să ia în considerare prevenirea acest lucru in prima instanta, chiar dacă sunt trimise date non-critice.

 

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

Cea mai simpla solutie este convertirea tuturor solicitarilor de date catre JSON, sa foloseasca POST in loc de GET. Acest lucru va preveni ca unor alte site-uri sa extraga de date folosind un script src = „” tag-ul in site-ul lor.

Alternativ, puteți utiliza valori unice pentru a stabili daca cererea de datele in realitate vine de pe site-ul tau. De exemplu, în cererea GET, puteți solicita date unice, care vor fi diferite pentru fiecare sesiune, și pe care le puteti stoca în cookie-urile de autentificare ale utilizatorilor.

Spre exemplu, următorul form PHP folosește o cerere GET pentru a trimite o cerere de date, si in continuare, o valoare unică, numita nonce, este plasata în cerere și informația salvata in cookie.

Prima pagina (pagina formular in care utilizatorul actioneaza)

<?php
  //start the user session (set session cookie)
  session_start();
  //generate nonce - this nonce will be used for this session only, using random values and the time
  $nonce=hash("md5",rand().time().rand());
  echo "<br />Nonce: ". $nonce. "<br />";
  $_SESSION[ 'nonce']= $nonce;
?>

<!-- Now create the form, and include the same nonce we generated above-->
<form name= "do_some_action" action= "completeAction.php" method= "POST">
  <input type= "hidden" name= "nonce" value="<? php echo  $nonce?>"/>
  <input type= "submit" value= "do Action"/>
</form>

The page where the action is performed, after a user clicks a button.

<?php
  //start session
  session_start();
  //get the POST nonce
  $post_nonce=$_POST[ 'nonce'];
  //get the session nonce
  $session_nonce=$_SESSION[ 'nonce'];
  //make sure to validate the post input to prevent other types of attacks! Not shown here for brevity
  if( $post_nonce=== $session_nonce)
  	echo  "Request is safe!";
  else
  	echo  "Data might be stolen!";
?>

Additional Resources

 

Gasiti Feed-uri JSON nesecurizate pe site

HackerAdvisor.com  include in procesul de scanare, diferite setari de test, care te vor ajuta sa reduci expunerea site-ului la atacuri, inclusiv securizarea feedurilor JSON .

dehackeradvisor™

Cum sa ascunzi valorile X Header

 

Informatiile X header sunt incluse in mod implicit in diferite tehnologii aflate pe internet. Antetul trimite informatii catre browser, inclusiv informatii legate despre serviciile web care ruleaza. Multe tipuri de X-* headere nu sunt o amenintare pentru securitatea ta. Cel mai des intalnit X header, in legatura cu punerea in periocol a securitatii site-ului, este X-Powered-By header.

 

Ce sunt valorile X header ?

 

Informatiile X header sunt incluse in mod implicit in diferite tehnologii aflate pe internet. Antetul trimite informatii catre browser, inclusiv informatii legate despre serviciile web care ruleaza. Multe tipuri de X-* headere nu sunt o amenintare pentru securitatea ta. Cel mai des intalnit X header, in legatura cu punerea in periocol a securitatii site-ului, este X-Powered-By header.

Header-ul X-Powered-By dezvăluie informații bazate pe versiunea de PHP. Similar cu alte vulnerabilități de securitate cu risc scăzut, legate de versiunea de software, acesta dezvăluie date catre un atacator sau catre un proces automat, si poate fi folosit pentru a lansa atacuri cunoscute, bazate pe vulnerabilitati deja descoperite, care sa functioneze pentru versiunea dvs specifica. Eliminarea acestor informații, scade probabilitatea unor astfel de atacuri.

Un alt antet comun este antetul X-Pingback folosit în multe instalari de WordPress. Acesta este un exemplu de antet fără implicații de securitate, și poate fi ignorat fără probleme. Există in practica multe X-* headere, și fiecare rezultat, ar trebui să fie verificat pentru a vedea dacă se ofera informații despre versiunea platformei site-ului.

 

De ce ar trebui sa ascund aceste headere ?

 

Un atacator dedicat, poate afla aceste informații printr-o varietate de metode, dintre care, cele mai multe nu pot fi prevenite cu ușurință. Prin ele însesi, aceste informații oferă o valoare mică pentru un atacator.

 

Cea mai comună utilizare a acestui tip de informații, este cea in care se caută pe Google dupa configurații specifice cunoscute a fi vulnerabile, sau vulnerabilitati deja depistate, si se automatizeaza atacuri cunoscute ca ar functiona împotriva unor setări similare cu ceea ce se gaseste pe site-ul dvs. Eliminarea acestor informații scade probabilitatea unor astfel de atacuri.

 

 

Solutii – Cum sa dezactivezi X Headers

 

Deși nu este neapărat posibil sa previi complet descoperirea acestor informatii, este posibil să le faci mult mai dificil de descoperit pentru atacatori. Cel mai des intalnit X header pe care vrem sa il inlaturam este X-Powered-By din PHP. Iata cum se elimina aceasta :

 

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

 

Resurse Suplimentare

Scanati pentru tot felul de vulnerabilitati

HackerAdvisor.com include scanari numeroase si diferite, care te vor ajuta sa-ti securizezi site-ul, inclusiv te vor ajuta sa descoperi amenintari mici si obscure, care pot deveni majore. Adaugam constant si mai multe, in procesul de scanare.

 

dehackeradvisor™

Securitatea HTTP PUT

Mulți dezvoltatori web sunt familiarizați cu metodele GET și POST care permit unui utilizator să transmita date unui site web. Mai puțin cunoscuta este metoda PUT, care permite unui utilizator sa incarce fișiere și a le transforma în automat in adrese noi URL.

 

Securitate & HTTP PUT

Mulți dezvoltatori web sunt familiarizați cu metodele GET și POST care permit unui utilizator să transmita date unui site web. Mai puțin cunoscuta este metoda PUT, care permite unui utilizator sa incarce fișiere și a le transforma în automat in adrese noi URL.

PUT poate fi periculos dacă nu este corect securizat. În cel mai rău caz, ne imaginăm un site care permite sa foloseasca PUT si sa incarce fisiere. Un atacator ar putea construi un script PHP special, care ar putea adăuga un nou cont de utilizator pentru server, cu drept de acces root (admin). Atacatorul efectuează apoi un HTTP PUT cu acest script PHP, ca rezultat va fi formata o nouă adresă URL . În cazul în care atacatorul navighează la acest URL, fișierul PHP este executat de către serverul de web, și poate avea acces sa modifice orice fișiere de utilizator pe sistemul la care are acces, inclusiv pagini web existente.

Uneori PUT este o componenta folositoare a unui site. Solutia este sa fii sigur că doar utilizatorii autentificați au acces, si cei autentificați sunt atent limitati, astfel încât numai utilizatoriilor de încredere li se permite să efectueze PUT. În acest mod, utilizatorii PUT au acelasi nivel de incredere ca si cand ar avea un cont pe server, și au posibilitatea de a încărca sau modifica fișiere prin alte metode, cum ar fi FTP.

 

Cum afecteaza aceasta securitatea mea ?

 

Dacă solicitările de PUT sunt acceptate de conturile care nu sunt de incredere (în general non-administrator) , atunci aceasta vulnerabilitate va permite unui atacator să preia controlul complet al site-ului dvs. și eventual, al întregului server web.

 

Implementarea Securizarii HTTP PUT

 

Daca site-ul nu are nevoie de funcționalitatea PUT, atunci, este recomandat să treceți la un alt protocol securizat care folosește datele de conectare specifice de utilizator, cum ar fi SFTP. Dacă este nevoie de PUT pentru site, asigurați-vă că ati blocat toți utilizatorii. O autentificare dubla este cea mai bună metodă de a asigura acest tip de funcționalitate – în primul rând cu un nume de utilizator și de asemenea, cu autentificare HTTP.

In this manner, users will be named and limited in who can perform PUT requests.

Daca site-ul nu are nevoie de funcționalitatea PUT, atunci este recomandat să treceți la un alt protocol securizat care folosește datele de conectare specifice de utilizator, cum ar fi SFTP. Dacă este nevoie de PUT pentru site, asigurați-vă că ati blocat/securizat accesul pentru toți utilizatorii. O autentificare dubla este cea mai bună metodă de a asigura acest tip de funcționalitate – în primul rând cu o autentificare web cu nume de utilizator, și in plus, cu autentificare HTTP.

 

 

Resurse Suplimentare

 

 

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

 

Cauta Setarile necorespunzatoare pe serverul tau

HackerAdvisor.com include in procesul de scanare, diferite setari de test, care te vor ajuta sa reduci expunerea site-ului la atacuri, inclusiv depistarea setarilor necorespunzatoare pe serverul web.

 

dehackeradvisor™

Prevenirea atacurilor SQL Injection

Cele mai multe site-uri au o modalitate de a stoca date, cea mai frecventa este cea care foloseste o bază de date. Când se foloseșt baze de date SQL pentru a stoca date site-ului, un proprietar de site trebuie sa se fereasca de atacurile SQL Injection, care pot fi folosite pentru a fura sau a modifica datele utilizatorilor.

Prevenirea atacurilor SQL Injection

 

Unele site-uri care returnează rezultate diferite pe baza informațiilor transmise de utilizator (cum ar fi spre exemplu, logarea un utilizator în baza unui username / parola) nu pot filtra în mod corespunzător toate datele introduse de utilizator. Astfel, atunci când un utilizator introduce unele date, acesta poate modifica datele dintr-o încercare de a schimba interogarea SQL asupra bazei de date. Dacă reuseste, atunci atacatorul poate fi în măsură să se conecteze ca si administrator, sau poate fura alte date ale utilizatorilor.

Imaginați-vă că aveți datele de logare a utilizatorilor, stocate într-o tabela a bazei de date (utilizatori), și ca aceasta are următoarea structură:

 

CREATE TABLE users(
	User_id INT,
	username VARCHAR(30),
	password VARCHAR(30)
	);

 

Uitandu-ne la codul pe care site-ul il foloseste pentru a trata procesul de log-are, observam ca se construiește dinamic o interogare SQL în PHP, după ce un utilizator a tastat numele de utilizator și parola într-un formular (cu campurile – utilizator și parola):

<?php
$results = mysql_query( "SELECT use_id FROM users WHERE username='".$_POST['user']."' AND password='".$_POST['pass']);
?>

 

Principala problemă de mai sus este ca datele de la utilizator nu sunt securizate, variabila POST este folosita pentru a trage date direct din formularul de login, și plasându-l în interogare. În acest moment, un atacator ar putea încerca sa puna într-un șir special pentru nume de utilizator:

‘ or 1=1 or ‘

Acum, interogarea returnează întotdeauna primul utilizator (potential administratorul ) și atacatorul se poate conecta ca si administrator!

 

Si alte atacuri sunt posibile folosind o logica similara. În loc să se conecteze ca administrator, un atacator ar putea folosi alte siruri de caractere speciale, pentru a solicita date din baza de date la care nu ar trebui să aibă acces, ar putea aduna toate datele din baza de date la care un utilizator al bazei de date are acces.

 

Cum afecteaza asta securitatea mea?

Un atac reusit ar permite unui atacator sa obtina majoritatea sau chiar toate informatiile din baza de date, inclusiv toate datele sensibile, și se conecteze cu drepturi de administrator.

SQL Injection este una dintre vulnerabilitățile cu riscul cel mai ridicat pe care il poate avea un site.

 

Cum sa previi Injectiile SQL ?

 

Atacurile de tip SQL Injection pot fi prevenite într-un mod similar cu XPath Injection. Cel mai bun mod este de a securiza cu atenție datele introduse de utilizator. Orice date primite de la un utilizator ar trebui să fie considerate nesigure. Eliminarea tuturor ghilimelelor simple și duble ar trebui să elimine cele mai multe tipuri de acest tip de atac.

 

 

Aveti grija la eliminarea ghilimelelor, deoarece poate avea efecte secundare, cum ar fi situatia când numele de utilizator ar putea conține ghilimele valide. Imaginați-vă nume comune, cum ar fi O’Malley, care conține ghilimelelor legitime și pot fi introduse printr-un formular ca si nume de utilizator. În aceste cazuri, campul de intrare ar trebui să fie escaped, de multe ori prin adaugarea unui \ în fața ghilimelei. Verificați in bibliotecile specifice și software-ul de bazei de date pentru sintaxa corespunzătoare.

 

Majoritatea bibliotecilor de programare conțin funcții pentru a face escape la datele introduse de utilizator. Consultați documentația specifică pentru modul corect de a face escape automat la date, inainte de interogarea bazelor de date SQL. În PHP si MySQL, mysql_real_escape_string este funcția de a face escape la datele de interogare periculoase. Folosind aceasta sau funcții similare, care trateaza toate datele introduse de utilizator va ajuta la mentinerea unui cod securizat.

 

În al doilea rând, scrie toate interogările SQL folosind interogări parametrizate, astfel incat interogarea este pre-definita, și datele tastate sunt verificate si transmise ulterior. În PHP, de exemplu, ai putea re-defini interogarile mentionate anterior folosind această interogare parametrizata, cu scopul de a preveni atacurile SQL injection:

 

<?php
	$query= "SELECT user_id FROM users WHERE username=? and password=?";	//query definition
	$preparedStatement=$database_connection()->prepare($query);				//prepare the statement
	mysqli_stmt_bind_param($preparedStatement, 'ss', $field1, $field2);		//prepare to bind two Strings (the ss)
	$field1 = $_POST['user'];			//you may want to do more input checking here!
	$field2 = $_POST['pass'];			//you may want to do more input checking here!
	mysqli_stmt_execute($preparedStatement);	//execute the parametrized query
?>

Resurse Suplimentare

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

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

HackerAdvisor.com include in procesul de scanare, diferite setari de test, care te vor ajuta sa reduci expunerea site-ului la atacuri, inclusiv atacurile SQL Injection.