Jump to content

PHP drošība


oxxxis
 Share

Recommended Posts

Labdien, tā, kā esmu iesācējs šajā jomā un mācos pats no literatūras, vēlējos noskaidrot dažus jautājumus par drošību no pieredzējušākiem cilvēkiem.

 

Zinu ka viena no potenciālajām riska zonām ir teksta ievade (input), caur kuru var veikt MySQL injekcijas

 

no šīm injekcijām var izvairīties lietojot mysql_real_escape_strings() funkciju. Lasot w3schools tika minēts, ka tas attiecas uz šiem: \x00; \n; \r; \; '; "; \x1a;

 

Jautājums būtu sekojošs, kam tiek izmantoti \x00 un \x1a. Pieņemu ka tie ir kādi speciāli simboli, bet vai nezinot manas datubāzes tabulu nosaukumus ir iespējams veikt šādu injekciju? Vai iespējama injekcija caur adress bar, ja jā, kā no tās izvairīties?

 

Otrs jautājums bija par addslashes(). Zinu ka tš tiek leitotas, lai pie speciāliem simboliem peivienotu \ zīmi un rezultātā

 

<script language="javascript" type="text/javascript">
alert('Nekas');
</script>

 

kļūst par

 

<script language=\"javascript\" type=\"text/javascript\">
alert(\'Nekas\');
</script>

 

Man radās jautājums, kā var izsargāties no tā, ka piemēram \" netiek aizstāts ar attiecīgu speciālo simbolu (ar &) un tālāk tiek izsaukts piemēram kāds slikts javascripts no citas lapas, kas manai var nodarīt pāri. Itkā bija funkcija html_special_chars() (vai tamlīdzīga, kas arī < u.c simbolus pārveido šādi, bet tas neatrisina problēmu). Varbūt var veidot masīvu, kas visus šos simbolus ar & pārveido vēl sazin kā, bet tad radās jautājums, kā rīkoties, ja ir textarea un nepieciešams tekstu pārnest jaunā rindā vai ieboldēt, attiecīgi tie ar tiks izmainīti, bet ja lietos stripslashes() funkciju, vei nenotiks tā, ka tas, kas sākumā bija pārveidots, lai neizpildītos, var izpildīties?

 

Lasīju, ka ir iespēja visus inputus pārbaudīt ar pašizveidotu funkciju, kas meklē SELECT, *, INSERT, DELETE utt, bet tas jau arī normālu tekstu pārveidos..

 

Ceru uz sakarīgām atbildēm, bez norādēm uz googli, jo gribu vienkārši tik skaidrībā, bet informācija ir ļoti daudz. Tā kā labojiet mani, ja kļūdos savās pārdomās un iesakiet vēl kādas aizsardzības iespējas.

Link to comment
Share on other sites

Un tad kad vajag atstāt enter'us, piemēram, lietotāja postētiem komentāriem- nl2br(htmlspecialchars($teksts));

Ieboldēšanai labāk izmantot kaut ko bbcode veidīgu, vai arī ļoti rūpīgi uzrakstītu strip_tags variantu (standartā strip_tags f-ja atstāj neskartus tagu atribūtus: <b onmouseover="alert('slikts kods')">Brauc ar peli virsū šitam</b> paliek neskarts (ja atļauj <b> tagu).

BBCode implementāciju ir pilns nets- http://www.google.com/search?client=opera&...-8&oe=utf-8

Link to comment
Share on other sites

Injekcijas var veikt caur jebkuriem datiem, kas nāk no klienta. Ne tikai <input>, bet arī, piemēram, caur cookies. Nav liela māksla uzģenerēt pašam savu pieprasījumu, kur salikt iekšā visu, ko vien sirds kāro.

 

Tu jau pats esi korekti identificējis abas visbiežāk sastopamās injekcijui klases - SQL injekcijas un HTML injekcijas. Tāpat arī esi jau identificējis, kā no tām izvairīties. Pret SQL injekcijām palīdz mysql_real_escape_string() funkcija, vai (vēl labāk) - parametrizētie kveriji. Par tiem linku deva Kristaps Kūlis.

 

HTML injekcijas atrisina htmlspecialchars() funkcija. Izlaižot stringu caur to, nav iespējama nekāda HTML vai JS koda saglabāšanās.

 

addslashes() un stripslashes() funkcijas nevajadzētu izmantot, lai izvairītos no injekcijām, jo tās ir iespējams apčakarēt. Tas gan ir garš stāsts par tehniskām niansēm, tāpēc to šeit neatstāstīšu. Vienkārši izmanto abas augšupminētās funkcijas, un būs OK.

Link to comment
Share on other sites

BBCode ir PITA, :

1)nav normāla WYSIWG editora

2)Db ir jāpieglabā divas versijas - renderētā uz HTML un editējamā vai arī jārenderē uz katra requesta servera galā.

