Trafic.ro si scriptul lor anti-frauda
Intr-un moment de pura plictiseala am facut o analiza a scriptului de monitorizare de la trafic.ro . Dupa ce am pierut putin timp sa vad cum functioneaza sistemul lor, si ce fel de protectie au, am reusit sa gasesc un exploit extrem de simplu care se poate implementa in 5 linii de cod.
Ce poate face exploitul ?
Sa presupunem ca exista site-ul A si site-ul X .Site-ul A are script de monitorizare trafic.ro, ias site-ul X nu. Sa presupunem ca mi-as dori ca toti vizitatorii care vin pe site-ul X sa apara ca si cum ar fi venit pe site-ul A. Cu acest exploit se poate face acest lucru extrem de simplu. Si desigur putem sa mergem un pas mai departe si vizitatorii de la X sa apara nu numai la site-ul A dar si la B,C,D.. etc…
Oare ar trebui sa fac public exploitul ? Hmmm…. momentan nu. Daca cineva este cu adevarat interesat si imi da un motiv bun , am sa il trimit.
PS.: Cat ziceau cei de la trafic ca au experienta? 10 ani ? Patetic!
Tags: analytics, securita, traficro
SELECT * FROM internet
Am lucrat de curand cu Yahoo! Query Language .
Pentru cei ce nu stiu ce este :
The Yahoo! Query Language is an expressive SQL-like language that lets you query, filter, and join data across Web services. With YQL, apps run faster with fewer lines of code and a smaller network footprint.
Este un serviciu genial si free, cu cateva limitari (1000/api request pe ora da nu esti inregistrat, 10.000 daca esti ) ma mir ca nu au facut si altii o astfel de chestie(Google,Bing) . Este magic din multe puncte de vedere si e super ca exista YQL console pe care poti sa testezi interogarile.
Ban pe IP
Foloseam pana de curand o metoda pentru a bana un IP chiar daca foloseste proxy transparent. Solutia pe care am folosit-o era urmatoarea functie :
function getip() {
if (isset($_SERVER["HTTP_X_FORWARDED_FOR"]))
foreach (explode(",",$_SERVER["HTTP_X_FORWARDED_FOR"]) as $ip) {
if (baseMod::validip(trim($ip))) {
return $ip;
}
}
$ipsl=array("HTTP_CLIENT_IP","HTTP_X_FORWARDED","HTTP_FORWARDED_FOR","HTTP_FORWARDED","HTTP_X_FORWARDED");
foreach ($ipsl as $tp)
{
if (isset($_SERVER[$tp]))
if (baseMod::validip($_SERVER[$tp]))
return $_SERVER[$tp];
}return $_SERVER["REMOTE_ADDR"];
}
IP-ul returnat in treceam in baza de date ca fiind banat… problema aici este ca are prioritate IP-ul trimis de proxy. Astfel se pot face modificari la HEADER-ul trimis de browser si introduce HTTP_X_FORWARDED_FOR cu ce IP se doreste…
Solutia evidenta este de a adauga in ban atat adresa returnata din $_SERVER["REMOTE_ADDR"] cat si pe cea din header.
Sper sa gaseasca cineva utila informatia asta si sa nu faca aceasi greseala ca mine
Tags: ban, securitate
Si daca totusi uitam!
Scriam in postul trecut cat de important este sa verifici tot input-ul de la utilizatori. Este de ajuns doar unu sa fie sarit si site-ul poate fi vulnerabil.
Dar daca totusi gresim si uitam sa validam un input ? Ce putem face in cazul in care site-ul este vulnerabil la SQL Injection?
Pentru astfel de cazuri folosesc urmatoarea solutie :
In toate site-urile care lucrez cu baze de date folosesc o clasa/functie pentru a executa interogarile sql. O functie ar arata asa:
function doQuery($strQuery)
{
return mysql_query($strQuery);
}
Si astfel voi folosi aceasta functie pentru toate interogarile.
Pasul urmator este de a modifica aceasta functie astfel incat atunci cand are loc o eroare SQL sa-mi bage eroarea intr-o tabela in baza de date cu urmatoarele informatii IP,data,SQL-ul,SQL-ul codat in base64 .
In continuare se va verifica daca ip-ul respectiv a declansat in total un maxim de (sa zicem) 5 erori. In acest caz il trecem intr-o tabela de ban-uri. Tabela de ban-uri va fi verificata evident la accesul oricarei portiuni din frontend.
Deci o astfel de functie arata asa :
function doQuery($strQuery)
{$rt= mysql_query($strQuery);
if (mysql_errno())
{
if (doQueryGetColumn(“SELECT COUNT(*) as total FROM modules_errors WHERE ip=’”.$_SERVER['REMOTE_ADDR'].”‘”,”total”)==4)
{
$dataset=array();
$dataset['state']=’denied’;
$dataset['data']=date(“Y-m-d H:i:s”);
$dataset['ip']=$_SERVER['REMOTE_ADDR'];
$dataset['description']=”Banned after unknown SQL errors(more than 4)”;
bansMod::add($dataset);mail (“email@email.ro”,”Attack detected on <nume site> ! FROM “. $_SERVER['REMOTE_ADDR'],$strQuery);
}
}
// inseram in baza de date eroarea
mysql_query(“INSERT INTO errors SET type=’sql’, extra=’”.make_safe($strQuery).”‘, query=’”.base64_encode($strQuery).”‘, data=’”.date(“Y-m-d H:i:s”).”‘, ip=’”.$_SERVER['REMOTE_ADDR'].”‘, error=’”.make_safe(mysql_error()).”‘”);// in cazul in care incercarea de a insera da eroare atunci inseram fara a mai adauga si SQL-ul in plain-text
if (mysql_errno())
mysql_query(“INSERT INTO modules_errors SET type=’sql’, query=’”.code($strQuery).”‘, data=’”.date(“Y-m-d H:i:s”).”‘, ip=’”.$_SERVER['REMOTE_ADDR'].”‘, error=’”.make_safe(mysql_error()).”‘”);
return false;
}
return $rt;
}
In acest mod daca va fi un atac asupra site-ului vom sti aproape imediat(depinde cat de des ne verificam adresa de mail). De obicei nici un atac nu reuseste numai dupa 5 erori in baza de date. Si odata ce cele 5 erori apar… respectivul are ban pe tot siteul iar noi avem informatiile necesare pentru a repara greseala!
Tags: securitate, SQL injection, tutorial
Securitate? ce e aia ?
Dupa o lunga perioada de timp am revenit cu un nou post.. si sper ca de acum in colo sa scriu mai des.
Astazi va voi vorbi cum sa incepeti sa va asigurati site-ul si ce sa face ti pentru o mai multa siguranta la codare.
Pentru inceput ar trebui sa fie stiut ca absolut tot ceea ce se primeste de la useri trebuie verificat.. si sa se presupuna ce e un posibil atac. Deci toate variabilele primite prin GET,POST,COOKIE, etc.. trebuie facute “safe” . Pentru asta puteti folosi o functie de genu:
function make_safe($value, $allow_html=false,$remove_html=false)
{
if ($remove_html)
$value=strip_tags($value);if (!$allow_html)
$value=htmlspecialchars($value);
// Stripslashes
if (get_magic_quotes_gpc())
$value = stripslashes($value);// Quote if not a number or a numeric string
if (!is_numeric($value))
$value = mysql_real_escape_string($value);return $value;
}
Astfel folosind o astfel de functie puteti sa va protejati impotriva atacurilor de timp SQL Injection sau XSS.
Tags: securitate, SQL injection, tutorial, XSS
Cat mai costa un vot ?
Astazi sa intamplat o chestie care nu as fi crezut-o daca nu vedeam cu ochii mei. In timpul odihnei de dupa masa (somn) aud soneria de la usa. Uimit cine ma deranjeaza la ora asta de odihna… ma ridic cu greu si ma indrept spre usa. Fiind mai rapid fratele ajunge inaintea mea si intr-o viteza uimitoare primeste de la un necunoscut o sacola si cuvintele : “Mergeti maine la vot, din parte lui Doru Tompea” sau ceva aproximativ…
Drept sa spun am ramas fara cuvinte si evident ca nici nu exista timp sa dai o replica deoarece persoana respectiva a si disparut. Dupa ce ne-am revenit am tras o privire in sacosa pe care domnul de la PSD a fost destul de darnic de a o oferi “cadou”. Si ce am gasit (sorry de calitatea imaginilor , nu am mai avut rabdare sa se incarce bateriile de la aparat) :
Se pare ca atat costa un vot : 1L ulei, 1kg zahar, 1kg orez si 1kg faina.
Problema cea mai mare este ca sunt fiinte care voteaza pe dl. Tompea doar pt. ca au primit aceasta mica “atentie”.
Dupa am tras o fuga la geam sa vad unde dispare persoana respectiva.. si nu mica mi a fost uimirea cand am vazut loganul de la PSD de unde baietii luau sacosele si se indreptau spre scarile blocurilor…
Nu uitati maine sa mergeti la vot!!!
SQL injection site fancourier
Astazi la indemnul unui coleg… am gasit din “greseala” posibilitatea de a face un SQL injection la search-ul pt. AWB la site-ul celor de la fancourier.
Mi se pare anormal ca site-ul unei firme de curierat destul de mare(22,4 milioane de EURO dupa 9 luni) sa aiba o securitate asa de proasta. Acest exploit fiind unul pe care si un copil de 12 ani cred ca ar putea sa-l aplice.
Nu stiu la ce date poti ajunge daca dezvolti si faci un atac cu SQL-uri complexe, si nici nu ma intereseaza.. sper doar ca nu au multe informatii confidentiale pe acolo : nume, adrese, nr. telefon… si altele…
Tags: exploit, fancourier, mysql, SQL injection
flash upload – problema cu session id-urile
Zilele trecute am avut nevoia intr-un protiect de a folosi un flash pentru upload-ul de fisiere.
Nu prea imi place flash-ul dar alta solutie mai buna nu am gasit asa ca am optat pt. varianta asta. Aveam persoana potrivita care sa rezalizeze asta (nu stiu o boaba de flash) si am trecut la munca. Trebuie sa precizez ca upload-ul se face sub o sectiune unde trebuia sa fii autentificat ca sa ai acces. Dupa ce testele initiale au avut succes am introdus flashu-ul in sectiunea sa incepand al doilea rand de teste. Evident testul a fost un esec. Dupa mult “debbuging” am ajuns la concluzia ca flash-ul la upload nu trimite acelasi SESSIONID ca al browser-ului, creand el unul nou. De aici si problema cand incerca sa faca upload-ul in sectiunea in care trebuia sa fii autentificat.
Solutia la care am ajuns a fost modifcarea flas-ului si introducerea unui parametru in link-ul de upload pt. SESSION ID iar php-ul care se ocupa de upload intai inregistra SESSIONID-ul si apoi facea verificarea de logare. Probabil ca mai sunt si alte solutii dar asta a fost cea mai buna alegere pt. proiectul asta.
Tags: flash, phpsessid, sessionid, upload
Hug a developer
Un filmulet super tare… developerii… saracii… prin ce trec…
Sper ca toti ce i care nu sunt/fost developeri sa inteleaga prin ce trecem
stiri.. 01 phone… cand nu se verifica sursele.. fals
Am citit zilele trecute o stire pe go4it.ro in care se vorbea de posibila aparitie a unui telefon a carui producator este necunoscut . Site-ul(The01Phone.com) unde telefonul este prezentat(cateva imagini) are un timer care la fiecare refresh porneste de la aceasi valoare… Dupa putin citit pe net se observa ca este o stire falsa. Pacat ca cei de la go4it.ro nu verifica stirile care sunt puse pe site… Dar na ce conteaza o stire falsa… doar sunt altele adevarate…

