SQL injekcijas (1). Caurums drošībā.
Autors: alijs (alijs (at) navigator.lv)Kategorija: Drošība
Caurums drošībā
Vienkāršoti runājot, SQL injekcijas ir kādas trešās personas uzrakstīti SQL koda fragmenti, kas tiek izpildīti mērķa datu bāzē. Pieņemsim, ka mums ir PHP rakstīta web lapa, kas izmanto MySQL datu bāzi dažādu datu glabāšanai. Viens no bieži izmantotiem datu bāzes izmantošanas veidiem web lapās ir reģistrēto lietotāju datu glabāšana. Parasti šādās web lapās apmeklētājiem tiek dota iespēja piereģistrēties, kā arī autorizēties jau reģistrētajiem lietotājiem, ievadot lietotājvārdu un paroli.
Apskatīsim, kā tas varētu būt realizēts no tehniskā viedokļa. Web lapā tiek piedāvāta reģistrācijas/autorizācijas forma ar nepieciešamajiem laukiem. Kad lietotājs to ir aizpildījis, viņš apstiprina ievadītos datus ar pogas nospiešanu. Šajā brīdī ievadītie dati tiek nodoti serverim atbilstoši tam, kas norādīts HTML formas action laukā, un tiek izsaukts PHP koda gabals, kas prot šos datus apstrādāt.
Primitīvā autorizācijas gadījumā PHP koda uzdevums ir salīdzināt lietotāja ievadītos datus ar datu bāzē eksistējosiem un pieņemt lēmumu par atļaušanu vai aizliegšanu lietotājam autorizēties. PHP koda gabals, kas to realizē:
$login = $_POST['login'];
$password = $_POST['password'];
$result = mysql_query("select name from webusers where login='$login' and password='$password'");
$row = mysql_fetch_array($result);
$name = $row['name'];
if ($name) {
//lietotājs ir autorizēts ar vārdu $name
echo "Welcome, $name!";
//...
} else {
//lietotājs nav autorizēts
echo "Not authorized";
//...
}
Koda darbības principi ir vienkārši - saņemam lietotāja ievadīto loginu un paroli no POST datiem, un meklējam datu bāzē, vai tur eksistē lietotājs ar tādu loginu un paroli. Ja eksistē, tad iegūstam lietotāja vārdu un dodam pozitīvu atbildi. Savukārt, ja lietotājs datu bāzē nav atrasts, tad atbilde ir negatīva.
Principā piemērā dotais kods dara to, kas no viņa tiek sagaidīts, un web lapa ir spējīga atbilstoši funkcionēt - ļaut autorizēties datu bāzē reģistrētajiem lietotājiem, bet pārējos noraidīt. Tomēr spēja funkcionēt atbilstoši šajā gadījumā pastāv tikai līdz zināmam brīdim... tikai tik ilgi, kamēr lietotāji apzinīgi ievada tieši to, kas no viņiem tiek sagaidīts - lietotāja vārdu un paroli.
Problēmas sākas tad, ja kādam ir savtīgs nolūks un mērķi izmantot drošības caurumus savā labā. Pieredzējušiem programmētājiem būs skaidrs, ka šis kods ne tuvu nav labākais paraugs, pēc kura vadīties, rakstot autorizācijas veikšanas kodu. Nu kaut vai tādēļ, ka paroli glabāt datu bāzē nešifrētā veidā nav tas labākais stils. Un, protams, arī tāpēc, ka šim kodam piemīt ļoti liela potenciāla bīstamība, kas var izpausties gadījumā, ja pret to tiks izmantotas SQL injekcijas...
Turpinājumi:
SQL injekcijas (2). Iespējamais uzbrukums.
SQL injekcijas (3). Aizsardzība.
Lai pievienotu komentāru, autorizējies!


SĀKUMS
RAKSTI