3)Bez tam, rakstīt kodu ar roku, protams, ir 1337, bet neviens negīks to neizvēlēsies WYSIWG vietā un average cilvēkam BBCode ir tikpat nesaprotams kā HTML. No BBCode PHP implementācijām rullē PECL paplašinājums (ātrāks nekā standarta regex`i. Problemātiska labošana, ja necērt C :) un vajag root acc uz servera, lai jamo uzstellētu). Protams, strip_tags ēeed zemi (Tāpat kā lielākā daļa PHP cores:)), bet HTML filtrēšanai rullē http://htmlpurifier.org/ (Kas gan ir diezgan lēns, bet toties dzenājams vienreiz -> pie requesta pieseivošanas, pēc tam mums jau ir droši dati) .

 

Ja gribi abstrahēties no visiem attīrītājiem, centralizēti un konsistenti to dara http://www.php.net/filter .

Link to comment
Share on other sites

Autors vispār ir norādījis, ka vēlas saņemt no lietotāja tekstu ar formatējumu, ne tikai pliku tekstu?

 

OK, man tagad ir mazliet vairāk laika, tāpēc varu nedaudz vairāk pastāstīt par PHP drošību, lai neiznāk iebraukt ziepēs.

 

Pirmkārt, autoram iesaku atvilkt tādu rīku kā Fiddler. Tas paredzēts Internet Explorer. Eksistē arī analogi priekš FireFox un Opera, bet šis man personīgi patīk. :)

 

Šis rīks pārķer visas komunikācijas starp Internet Explorer un serveri. Tu vari paskatīties, kas un kā tad īsti tika sūtīts. Tas palīdzēs saprast, kā lietas notiek, kā arī reizēm noķert kādu kļūdiņu.

 

Šis rīks arī ļauj vienkāršā veidā pašam veidot savus pieprasījumus, kuros vari norādīt dajebkādas GET/POST/COOKIES vērtības. No tā būs mācīties, ka ļaundariem arī šādi rīki ir pieejami, un viņi var veidot dajebādus pieprasījumus uz serveri. Secinājums - Tu nevari paļauties pilnīgi ne uz ko, kas nāk no lietotāja. Iekš PHP tie būtu $_GET, $_POST un $_COOKIE masīvi. Pat, ja Tu esi uztaisījis kādus nebūt slēptus formas laukus (<input type="hidden">) vai uzstādījis kādus cepumiņus (ar setcookie() funkciju), ļaundarim ir elementāri tos pamainīt pēc sirds patikas. Tāpēc pilnīgi obligāti visas vērtības, kuras Tu nolasi no šiem masīviem, ir jāpārbauda, vai tajās nav kaut kas slikts.

 

Lielākajā tiesā gadījumu pārbaudes nemaz nav tik sarežģītas. Piemēram, ja vērtība nāk no kāda <select> elementa, tad Tev pietiek pārbaudīt, ka tā patiesi ir viena no tām vērtībām, kuras Tu tajā <select> sākumā ieliki. Ja Tev kādā vietā obligāti vajag skaitli, tad vari to pārbaudīt ar ctype_digit() vai is_numeric() funkcijām (viņām ir biki atšķirības, palasi manuāli).

 

Reizēm būs arī vietas, kur no lietotāja vajadzēs saņemt kaut kādu tekstu. Nu, piemēram, lauks, kur lietotājs ievada savu vārdu, vai komentārus. Šajā gadījumā nekādas pārbaudes īsti veikt nevar, jo jebkurš teksts jau pēc savas būtības ir derīgs. Būtu muļķīgi, piemēram, lietotājam aizliegt lietot pēdiņas savos komentāros. Vajag tikai vienmēr piedomāt pie tā, kā dažādās vietās jāapietas ar patvaļīgu tekstu, lai nerastos problēmas ar dažādiem īpašiem simboliem.

 

Pārsvarā gadījumu speciāli simboli tekstā var sagādāt problēmas tikai divās vietās - SQL kverijos, un pie atkal rādīšanas lietotājiem. Protams, var būt arī citi gadījumi, bet tie tad ir specifisiki. Pielieto veselo saprātu, un vienmēr padomā, vai veicot kaut kādu darbību ar patvaļīgu tekstu nevar rasties problēmas dēļ kaut kādiem simboliem.

 

SQL kverijos problēma var būt ar vienpēdiņu. T.i. ja lietotājs ievada, piemēram, es'ir un Tu to mēģini ievadīt datubāzē, tad tas varētu izskatīties aptuveni šādi:

mysql_query("INSERT INTO tabula (teksts) VALUES ('$Text');")

Kad šis kods izpildās, tad lietotāja ievadītā vērtība tiek ielikta iekšā šajā stringā, un tas viss kļūst ekvivalents šim:

mysql_query("INSERT INTO tabula (teksts) VALUES ('es'ir');")

Kā redzi, tas vairs nav pareizs kverijs, un Tu dabūsi kļūdas paziņojumu. No tā var atbrīvoties ar augšupminēto mysql_real_escape_string() funkciju. Šī funkcija saņem stringu, un ārā izdod citu stringu, kurā vienpēdiņām priekšā ir \ simbols. Rezultātā, Tu iegūsti šo:

mysql_query("INSERT INTO tabula (teksts) VALUES ('es\'ir');")

Tas jau ir pavisam derīgs kverijs. Vienpēdiņa nav vienīgais simbols, kuru šī funkcija apstrādā, bet Tev par to nevajag uztraukties. Tas, ko Tev vajag zināt ir - lai arī ko Tu dosi iekšā šai funkcijai, ārā viņa izdos stringu, kuru ir droši bāzt iekšā kverijā.

 

Populāra kļūda ir izmantot addslashes() metodi tā vietā, lai izmantot mysql_real_escape_string(). Tas nav droši, jo addslashes() nenodrošinās pret visiem sliktajiem simboliem.

 

Vēl ir vērts atcerēties:

  • mysql_real_escape_string() ir derīgs tikai tad, ja Tu strādā ar MySQL datubāzi. Citām datubāzēm (Oracle, MSSQL, Postgre, u.t.t.) ir savas funkcijas šim nolūkam, un mysql_real_escape_string() nederēs;
  • Jāuzmanās, lai vienam stringam šo funkciju neizsauktu divreiz. Tad būs šitā - ja sākumā bija es'ir, tad pēc vienas izsaukšanas būs es\'ir, un pēc divām - es\\\'ir, kas jau vairs nav pareizi;
  • Mūsdienās daudz ērtāks, ātrdarbīgāks, un vēl drošāks veids nekā mysql_real_escape_string() ir parametrizētie kveriji. Par to palasies citviet. Bet doma tāda, ka izmantojot tos, Tev principā nav iespējas dabūt SQL injekciju. Šeit vēl Tu vari kādreiz nomudīties un aizmirst izsaukt to mysql_real_escape_string(), vai izsaukt par daudz, bet tur tādas iespējas nav. Silti iesaku izmantot šo variantu, tas ir daudz pārāks visos variantos.

 

Otra lieta, par ko jāuztraucas ar tekstu no lietotāja ir tāda, ka to parādot atpakaļ lietotājam sliktie simboli var nočakarēt Tavu HTML kodu. Ļaundari to pat var izmantot, un iespraust kādu īpašu HTML kodu, kurš Tavu lietotāju browseros sāks izpildīt kaut kādu sliktu kodu. To pazīst ar vārdu XSS jeb "cross-site-scripting".

 

Šeit arī doma ir vienkārša. Tāpat kā eksistē mysql_real_escape_string(), ko lieto, kad tekstu liek iekšā kverijā, tā eksistē arī htmlspecialchars() funkcija, kura ļaunos simbolus pārveido par speciālu HTML kodu, lai tie tā arī browserī parādītos lietotājam, nevis tiktu uztverti kā HTML sastāvdaļa. Tev nav jāuztraucas par to, kuri simboli tie ir. Tikai atkal zini, ka šīs funkcijas izvadītais rezultāts ir drošs, lai to pa tiešo spraustu iekšā HTML kodā.

 

Atkal pāris piezīmītes:

  • Kā jau parasti, izsaukt šo funkciju divreiz vienam un tam pašam tekstam visu nočakarēs, tāpēc vienreiz nodrošinātu tekstu otrreiz nelaid cauri šai funkcijai.
  • Nav vērts izsaukt šo funkciju uzreiz kā Tu ielasi tekstu no $_GET vai $_POST masīviem. Tā Tu tikai apgrūtināsi savu darbu ar šo tekstu. Vislabāk šo funkciju izsaukt pašā pēdējā brīdī, tieši pirms teksta parādīšanas lietotājam.

 

Vēl viena klasiska drošības problēma, kas šeit nebija pieminēta, ir saistīta ar lietotāju parolēm. Bieži vien, taisot kādu weblapu, nākas taisīt datubāzē sarakstu ar lietotājiem un viņu parolēm. Gandrīz katrā weblapā mūsdienās ir "reģistrācijas" iespēja. Nedroša lieta ir glabāt paroli datubāzē tieši tādu, kā lietotājs to ievadīja. Tas pirmajā brīdī šķiet loģisks un vienkāršs risinājums, taču tam ir problēma. Ja kāds nozags Tavu DB (un tas pāris reizes ir gadījies pat BOOT.LV), viņš uzreiz redzēs visu Tavu lietotāju paroles. Tā kā cilvēkiem ir tendence vienu un to pašu paroli izmantot visur, tas ļaundarim paver plašas iespējas...

 

Klasisks risinājums šai problēmai ir paroli izlaist caur md5() funkciju. Šī funkcija no paroles izrēķinās maģisku kodu. Šis kods ir labs un maģisks tā, ka katrai parolei tas būs citādāks, un no koda atpakaļ paroli nevar dabūt. Šo kodu tad arī glabā DB. Kad lietotājs grib login'oties Tavā lapā, Tu viņa ievadīto paroli atkal izlaid caur md5() funkcijai, un salīdzini ar to, kas ir iekš DB. Ja sakrīt, tad lietotājs paroli zin.

 

Lai arī šis ir drošāk nekā glabāt paroli tīrā tekstā, tomēr mūsdienās arī eksistē paņēmieni, ar kuriem šī metode kļūst nedroša. Piemēram, eksistē milzīgas datubāzes kuras satur MD5 kodus visām parolēm, kas ir līdz 8 simbolus garas. Lai arī no MD5 koda nevar iegūt atpakaļ paroli, šo kodu var uzmeklēt šajā milzīgajā DB, un tur arī būs rakstīts, no kādas paroles šo kodu var iegūt.

 

Lai pret šo cīnītos, visvienkāršākā metode ir parolei vispirms piekabināt galā kādu garu, tikai Tev zināmu kodu (teiksim, 50 simboli, kas iegūti ar galvu dauzot pa klaviatūru), un tikai tad rēķināt MD5 kodu. Šo jau ļaundariem būs daudz grūtāk uzlauzt. Vēl arī MD5() funkcijas vietā var lietot sha1() funkciju. Šī funkcija ģenerē garāku kodu, kurš ir arī noturīgāks pret citām "laušanas" metodēm, kuras es šeit neaprakstīšu.

 

Ceru, ka palika mazliet skaidrāks? :)

Link to comment
Share on other sites

Papildus jau pateiktajam. Ja pastāv šāda iespēja (un šī iespēja pastāv gandrīz vienmēr), tad ir jāizmanto "iepriekšsagatavotie" vaicājumi jeb prepared statements.

Tātad nevis:

mysql_query("SELECT * FROM tabula WHERE id = $mainigais");

bet gan:

$vaicajums = mysqli_prepare($savienojums, 'SELECT * FROM tabula WHERE id = ?');

mysqli_stmt_bind_param($vaicajums, "i", $mainigais);

mysqli_stmt_execute($vaicajums);

... vairāk

 

Ja ir iespēja, tad var izmantot arī datubāzē glabātās procedūras jeb stored procedures, lai papildus izslēgtu iespēju izpildīt brīvi veidotus vaicājumus.

 

[upd] Runājot par parolēm, vari uzmest aci manai demonstrācijai par "Stateless session cookies" - koda piemēros ir arī, manuprāt, pietiekami daudz demonstrēts, kā aizsargāties pret SQL injekcijām.

http://php.lv/f/index.php?showtopic=11116

Edited by Aleksejs
Link to comment
Share on other sites

Gribu papildināt Vilx-, ka

1)Prātīgāk ir izmantot nevis system-wide salt, bet katram jūzerim izmantot savu. Tad rainbow tables būs derīgas tikai viena jūzera ietvaros.

2)Arī SHA1 ir rainbow tabulas un bez salt`a viņš nav derīgs paroļu hašošanai. MD5 vispār ir derīgs tikai failu integritātes nodrošināšanai.

3)Jāatceras, ka PHP ir tāds masīvs kā $_SERVER, kur daļa datu ir pilnīgi un absolūti droši (Failsistēmas ceļš utt), bet citi (User-Agent, kverij strings, referer, X_FORWARDER_FOR - jebkam, kas nāk no HTTP headeriem NEDRĪKST uzticēties. Tas pats attiecas uz IP noteikšanu ar X_FORWARDED_FOR => uzticēties var tikai vienā scenārijā - aplikācija ir deployota aiz reversā prokša un jams to headeri sūta. ).

