Padomi mājas lapas drošībā

Sen pagājis laiks, kad lielākajai daļai cilvēku internets bija liels un nezināms labirints. Ir apgūts daudz no tā, ko tas spēj piedāvāt, un tagad kārta pienākusi atzīmēties interneta plašumos ne tikai komentāru laukos, bet arī publicējot pašam savu mājas lapu. Kā to izdarīt, tiek mācīts gan skolās, gan universitātēs, bet ne vienmēr ar to vien pietiek. Vajadzīga arī pieredze, kā nodrošināt, lai lapa tiešām strādātu ilgi un kvalitatīvi. Piemēri pārsvarā attieksies uz mājas lapu servera pusē izpildāmo kodu (vai nu PHP, vai ASP.NET, vai arī JSP utt.), bet ar daļu no problēmām var sastapties arī statiskās HTML lapās.

Izpētiet savas lapas web serveri

Pirmais, par ko jādomā jau pirms mājas lapas izstrādes, ir serveris, kurā tā tiks izvietota. Jāņem vērā, ka servera administratoram ir pilnīga piekļuve visiem datiem, kas atrodas serverī, – gan izejas kodam, gan datu bāzei. Ir vērts pārdomāt, vai savus datus (un arī sistēmas lietotāju datus) esat gatavs uzticēt šim administratoram. Noderīgi arī pārliecināties, vai administrators, lai novērstu to, ka iespējams uzlauzt serveri, vienmēr atjaunina servera programmatūru.

Ar servera konfigurāciju ir saistīta vēl kāda ļoti liela problēma – ja serverī ievietotas vairākas mājas lapas, tad jāpārliecinās, vai nav iespējams, strādājot ar kādas citas mājas lapas kodu, piekļūt jūsu rakstītajam kodam. Šī kļūda ir visai izplatīta, jo parasti web serverī tiek noteiktas piekļuves tiesības vienam sistēmas lietotājam apstrādāt visas lapas. Ja nav veikti speciāli drošības pasākumi, dažādu mājas lapu kodi nav savstarpēji izolēti.

Parūpējieties par izejas koda drošību

Viens no galvenajiem drošības pasākumiem jebkurai lapai ir sargāt tās izejas kodu. Ja vien neesat pilnībā pārliecināts par to, ka kods ir pilnīgi bez kļūdām, tad tā izplatīšana var sagādāt nepatīkamus pārsteigumus. Iespējams, ka kāds interesents to izpētīs un, pamanījis kļūdu, to izmantos, lai veiktu mājas lapā nevēlamas darbības. Daudzas no rakstā minētajām kļūdām ļoti grūti ir izmantot praksē, ja ļaundarim nav pieejams kods, jo tas nozīmē, ka, uzlaužot lapu, jātērē daudz vairāk laika. Ja tiek lietots kāds Open Source risinājums, tad obligāti jāuzmana, kad tiek publicētas jaunākas versijas, jo, izmantojot šo risinājumu, internetā var atrast ne tikai problēmas aprakstus, bet arī gatavus paraugus, kā to izmantot, lai lapu uzlauztu. Ļoti spilgts piemērs ir portālu sistēma PHPNuke, kas kādu laiciņu atpakaļ bija ļoti populāra. Savu izmēru dēļ tā diemžēl bija pilna ar kļūdām, kuras ik pa laikam izmantoja, lai uzlauztu ne tikai atsevišāmājas lapas, bet arī pat veselus serverus, kuros šīs mājas lapas atradās.

Servera drošība ir ļoti svarīga, taču pat vislabākais serveris nespēs pasargāt no problēmām, kuras rodas slikti uzrakstīta mājas lapas koda dēļ. Turpmākie piemēri attiecas uz PHP valodu, bet arī citās programmēšanas valodās tie var būt aktuāli.

Neļaujiet nolasīt svarīgus failus

