Drošības pamati web-lapās


Piedāvāju nelielu aprakstu par populārākajām web-lapu ievainojamībām un padomus kā izvairīties no tām.

SQL injekcijas
Ja dati pirms to saglabāšanas datu bāzē netiek pareizi apstrādāti, tad ļaundaris var injicēt papildus nosacījumus SQL pieprasījumos, kā rezultātā ir iespējams nolasīt/labot/dzēst jebkurus datus datu bāzē. Vairāk par SQL uzbrukumiem - SQL Injection Cheat Sheet.

Lai izvairītos no SQL injekcijām, visi dati pirms to ievietošanas SQL pieprasījumā ir jāapstrādā ar funkciju mysql_real_escape_string.

XSS - Cross Site Scripting
Viena no biežākajām ievainojamībām web-lapās ir tieši XSS - JavaScript koda injekcija, kas ļauj vizuāli izmainīt web-lapu, pārvirzīt tās apmeklētājus vai iegūt informāciju par tiem, nolasīt cookie datus un izmantot visas pārējās JavaScript iespējas. Piemēram, slikti aizsargātā lapā, apmeklētājs var pievienojot komentāru norādīt savu vārdu kā <script>window.location=”http://someplace.com”;
<script>, kā rezultātā pie komentāru apskates visi apmeklētāji tiks pārsūtīti uz citu lapu. Par dažādiem XSS piemēriem var palasīties iekš http://ha.ckers.org/xss.html. Tāpēc visi dati pirms izvadīšanas web-lapā ir jāapstrādā vismaz ar funkciju htmlentities().

Aizsardzība pret nozagto sesiju lietošanu

Parasti pēc sesijas izveidošanas lietotāja pārlūkprogrammā tiek saglabāts cookie ar sesijas ID, kas pēc noklusējuma ir vienīgais veids lai noteiktu, ka tieši šim lietotājam atbilst konkrētā sesija ar visu tajā esošo informāciju. Ja ļaundarim izdodās uzzināt šo sesijas ID (kas var būt izdarāms gan ar SQL injekciju, gan, visbiežāk, ar XSS, gan jebkādā veidā nolasot cookie failus no lietotāja datora), tad viņš norāda tādu pašu ID savā pārlūkprogrammā un iegūst no dotās web-lapas to pašu, ko cietušais lietotājs, piemēram, pieeju pie administrēšanas paneļa vai profilu forumā.

Pilnībā izslēgt jebkādu iespēju nozagt sesijas ID un/vai jebkurus citus cookie datus ir gandrīz neiespējami un tāpēc ir jāparūpējas par aizliegumu izmantot vienu sesiju vairākos datoros. Populārākais un, iespējams, labākais risinājums ir pie sesijas izveidošanas (piemēram, pēc ielogošanās formas) saglabāt lietotāja IP adresi un pie katras nākamās lapas ielādes to salīdzināt ar faktisko IP adresi, un gadījumā, ja abas IP nesakrīt, izdzēst sesiju.

Paroļu šifrēšana

Pašsaprotami, ka paroles nedrīkst tikt glabātas tīrā teksta veidā un tām ir jābūt šifrētam vismaz ar MD5 algoritmu, bet arī tas nav drošs risinājums, jo izmantojot brute-force metodi, pat septiņu simbolu paroles atminēšanai nav nepieciešams vairāk par dažām stundām uz viduvējas veiktspējas datora.

Tādēļ parolēm ir obligāti jāpievieno tā saucamais salt, kas ir papildus simboli pie paroles un padara to garāku lai padarītu paroles atminēšanu neiespējamu gadījumos, kad ļaundarim ir zināms tikai paroles hash. Piemērs:

$password = 'qwerty'; // Lietotāja ievadītā parole
$salt = md5($username.'#!'); // SALT no lietotāja vārda un divi papildus simboli
$password = MD5($password.$salt); // Galējais paroles hash

Rezultātā ļaundarim ir jāatmin hash`a vērtību nevis vienkāršai 6 simbolu parolei, bet nu jau 26 simbolu parolei, kas ir praktiski neiespējami bez pilnas pieejas pie visas datu bāzes un web-lapas izejas koda.

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.


Other Posts
Unobtrusive Javascript
Caurspīdīgie PNG

Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

“…jo izmantojot brute-force metodi.. ” tam tāpat vajag tiešu pieeju db

Atļaušos iebilst par paroļu šifrēšanu un SQL injekcijām!

Vispirms par parolēm.
Cienījamais autors neatšķir šifrēšanu (crypting) no hešošanas (hashing).

Pielietojot atslēgu, šifrētus datus var atjaunot sākotnējā stāvoklī, bet hešotus datus atjaunot sākumstāvoklī ir praktiski neiespējami - var tikai atrast kādu heša sadursmi (collision), bet nav nekādas garantijas, ka ir atrasti sākotnējie dati.

Tātad vēlreiz atgādinu - MD5 algoritms NAV šifrēšanas algoritms! MD5 ir hešošanas algoritms!

Un arī par paroļu sāli autoram nav īstas skaidrības.

Paroļu sāls jēga NAV paroles pagarināšanā.

Paroļu sāls jēga ir aizsargāt pret tabulācijas (rainbow table) uzbrukumiem, jo uzbrucējam faktiski ir jāzina 2 parametri - paroles hešs un sāls, tikai tad uzbrucējs var piemeklēt paroli, kas summāri ar sāli dod vajadzīgo paroles hešu.

Un nu par SQL injekcijām.

mysql_real_escape_string ir tikai viena maza daļa un tikai MySQL gadījumā.

Lai vispārīgā gadījumā izvairītos no SQL injekcijām ir jāpārbauda pilnīgi VISI lietotāja iesūtītie dati un jānosaka vai tie ir derīgi (data validation & sanitization).

Ceru, ka mani skaidrojumi ir pietiekami skaidri un saprotami.

Bytec, paldies par labojumiem un papildinājumiem.

KAC, tam pietiek arī ar SQL injekciju, ja izdodās pielietot UNION.

Atļaušos atzīmēt, ka izveidoju rakstiņu par vienu no aprakstītajām tēmām:
http://datubazes.wordpress.com/2008/10/29/sql-un-plsql-injekcijas/

[...] Drošības pamati web lapās; [...]

Hi, cool post. I have been pondering this topic,so thanks for writing. I will certainly be coming back to your blog. Keep up great writing

Hi, gr8 post thanks for posting. Information is useful!

The best information i have found exactly here. Keep going Thank you

Labi raksti par drošību internetā atrodami arī šeit: web drošība

It’s a masterpiece. I have never thought people can have such ideas and thoughts. You are great.

It’s a pity that people don’t realize the importance of this information. Thanks for posing it.

How soon will you update your blog? I’m interested in reading some more information on this issue.

How soon will you update your blog? I’m intsrested in reading some more information on this issue.;