4)Klasikai web app prātīgāk ir reģistrāciju un atbildību par jūzeru verifikāciju novelt kādam citam . To var darīt ar Open ID vai trauku pases palīdzību.

5)Prātīgākais variants ir izlasīt no GET / POST / COOKIE tos datus, kurus tu gaidi no klienta, novalidēt, nofiltrēt un iepūst kādā citā masīva vai datu struktūrā, un tālāk darboties ar jamiem, nevis aiztikt $_GET utt, jo tad var aizmirsties kaut ko novalidēt vai nofiltrēt .

6)Ja sistēma neļauj parametrizētos kverijus, tad vismaz neizmanto stringu konkaktēšanu, bet gan sprintf / uzraksti savu wrapperi jamam, kas automātiski eskeipo argumentus.

7)Izslēdz kļūdu paziņošanu publiski. Ne tikai tizli izskatās, bet arī dod ieskatu tavā koda semantikā uzbrucējam. Naher vajadzīgs.

 

Aleksej,

Par prepared statements te ir runāts daudz un dikti :) .

MySQLi paplašinājuma sintakse, ja ir prepared statementi ir select`i un vajag no viņiem dabūt datus ir tizla un neērta.

PDO caur resultset`u var normāli noiterēt (Ar foreach statementu vai klasiski ar while ciklu :)).