Ļoti bieži sastopams risinājums lapas navigācijai ir URL parametrā norādīts tā faila nosaukums, kuru lietotājs grib redzēt. Piemēram, http://serveris/index.php?lapa=about.php. Pats par sevi šāds risinājums vēl nerada problēmas, ja vien servera kods ir pareizi uzrakstīts. Piemēram, ja kodā rakstīts <?require $_GET['lapa']?>, tad potenciālajam ļaundarim vārti ir vaļā. Ja kā parametrs tiek norādīts ?lapa=/etc/passwd, tad var iegūt visu sistēmas lietotāju sarakstu (iespējams, pat ar visu paroļu kodētajām formām). Šāda koda rindiņa ļauj iegūt gandrīz jebkuru failu, kas atrodas serverī.

Ir vairākas iespējas, kā to nepieļaut, piemēram, veidojot masīvu ar to failu nosaukumiem, kurus drīkst pieprasīt, vai arī lietot PHP funkciju basename(), kas izdzēš speciālos simbolus (. vai /) no parametra. Līdzīga problēma rodas tad, kad dažādi datu faili ir nolasāmi no servera, ierakstot to nosaukumu adreses laukā. Piemēram, ja paroles glabājas failā http://serveris/passwords.txt vai arī http://serveris/config.inc (ja paplašinājumu *.inc serveris nemāk apstrādāt kā PHP kodu).

Piešķiriet sākumvērtību mainīgajiem

Mazāk sastopama problēma slēpjas PHP funkcionalitātē register_globals, kas automātiski izveido mainīgos ar datiem, kādus lietotājs ieraksta lapas pieprasījumā. Pēdējās PHP versijās šī funkcionalitāte ir izslēgta pēc noklusējuma, tāpēc tā vairs nav sastopama tik bieži, bet šo problēmu ļoti labi ilustrē šāds piemērs:

http://serveris/index.php?show_all=1

<?php
if ($_SESSION['admin']) $show_all=true;
....
if ($show_all)
/*šeit nonākam, pat ja nav admins, jo
parametrā ir padots mainīgais ar tādu pašu
nosaukumu*/
?>

Šajā gadījumā administratoram ir paredzēts rādīt papildu datus. Bet, tā kā mainīgais $show_all tiek izmantots tikai tad, ja lietotājs ir reģistrēts kā administrators, parasts lietotājs, pieprasot lapu ar iepriekšminēto adresi, arī var piekļūt šiem pašiem datiem. Kā redzams, šī problēma ir aktuāla tikai tad, ja arī kods nav korekts (mainīgo vērtības netiek inicializētas) un ļaundarim pie tam ir zināms mainīgā nosaukums. Tāpēc svarīgi ir glabāt savas lapas kodu pie sevis un neizdāļāt jebkuram. Pat ja šī problēma kodu neskar, iespējams, ka pieļautas kādas citas kļūdas, kas var novest pie līdzīga rezultāta.

Nodrošiniet lietotāja datu pārbaudi

Pati lielākā problēma dinamisku web lapu veidošanā ir tā, ka netiek pārbaudīti lietotāja ievaddati. Ja dati, ko lietotājs nosūta lapai, netiek pārbaudīti, ļaundarim paveras ļoti plašas iespējas dažādos veidos uzbrukt lapai. Turklāt nekad nedrīkst paļauties uz to, ka dati, kas, piemēram, atrodas slēptajos (hidden) laukos, nonāks serverī tieši tādi, kādi tie ir bijuši. Piemēram, nekad nedrīkst ievadīt lietotāja identifikatoru šādā veidā, jo tas ļauj lietotājam izmainīt šo vienu vērtību un sistēma uzskatīs, ka ar to strādā jau pavisam cits lietotājs. Nākamā iespēja izmantot šo problēmu ir tā sauktās SQL injekcijas, kad lietotājs var piemuļosistēmu, lai tā izpilda lietotāja izvēlētu SQL pieprasījumu. Piemēram:

http://serveris/index.php?id=1 –korektais pieprasījums
http://serveris/index.php?id=1 or TRUE – modificēts pieprasījums

<?php
mysql_query("update Tabula set apskatits=''Y' where id_col=".$_GET['id']);
?>

