Izkazalo se je, da je ogromno gesel prekratkih in preveč preprostih (recimo qa in podobno). Izjema ni niti direktor WordPressa, ki je imel za geslo štirimestno število. Žalostno je, da vdor ni posledica napada neke obskurne ranljivosti, ampak gre za osnovno tehniko, ki ima tudi relativno enostavno zaščito.
Poleg tega je bili napadeno tudi podjetje Oracle, mati MySQL-a, od koder so uspeli odtujiti tabele in elektronske naslove, gesel pa naj ne bi bili. Tudi tod je bil vdor izveden na enak način.
Sophos poroča še, da to ni edina huda ranljivost, ki jo ima stran MySQL.com. Že od januarja je znano, da je MySQL.com ranljiv tudi za napad XSS in da ranljivost še ni odpravljena. Možno je, da je bila to v tem napadu tudi sekundarna pot.
In potem si folk še vedno upa trdit, da naravnanost PHP jezika k napadom ni slaba stvar. PHP napadi se izvajajo na dnevnem nivoju, medtem ko kak Python res redko požene takšno slavo.
Linux in Linus sta že dojela, da je pomembna privzeta nastavitev. Kaj si uporabniki zavestno prenstavijo je irelevantno.
Mysqli že tako podpira prepared statements po defaultu, kakor jih tudi PDO. Vendar to še vseeno nobenemu ne prepreči uporabe $db->prepare("SELECT * FROM tabela WHERE id = ".$_GET['id']);
Vendar tudi če ne uporabljaš prepared statements, do danes še ni bila odkrita pomanjkljivost mysql_real_escape_string.
Če pa že primerjamo PHP in Python ... večina ljudi pri Pythonu uporablja uveljavljen framework, kjer je v 99,99% za dostop do baze poskrbljeno in uporabniku ni potrebno posebej skrbeti za to. Pri PHPju je velika večina strani narejenih brez nekega frameworka in očitno tudi nimajo dobro narejenega razreda (ali pa ga sploh nimajo) za dostop do baze.
Vendar tudi če ne uporabljaš prepared statements, do danes še ni bila odkrita pomanjkljivost mysql_real_escape_string.
Pred davnimi leti, v določenih okoliščinah, pod posebnimi pogoji (Vir):
However, a bug was detected in how the MySQL server parses the output of mysql_real_escape_string(). As a result, even when the character set-aware function mysql_real_escape_string() was used, SQL injection was possible. This bug has been fixed.
In potem si folk še vedno upa trdit, da naravnanost PHP jezika k napadom ni slaba stvar. PHP napadi se izvajajo na dnevnem nivoju, medtem ko kak Python res redko požene takšno slavo.
Linux in Linus sta že dojela, da je pomembna privzeta nastavitev. Kaj si uporabniki zavestno prenstavijo je irelevantno.
Seveda če pa je v PHPju itak večino web aplikacij, -- pa vsak mulc je že PHP developer. )
Vendar tudi če ne uporabljaš prepared statements, do danes še ni bila odkrita pomanjkljivost mysql_real_escape_string.
Pred davnimi leti, v določenih okoliščinah, pod posebnimi pogoji (Vir):
However, a bug was detected in how the MySQL server parses the output of mysql_real_escape_string(). As a result, even when the character set-aware function mysql_real_escape_string() was used, SQL injection was possible. This bug has been fixed.
Ampak izjeme zgolj potrjujejo pravila ;-)
In si še niso zmislili mysql_really_real_escape_string() funkcije? :)
1ACDoHVj3wn7N4EMpGVU4YGLR9HTfkNhTd... in case I've written something useful :)