MySQLi sintakse ir tizla un neērta.

Rakstīt MySQL procedūras katram web app kverijam ir PITA un daļa shared hosting provideru to neļaus darīt, galvenokārt tādēļ, ka lai to izdarītu ir vajadzīga super privilēģija (Un katrs klients nav tik ļoti super, lai dotu super privilēģiju viņam). :>

Tad prātīgāk ir uzrakstīt tabulas un skatus ar stingri definētām datu domēna robežām un ļaut selectot tikai tur ;)

Link to comment
Share on other sites

Aleksej, Kristap - viss, ko jūs sakāt ir taisnība, bet tēmas autors vēl ir iesācējs, tā kā labāk centieties to visu paskaidrot vienkāršajā variantā. ;)

Link to comment
Share on other sites

Kristap - kas nu kuram ir PITA :p

Var iztikt gan bez prepared, gan bez stored - bet to pareiza izmantošana dod papildus drošības slāni.

Link to comment
Share on other sites

Ar 100% drošību nevar principā uztaisīt. To var pierādīt. Taču mēdz būt dažādas programmas, kuras iziet cauri kodam un mazliet pasaka par labo stilu. Tas, protams, negarantē drošību, taču tā var atrast dažādas kļūdas un potenciāli vājākas vietas. Šobrīd gan nevienu tādu programmu priekš PHP nezināšu.

