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.
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:
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.
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!"; ?>
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 .
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.
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.
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.
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 :
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.
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.
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.
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.
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.
Apache PUT information
PUT vs. POST
Setting up Secure HTTP Authentication with Apache
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.
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.
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.
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.
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 ?>
SQL Injection Cheat Sheet
Prevent SQL Injection in PHP with MySQL
SQL Injection by Example
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.