Kā redzams minētajā piemērā, ar modificēto pieprasījumu lietotājs piespiež sistēmu norādīt pilnīgi visiem datu bāzes ierakstiem vērtību apskatits=’Y’. Pat tad, ja SQL pieprasījumā visi mainīgie tiek ievietoti pēdiņās (id_col='1'), ir jāpārbauda, vai lietotāja ievaddatos nav pēdiņu, un jāpievieno tām prefikss “”. PHP to automātiski nodrošina ar konfigurējamu iespēju magic_quotes, kas pēdējās PHP versijās ir ieslēgta pēc noklusējuma.

Trešā problēma lietotāja ievaddatos slēpjas iespējā saglabāt HTML kodu. Piemēram, lietotājs var saglabāt datus, kas satur <iframe src=http://mana/lapa/ style="position:absolute; left:0; top:0;width:100%; height:100%; z-index:1000"></iframe>. Ja servera kods neapstrādā šos datus korekti, turpmāk katru reizi, kad šie dati tiek parādīti lapā, lietotājs redz tikai un vienīgi to lapu, kuras adrese ir http://mana/lapa/. Ja šī lapa izskatās līdzīga oriģinālajai lapai, tad ir iespējams piemānīt citus lietotājus un iegūt viņu lietotājvārdus un paroles vai citu svarīgu informāciju. Šo problēmu sauc par cross-site scripting (CSS), un vienkāršākais veids, kā no tās izsargāties, ir neļaut lietotājam saglabāt HTML kodu, piemēram, izmantojot PHP funkciju strip_tags() vai arī aizstājot simbolu “<” ar “<”, kas nodrošinās to, ka lietotāja ievadītais kods tiks rādīts kā parasts teksts. Otrs cross-site scripting izmantošanas veids ir saglabāt nevis iepriekšminēto elementu iframe, bet gan elementu script ar klienta kodu, kas veidots tā, lai tas var nozagt kādu citu lietotāju unikāli identificējošo cookie ar lietotāja sesijas identifikatoru (session_id).

Ja šo session_id sliktais kods nosūta savam autoram, tad autors to var izmantot, lai piemānītu sistēmu un uzdotos par šo otro lietotāju. Iespējamie risinājumi ir, gan izmantot iepriekš minētos, gan arī piesaistīt session_id lietotāja IP adresēm.
Protams, ir jāpārliecinās arī, vai lietotājs nemēģina sistēmai nodot pārāk lielus pieprasījumus, kas var novest vai nu pie tā, ka izbeidzas sistēmas operatīvā atmiņa, vai cietā diska brīvā vieta, vai arī datu bāze tiek pārpildīta ar daudziem ierakstiem, kas krasi samazina sistēmas darbības laiku.

Lai nodrošinātu svarīgu lapu drošību, konsultējieties ar speciālistu

Pat tad, ja viss iepriekš teiktais tiek ievērots, sistēmu vajag aizsargāt arī pret citām drošības kļūdām. Visas iespējamās kļūdas nemaz nav iespējams uzskaitīt. Vislabākais variants ir mājas lapas audits, ko veic pieredzējuši eksperti. Tas palīdz atrast iespējamajās problēmas un saņemt rekomendācijas, kā no tām izvairīties.

Taču arī audits un citi drošības pasākumi neko nedos, ja lapas administratīvais interfeiss (ja tāds eksistē) netiks aizsargāts ar drošu paroli vai vēl labāk – administratīvajam interfeisam piekļuve tiks atļauta tikai no sev piederošiem datoriem (mājas, darba utt.). Arī citiem sistēmas lietotājiem nebūtu vēlams atļaut izmantot elementāras vai pārāk īsas paroles, kā arī tās obligāti ir jāglabā šifrētā veidā.

Nobeigumā jāteic, ka absolūti drošas sistēmas nav un visdrošāk web lapa būtu aizsargāta tad, ja to vispār neizvietotu internetā. Turklāt nekad nevajadzētu uzskatīt, ka teiciens “Īsti vīri rezerves kopijas netaisa” jāievēro arī dzīvē.


(Informācija pārpublicēta no knagis.miga.lv ar autora atļauju.)