Archive for the ‘Development’ Category
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
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
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.