Link to comment
Share on other sites

Nedaudz novirzoties no tēmas, bet tomēr pieturoties pie tās. Par drošības risinājumiem ronājot vispārīgos terminos, ja gribam tiešām labu drošības risinājumus, tad pašam ir jābūt tomēr no tā ļaunā kaut kas, tai kārei uzlaust to lapu, ja to var izdarīt pats ar saviem spēkiem, tad arī atradīsi kļūdas kur tās ir bijušas ;) + spēsi nodrošināt to drošību. Vai vēl ir tāds paliels risks, bet pakļaut to lapu uzbrukumam un pēc tam vērot log`us kur tad gudrais prāts caurumus atradis jau pirms laika. Pats savu laik ar līdzīgām lietām šitā eksperimentēju, un zinies bija rezultāti nākotnei.

Link to comment
Share on other sites

Pateicos par atsaucību, tiešām ļoti noderīgi, es izpetisu Jūsu dotos linkus!

 

Man radās papildu jautājums. Ja es uztaisu sistēmu, piemēram, kā interneta veikalā, kad nereģistrēti leitotāji var redzēt preces, bet reģistrētiem parādās poga 'pirkt'. Manuprāt to var taisīt ar if piem.

if($logged==1){echo '<input type="submit" value="submit" name="submit" />';}

Vai nepastāv iespēja, ka nereģistrēts lietotājs varētu izmainīt mainīgo $logged no 0 uz 1 un nodarīt kādu ļaunumu, spēlējoties ar pogu pirkt?

Edited by oxxxis
Link to comment
Share on other sites

#14 Atkarīgs no tā, uz kā tev tas mainīgais ir balstīts, nevajadzētu piesaistīt mainīgo cepumam, tad gan var sanākt ziepes, jāizveido sesija un jāglabā dati db.

Link to comment
Share on other sites

Sesijas mainīgie glabājas uz servera un klientam netiek sūtīti. Klientu sasaista ar viņam definētajiem sesijas mainīgajiem izmantojot sesijas identifikatoru (kuru sūta izmantojot Cookie vai URL).

Link to comment
Share on other sites

Vai nepastāv iespēja, ka nereģistrēts lietotājs varētu izmainīt mainīgo $logged no 0 uz 1 un nodarīt kādu ļaunumu, spēlējoties ar pogu pirkt?

Pieliec $logged==1 nosacījumu arī tai vietā, kur apstrādā submit pogas nospiešanu.

Link to comment
Share on other sites

Nē, sesijas saturam no klienta puses nevar tikt klāt. Tā ir viena lieta, uz ko Tu vari paļauties.

 

Tev ir jāsaprot viena lieta - visā šajā web pasākumā darbojas divas puses - serveris un klients (jebšu saukts arī par browseri vai pārlūkprogrammu).

 

PHP kods izpildās servera pusē. Pie klienta viņš nenonāk. PHP koda rezultātā tiek uzģenerēta HTML kods, kurš tiek nosūtīta klientam. Klients tad ņem šo uzģenerēto HTML kodu un parāda lietotājam.

 

JavaScript kods savukārt izpildās klienta pusē. Servera pusē nekāds JavaScript neizpildās. Bet klienta pusē tas ir vienīgais kods, kas var izpildīties.

 

PHP kods patiesībā var ģenerēt jebko, kas tiek sūtīts uz klientu. Tas var būt ne tikai HTML, bet arī CSS, JavaScript vai pat bildes. Klients neko nezin par to, kas notiek servera pusē. Klients tikai sūta pieprasījumus (piem. "GET http://www.boot.lv/") un saņem atbildes uz šiem pieprasījumiem. Ko serveris dara, lai šo atbildi uzģenerētu, nav klienta daļa. Tas var vienkārši atgriezt faila saturu, vai arī tas var izpildīt PHP kodu un atgriezt šī koda rezultātu.

 

Starp citu - plašākam redzeslokam - PHP nav vienīgā valoda, kas var izpildīties servera pusē. Tādu ir bezgala daudz. Piemēram, Ruby, C#, VB.NET, Java, Python, Perl - tās visas tiek izmantotas weblapu izstrādē. PHP gan šobrīd ir populārākā un, iespējams, viena no vienkāršākajām.

 

Sesijas, tāpat kā PHP kods, glabājas servera pusē. PHP gadījumā process ir šāds: ir viens folderītis, kur ir daudzi faili - pa vienam katrai sesijai. Kad atnāk lietotājs, kuram cepumiņā PHPSESSID nekā nav, tiek izveidots jauns failiņš. Failiņa nosaukums ir diezgan garš random strings. To sauc par sesijas identifikatoru. Tā kā viņš ir tik garš, tad iespējamība, ka divām sesijām būs vienādi identifikatori, ir praktiski nekāda. Šis identifikators tad tiek ielikts cepumiņā PHPSESSID. Kad skripts ir izpildījies, tad viss sesijas saturs tiek ierakstīts failiņā. Kad lietotājs izpilda nākamo pieprasījumu, viņam jau cepumiņā PHPSESSID ir failiņa nosaukums. PHP tad šo failiņu uzmeklē, un dara tā saturu Tev pieejamu caur $_SESSION masīvu. Tā kā failiņš nevienā brīdī pie klienta nenonāk (tikai failiņa nosaukums), tad arī klients nevar ietekmēt šī failiņa saturu. Vienīgais, ko klients var sliktu izdarīt, ir, ka viņš var nomainīt sava PHPSESSID cepumiņa vērtību, lai tas saturētu cita failiņa nosaukumu. Taču tā kā tie nosaukumi ir tik gari un pilnīgi random, tad uzminēt tos nav iespējams. Principā morāle ir tāda, ka par sesiju drošību Tev nevajag daudz uztraukties - PHP jau pats par to ir parūpējies. Tu vari paļauties uz to, ka tas, kas ir iekš $_SESSION netiks izmainīts no klienta puses.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...