PHP saugumas, svetainiu pažeidžiamumas

Sveiki,

Norėčiau sužinoti visus būdus kaip geriausia savo puslapti apsaugoti

1. Kaip apsisaugoti nuo SQL injection? Gerai, naudoju PDO ir prepare sakinius, ką toliau galima?

2. XSS atakos kokios galimos jos ar uztenka htmlspecialchars?

3. Esu girdėjas, kad galima injekcija ikelti per failus upload'inant pvz per paveiksliukus, kaip jos yra daromos ir kaip nuo ju apsisaugoti?

4. Slaptazodziu kodavimas naudojant mcrypt ar tai pats geriausias būdas su salt ar dar yra geresniu?

Išvardinau čia vienas iš pagrindiniu nežinau kokiu dar gali būti pakenkimo būdų tiesiogiai be šiu, jei galite pagelbėkite ir pridėkite kitus būdus. :)

Jei galite nurodykite šaltinius informacijos ar iš savo patirties ką nors pasakyt galėtumėt ar bet kokios informacijos suteikti :)

• Ieškojau informacijos internete, bet greičiausiai blogai ieškojau, kad neradau ko man reikia, tad pageidauju nerašykit komentaru kaip „PaGooglink“

Dėkoju iš anksto už suteikta naudinga informacija ir supratinguma.

P.S. Atsiprašau už gramatikos klaidas kuriu tikrai daug.

1 rezultatas googlėje, pilna informacijos: http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php

1 rezultatas googlėje, pilna informacijos: http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php

Tai čia paprasčiausias PDO naudojimas taikimas prepare sakinius ir iterpiamus kintamuosius bind'inant tai aš naudoju, tačiau daugiau kaip ir ten nieko neradau prabėgant naudingo.

1. Jeigu tvarkingai visi kreipimaisi i DB yra per prepared statements, tada nebus problemu su SQL injection. Siaip, man labiau patinka stored procedures, bet sis polinkis susijes ir su kitais dalykais ne tik saugumu.

2. Kaip ir su DB, prepared statements apsaugos nuo XSS, taciau siulyciau dar ir is DB imama teksta praleisti pro funkcijas, kurios panaikintu special chars.

3. Nera lengva apsisaugot, geriausia yra vengti failu ikelimo i serveri, nebent to tikrai reikia. Aplamai, siulyciau leisti ka nors ikelti tik tada jeigu tai tavo service (file upload) ir nori investuot pinigus i apsauga.

4. sha256+RANDOM salt (daug kas daro klaida ir salt nedaro random) ir nebus problemu.

5. Pasiskaityk ir del XSRF ir apsaugos nuo jo (form tokens).

1. Jeigu tvarkingai visi kreipimaisi i DB yra per prepared statements, tada nebus problemu su SQL injection. Siaip, man labiau patinka stored procedures, bet sis polinkis susijes ir su kitais dalykais ne tik saugumu.

 

2. Kaip ir su DB, prepared statements apsaugos nuo XSS, taciau siulyciau dar ir is DB imama teksta praleisti pro funkcijas, kurios panaikintu special chars.

 

3. Nera lengva apsisaugot, geriausia yra vengti failu ikelimo i serveri, nebent to tikrai reikia. Aplamai, siulyciau leisti ka nors ikelti tik tada jeigu tai tavo service (file upload) ir nori investuot pinigus i apsauga.

 

4. sha256+RANDOM salt (daug kas daro klaida ir salt nedaro random) ir nebus problemu.

 

5. Pasiskaityk ir del XSRF ir apsaugos nuo jo (form tokens).

1. O tai prepare sakiniai 100procentine apsauga nuo SQL injection? ar įmanoma pro ten dar kaip nors injection ikišti? o pro kokias funkcijas praleisti be htmlspecialchars ir trim?

3. O tai nežinai kaip apsisaugoti nuo file injection? :/

4. tai tas salt tik nuo zodyno brute force jei neklistu apsaugo teisingai? :) jei klistu plačiau ir patikslink :)

O šis užkodavimo būdas yra geras ar galima ką nors geresnio?

<?php
class Encryption {

 // raktas i duomenu atkodavima
   var $skey = "atsitiktinisnesikeiciantiskodas";

   public  function safe_b64encode($string) {
       $data = base64_encode($string);
       $data = str_replace(array('+','/','='),array('-','_',''),$data);
       return $data;
   }
   public function safe_b64decode($string) {
       $data = str_replace(array('-','_'),array('+','/'),$string);
       $mod4 = strlen($data) % 4;
       if ($mod4) {
           $data .= substr('====', $mod4);
       }
       return base64_decode($data);
   }
   public  function encode($value){
       if(!$value){return false;}
       $text = $value;
       $iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
       $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
       $crypttext = mcrypt_encrypt(MCRYPT_RIJNDAEL_256, $this->skey, $text, MCRYPT_MODE_ECB, $iv);
       return trim($this->safe_b64encode($crypttext)); 
   }
   public function decode($value){
       if(!$value){return false;}
       $crypttext = $this->safe_b64decode($value); 
       $iv_size = mcrypt_get_iv_size(MCRYPT_RIJNDAEL_256, MCRYPT_MODE_ECB);
       $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
       $decrypttext = mcrypt_decrypt(MCRYPT_RIJNDAEL_256, $this->skey, $crypttext, MCRYPT_MODE_ECB, $iv);
       return trim($decrypttext);
   }
}
$encryption = new Encryption();
?>

Jei galit patobulinkit ir paiškinkite kas negerai ir kuo jūsų patobulinimas geresnis nei būvo.

1. O tai prepare sakiniai 100procentine apsauga nuo SQL injection? ar įmanoma pro ten dar kaip nors injection ikišti? o pro kokias funkcijas praleisti be htmlspecialchars ir trim?

3. O tai nežinai kaip apsisaugoti nuo file injection? :/

4. tai tas salt tik nuo zodyno brute force jei neklistu apsaugo teisingai? :) jei klistu plačiau ir patikslink :)

 

O šis užkodavimo būdas yra geras ar galima ką nors geresnio?

1. SQL injection vykdomas exploitinant SQL kalba. Prepared statements uz akiu escape'ina duodamus duomenis, taip neleisdamas tiems duomenims tureti prasmes SQL kalboje. Del sios priezasties prepared statemens 100% apsaugos nuo injections.

1.1 htmlspecialchars pilnai uztektu, o del trim, tai priklauso ar ji naudoji kai idedami duomenys i DB ar ne. Nors aplamai, trim nieko bendro su apsauga neturi, jis skirtas tarpams sakiniu gale/pradzioj panaikinti.

3. I si klausima sunku atsakyti. Kai kurie hosting provider'iai daro savo ikeliamu failu patikrinima, kad juose nebutu virusu ir pan dalyku (zinoma kokio gerumo ta ju apsauga, sunku pasakyti), todel tokiuose hostinguose tau tereikia atlikti meta-data checkus del formato ir pan. Jeigu serveris tavo, tai tada jau visai kita kalba.

3.1 Kas liecia tai, del ko nepatariu leisti ikelineti failu i serveri labiausiai susije su tavo resources (jeigu hosting paslaugomis naudojamasi), mat neturint tvarkingo front-end galima atverti langa kenkejams ikelineti neriboto kiekio failus.

4. Random salt naudojami tam, kad hashinant du vienodus password'us butu gaunami du skirtingi hashes, kas reiskia, kad atveju kai kenkejai gauna tavo DB, jie negaletu rade du vienodus hashes atrasti ta non-random salt ir taip labai palengvinti kitu passwords suzinojima. Kas liecia brute force zodyno, tai nuo jo apsauga yra ne kaskokie tai hashes ar kas, bet password policies, pvz.: min 8 zenklai, 1 didzioji, 1 skaicius ir pan.

Del tavo pasiulyto uzkodavimo budo negaliu nieko pasakyti, nebent tai, jog jeigu tai pripazintas algoritmas - gerai. Viena is didziausiu klaidu kurias daro programuotojai kas liecia sauguma - savo sugalvotu hashing algoritmu kuryba.

P.s. labai dazna saugumo klaida kuria esu mates, tai id's/keys atskleidimas select ir pan formu elementuose ir back'ende patikros nebuvimo, kuris patikrintu ar tie values gauti teisingi. Pvz butu: kokia jusu lytis? - duodamas drop down su Mr, Mrs ir pan. Values tokio select buna dazniausiai 1=> MR, 2=>Mrs,3=>... . Kenkejui tereikia atsidarius saltinio editoriu pakeisti values i bet ka ir jeigu backende nera patikros kad value gautas tikrai teisingas, gali isivelti klaidos ne tik duomenu bazeje bet ir sistemoje jeigu ji remiasi ranges ir pan.

1. SQL injection vykdomas exploitinant SQL kalba. Prepared statements uz akiu escape'ina duodamus duomenis, taip neleisdamas tiems duomenims tureti prasmes SQL kalboje. Del sios priezasties prepared statemens 100% apsaugos nuo injections.

1.1 htmlspecialchars pilnai uztektu, o del trim, tai priklauso ar ji naudoji kai idedami duomenys i DB ar ne. Nors aplamai, trim nieko bendro su apsauga neturi, jis skirtas tarpams sakiniu gale/pradzioj panaikinti.

3. I si klausima sunku atsakyti. Kai kurie hosting provider'iai daro savo ikeliamu failu patikrinima, kad juose nebutu virusu ir pan dalyku (zinoma kokio gerumo ta ju apsauga, sunku pasakyti), todel tokiuose hostinguose tau tereikia atlikti meta-data checkus del formato ir pan. Jeigu serveris tavo, tai tada jau visai kita kalba.

3.1 Kas liecia tai, del ko nepatariu leisti ikelineti failu i serveri labiausiai susije su tavo resources (jeigu hosting paslaugomis naudojamasi), mat neturint tvarkingo front-end galima atverti langa kenkejams ikelineti neriboto kiekio failus.

4. Random salt naudojami tam, kad hashinant du vienodus password'us butu gaunami du skirtingi hashes, kas reiskia, kad atveju kai kenkejai gauna tavo DB, jie negaletu rade du vienodus hashes atrasti ta non-random salt ir taip labai palengvinti kitu passwords suzinojima. Kas liecia brute force zodyno, tai nuo jo apsauga yra ne kaskokie tai hashes ar kas, bet password policies, pvz.: min 8 zenklai, 1 didzioji, 1 skaicius ir pan.

 

Del tavo pasiulyto uzkodavimo budo negaliu nieko pasakyti, nebent tai, jog jeigu tai pripazintas algoritmas - gerai. Viena is didziausiu klaidu kurias daro programuotojai kas liecia sauguma - savo sugalvotu hashing algoritmu kuryba.

 

P.s. labai dazna saugumo klaida kuria esu mates, tai id's/keys atskleidimas select ir pan formu elementuose ir back'ende patikros nebuvimo, kuris patikrintu ar tie values gauti teisingi. Pvz butu: kokia jusu lytis? - duodamas drop down su Mr, Mrs ir pan. Values tokio select buna dazniausiai 1=> MR, 2=>Mrs,3=>... . Kenkejui tereikia atsidarius saltinio editoriu pakeisti values i bet ka ir jeigu backende nera patikros kad value gautas tikrai teisingas, gali isivelti klaidos ne tik duomenu bazeje bet ir sistemoje jeigu ji remiasi ranges ir pan.

4. Mano šis algoritmas ištrauktas yra iš phpclasses.org tai čia toks ir pripažinimas :D o gal norėtum pasidalinti tokiu algoritmu su random hash ir salt? biski turiu ir kita toki idomu klausima o verta taip pat uzkoduoti username? :D Gavus sakykim sąraša bus nežinomi nei slaptažodis nei vartotojo vardas ar el., paštas :D beja tavo užkodavimo algoritmas yra atkoduojamas? :) Jei gali įkelk :)

3. Man reikėtu, kad galimėt įkelinėt paveiksliukus bet esmės aišku nekeičia ar video ar paveiksliukas ar koks kitas dar :D

gaila tikiuosi dar kas nors atsilieps ir atsakis į ši man klausima :)

1. Tai tada drasiai ir naudosiu PDO prepare sakinius ir bindValue :D

Ačiū. ;)

4. Mano šis algoritmas ištrauktas yra iš phpclasses.org tai čia toks ir pripažinimas :D o gal norėtum pasidalinti tokiu algoritmu su random hash ir salt? biski turiu ir kita toki idomu klausima o verta taip pat uzkoduoti username? :D Gavus sakykim sąraša bus nežinomi nei slaptažodis nei vartotojo vardas ar el., paštas :D beja tavo užkodavimo algoritmas yra atkoduojamas? :) Jei gali įkelk :)

3. Man reikėtu, kad galimėt įkelinėt paveiksliukus bet esmės aišku nekeičia ar video ar paveiksliukas ar koks kitas dar :D

gaila tikiuosi dar kas nors atsilieps ir atsakis į ši man klausima :)

1. Tai tada drasiai ir naudosiu PDO prepare sakinius ir bindValue :D

 

Ačiū. ;)

4.1 Gaila, bet neturiu pasidalinti to ka galetum panaudoti.

4.2 Kas liecia username, email ir password, panasu, kad nelabai supranti skirtumo tarp hashing ir encryption. Hashing yra neatverciamas, t.y. neimanoma is hash isgauti duomens kuris buvo uzhashintas, o encryption tik pavercia tai kas turi prasme i tai kas neturi prasmes ir vice versa. Jeigu tai duomo kurio value tau nesvarbus - pvz password, tada naudoji hash, bet jeigu tai kas kas ka tau reikes atversti atgal - encrypt. Siaip tuokie duomenys kaip username ir email dazniausiai nera encryptinami. Duomenu bazeje dazniausiai encryptinami tik privati informacija apie zmones - namu adresai, telefonai ir pan.

4.1 Gaila, bet neturiu pasidalinti to ka galetum panaudoti.

4.2 Kas liecia username, email ir password, panasu, kad nelabai supranti skirtumo tarp hashing ir encryption. Hashing yra neatverciamas, t.y. neimanoma is hash isgauti duomens kuris buvo uzhashintas, o encryption tik pavercia tai kas turi prasme i tai kas neturi prasmes ir vice versa. Jeigu tai duomo kurio value tau nesvarbus - pvz password, tada naudoji hash, bet jeigu tai kas kas ka tau reikes atversti atgal - encrypt. Siaip tuokie duomenys kaip username ir email dazniausiai nera encryptinami. Duomenu bazeje dazniausiai encryptinami tik privati informacija apie zmones - namu adresai, telefonai ir pan.

Aišku supratau.

Aš radau mcrypt čia atrodo kaip ir hash'ingas rezultatas atkoduojamas o užkoduota dalis visalaik besikeičianti, jei gali pakomentuok ši koda :)

Aišku supratau.

Aš radau mcrypt čia atrodo kaip ir hash'ingas rezultatas atkoduojamas o užkoduota dalis visalaik besikeičianti, jei gali pakomentuok ši koda :)

Man neatidaro tavo duotos nuorodos. O kas liecia mcrypt, tai kaip ir pats pavadinimas sako, tai encryption. T.y. duomenys uzkuodojami tam kad nebutu human readable, bet juos butu galima atgal atversti i human readable. Cia skirtingas dalykas nuo hash, kur paemus kad ir 1gb dydzio txt faila galima gauti tik 128, 256 ar pan ilgio digest, is kurio neimanoma atkurti atgal ta 1gb faila.

O del to, kad uzkuodota dalis visalaik keiciasi, bet vistiek ja galima atgal atkoduoti - tai tik sio encryption algoritmo savybe, kuri leidzia tam tikra isivaizduojama randomization, nors is tiesu nera jokio randomness, nes tada neitu atgal atversti.

Man neatidaro tavo duotos nuorodos. O kas liecia mcrypt, tai kaip ir pats pavadinimas sako, tai encryption. T.y. duomenys uzkuodojami tam kad nebutu human readable, bet juos butu galima atgal atversti i human readable. Cia skirtingas dalykas nuo hash, kur paemus kad ir 1gb dydzio txt faila galima gauti tik 128, 256 ar pan ilgio digest, is kurio neimanoma atkurti atgal ta 1gb faila.

 

O del to, kad uzkuodota dalis visalaik keiciasi, bet vistiek ja galima atgal atkoduoti - tai tik sio encryption algoritmo savybe, kuri leidzia tam tikra isivaizduojama randomization, nors is tiesu nera jokio randomness, nes tada neitu atgal atversti.

Pamiršau, reikia ten užsiregistruoti :D atsiprašau prikabinu faila :)

Dėl tu failu injection pagalvojau pavyzdžiui su paveiksliukais tai gal padet galėtu resize ir jo atvaizdavimas svetaineje ne *.jpg o image.php?id=5895132 panaudojant GD galbūt visa tai paslėptu bent jau sumažintu rizika :D

mcrypt-2009-04-29.zip

Pavyko pagaliau pasiekti tavo duota nuoroda :/

Sis kodas tera paprasta encryption klase, kuri tiesiog naudojasi php built-in funkcijomis kad uzkuoduotu/atkoduotu duomeni. Hash yra naudojamas tik del IV dydzio, t.y. tavo duomuo nera hash'inamas, tik uzkuodojamas.

Pamiršau, reikia ten užsiregistruoti :D atsiprašau prikabinu faila :)

Dėl tu failu injection pagalvojau pavyzdžiui su paveiksliukais tai gal padet galėtu resize ir jo atvaizdavimas svetaineje ne *.jpg o image.php?id=5895132 panaudojant GD galbūt visa tai paslėptu bent jau sumažintu rizika :D

mcrypt-2009-04-29.zip

Failu injection yra skirtas tam, kad sugadinti/isilausti i serveri, jis nera skirtas tos svetaines vartotojams mulkinti. T.y. nera realios prasmes slepti paveiksliuko naudojantis tavo pasiulymu, saugumui tai neturi itakos. Tai ka tu cia siulai daro tik tie, kurie nenori, kad ju svetaine nebutu naudojama kaip koks tai image hostingas (pvz, nurodant avatar duodamas adresas iki paveiksliuko ikelto i tavo svetaine). Naudojant tavo pasiulymu neitu to padaryti, nes svetaine, kurioje duodamas tas adresas iki paveiksliuko, nesugebetu to paveiksliuko 'istraukti'.

Pavyko pagaliau pasiekti tavo duota nuoroda :/

 

Sis kodas tera paprasta encryption klase, kuri tiesiog naudojasi php built-in funkcijomis kad uzkuoduotu/atkoduotu duomeni. Hash yra naudojamas tik del IV dydzio, t.y. tavo duomuo nera hash'inamas, tik uzkuodojamas.

 

 

 

Failu injection yra skirtas tam, kad sugadinti/isilausti i serveri, jis nera skirtas tos svetaines vartotojams mulkinti. T.y. nera realios prasmes slepti paveiksliuko naudojantis tavo pasiulymu, saugumui tai neturi itakos. Tai ka tu cia siulai daro tik tie, kurie nenori, kad ju svetaine nebutu naudojama kaip koks tai image hostingas (pvz, nurodant avatar duodamas adresas iki paveiksliuko ikelto i tavo svetaine). Naudojant tavo pasiulymu neitu to padaryti, nes svetaine, kurioje duodamas tas adresas iki paveiksliuko, nesugebetu to paveiksliuko 'istraukti'.

Tik sugadinti? Su failu injection pasižiurėk plačiau mano nuomone su ja įmanoma yra gauti visus php failus su visais algoritmais ir duomenimis į duomenu bazes o tai taspats kas viska padėti ant lėkštutės :D

Kaip tai nepavyktu istraukti argumentuok? Pavyktu juk, faila GD sistema istrauks ir atvaizduos kaip aš noriu :)

Tik sugadinti? Su failu injection pasižiurėk plačiau mano nuomone su ja įmanoma yra gauti visus php failus su visais algoritmais ir duomenimis į duomenu bazes o tai taspats kas viska padėti ant lėkštutės :D

Kaip tai nepavyktu istraukti argumentuok? Pavyktu juk, faila GD sistema istrauks ir atvaizduos kaip aš noriu :)

Panasu, nepaminejau viska. Taip, su file injection galima gauti duomenis is serverio. Kas liecia GD, panasu parasiau ne visai aiskiai ka turejau omenyje, kai sakiau negales istraukti, bet tai nlb svarbu siame kontekste. Svarbesnis dalykas yra tai, kad GD nepades tau nuo faile injection (na tiksliau nuo tam tikro tipo file injection), nes file esantis injection buna ivykdomas kai tas failas yra nuskaitomas serverio, o ne kai generuojamas atvaizdas vartotojui.

Aplamai, nebent tai tavo serveris, tau neverta rupintis daug del file saugumo, tik del ziurejimo, kad butu ne per didelis (cia padeda flash uploader, nes jis gali aptikti file dydi is front-end puses) ir gero formato. Tikroji apsauga turi buti atliekama is hosting provider puses.

Panasu, nepaminejau viska. Taip, su file injection galima gauti duomenis is serverio. Kas liecia GD, panasu parasiau ne visai aiskiai ka turejau omenyje, kai sakiau negales istraukti, bet tai nlb svarbu siame kontekste. Svarbesnis dalykas yra tai, kad GD nepades tau nuo faile injection (na tiksliau nuo tam tikro tipo file injection), nes file esantis injection buna ivykdomas kai tas failas yra nuskaitomas serverio, o ne kai generuojamas atvaizdas vartotojui.

 

Aplamai, nebent tai tavo serveris, tau neverta rupintis daug del file saugumo, tik del ziurejimo, kad butu ne per didelis (cia padeda flash uploader, nes jis gali aptikti file dydi is front-end puses) ir gero formato. Tikroji apsauga turi buti atliekama is hosting provider puses.

Tai taip mano serveris :)

O kodėl nereikia jau rūpintis? Na, juk resizinant faila keiciasi jo turinys +- tai issidarkis koks nors, na bet gal ir klystu, vartotojo pusėje atliekamas patikrinimas nėra patikimas, o iš serverio pusės patikimas tik kreivos rankos gali pakišti ir problema bus programuotojo. Net nežinau, kaip dar galėčiau apsisaugoti :D

Tai taip mano serveris :)

O kodėl nereikia jau rūpintis? Na, juk resizinant faila keiciasi jo turinys +- tai issidarkis koks nors, na bet gal ir klystu, vartotojo pusėje atliekamas patikrinimas nėra patikimas, o iš serverio pusės patikimas tik kreivos rankos gali pakišti ir problema bus programuotojo. Net nežinau, kaip dar galėčiau apsisaugoti :D

Kadangi file injection apsauga, nera ta sritis, apie kuria galeciau sakyti, kad gerai nusimanau, galiu duoti tik tips, be tikru pavyzdziu:

• Naudok scaneri incoming failams, kuris sugebetu aptikti ar tas failas tikrai yra tas kas sakosi yra. Sie scaneriai pagrinde naudojami tam, kad sakykim .exe failas, kuris padarytas kad atrodytu kaip .jpg nebutu ileistas i tavo serveri.
  
• Pro scaneri praleistus failus regeneruok (pvz.: pakeisk dydi->ji vel atstatyk), tai apsaugos vartotojus kurie nores ta paveiksliuka parsisiusti i kompiuteri, nes viduje esantis injection bus sugadintas.
  

Sitai apsaugos tavo sistema nuo 99,9% visu file injections, o tas likes 0,1% tau nelabai aktualus, nes duodu garantija, kad nebent tavo svetaineje esanti informacija labai vertinga, niekas negais laiko kuriant ta 0,1% faila =] (nelabai daug zmoniu moka tai daryti aplamai ir tai uzima daug laiko)

Sveiki,

 

Norėčiau sužinoti visus būdus kaip geriausia savo puslapti apsaugoti

 

1. Kaip apsisaugoti nuo SQL injection? Gerai, naudoju PDO ir prepare sakinius, ką toliau galima?

2. XSS atakos kokios galimos jos ar uztenka htmlspecialchars?

3. Esu girdėjas, kad galima injekcija ikelti per failus upload'inant pvz per paveiksliukus, kaip jos yra daromos ir kaip nuo ju apsisaugoti?

4. Slaptazodziu kodavimas naudojant mcrypt ar tai pats geriausias būdas su salt ar dar yra geresniu?

 

Išvardinau čia vienas iš pagrindiniu nežinau kokiu dar gali būti pakenkimo būdų tiesiogiai be šiu, jei galite pagelbėkite ir pridėkite kitus būdus. :)

Jei galite nurodykite šaltinius informacijos ar iš savo patirties ką nors pasakyt galėtumėt ar bet kokios informacijos suteikti :)

 

• Ieškojau informacijos internete, bet greičiausiai blogai ieškojau, kad neradau ko man reikia, tad pageidauju nerašykit komentaru kaip „PaGooglink“

 

Dėkoju iš anksto už suteikta naudinga informacija ir supratinguma.

P.S. Atsiprašau už gramatikos klaidas kuriu tikrai daug.

Apie SQL injekciją jau kažkas papasakojo.

2. Jei nekiši vartotojo inputo į HTML atributus, į JS kodą, ir pan., tai visai užtenka htmlspecialchars().

3. Reikia visikai atskirti vietą file uploadams nuo PHP kodo, kad vartotojų įkelti failai net neitų per PHP interpretatorių jokiu būdu. Kažin, kiek tai įmanoma shared hostinge.

4. Mcrypt nėra tiesiog PHP paketas simetriniam šifravimui? Slaptažodžius reikia hešuoti, ne šifruoti. Jei gali atgauti vartotojo plaintext passwordą, tai jau yra nesaugu. Šiaip jau reiktų naudoti Bcrypt, PBKDF2 arba Scrypt. PHP 5.5 (arba senesnės naudojant password_compat) turi nuostabią api, kuri leidžia lengvai naudoti bcrypt. (password_hash() ir password_verify()). Naudok tai su normaliu Bcrypt cost'u ir būk ramus. Random salt'ais pasirūpinta už tave.

O šiaip kažkas jau davė OWASP Top 10. Ten gal ir nebus duotas konkretus PHP kodas problemoms spręsti, bet pačios problemos tikrai gerai aprašytos. Yra net lietuviška versija. https://cert.litnet.lt/lt/dokumentai/pagrindiniai-web-sistemu-pazeidziamumai-ir-saugos-budai

Apie SQL injekciją jau kažkas papasakojo.

 

2. Jei nekiši vartotojo inputo į HTML atributus, į JS kodą, ir pan., tai visai užtenka htmlspecialchars().

3. Reikia visikai atskirti vietą file uploadams nuo PHP kodo, kad vartotojų įkelti failai net neitų per PHP interpretatorių jokiu būdu. Kažin, kiek tai įmanoma shared hostinge.

4. Mcrypt nėra tiesiog PHP paketas simetriniam šifravimui? Slaptažodžius reikia hešuoti, ne šifruoti. Jei gali atgauti vartotojo plaintext passwordą, tai jau yra nesaugu. Šiaip jau reiktų naudoti Bcrypt, PBKDF2 arba Scrypt. PHP 5.5 (arba senesnės naudojant password_compat) turi nuostabią api, kuri leidžia lengvai naudoti bcrypt. (password_hash() ir password_verify()). Naudok tai su normaliu Bcrypt cost'u ir būk ramus. Random salt'ais pasirūpinta už tave.

 

O šiaip kažkas jau davė OWASP Top 10. Ten gal ir nebus duotas konkretus PHP kodas problemoms spręsti, bet pačios problemos tikrai gerai aprašytos. Yra net lietuviška versija. https://cert.litnet.lt/lt/dokumentai/pagrindiniai-web-sistemu-pazeidziamumai-ir-saugos-budai

2. Bet jei aš kišu į išvedima tai ką daugiau pasiulyti gali?

3. Visai pamiršau, kad galima ir taip, bet ar daugiau problemu pažeidžiamumo man iškilti negali?

4. O kofidencialia informacija kaip užkoduoti kuria reikėtu visvien atkoduoti ir ją panaudoti?

4.1 password_hash() ir password_verify() tik tokias paprastas reikia naudoti, ar reikėtu kurti dar kokias class'es ir dar su jom kažka daryti?

2. Bet jei aš kišu į išvedima tai ką daugiau pasiulyti gali?

3. Visai pamiršau, kad galima ir taip, bet ar daugiau problemu pažeidžiamumo man iškilti negali?

4. O kofidencialia informacija kaip užkoduoti kuria reikėtu visvien atkoduoti ir ją panaudoti?

4.1 password_hash() ir password_verify() tik tokias paprastas reikia naudoti, ar reikėtu kurti dar kokias class'es ir dar su jom kažka daryti?

2. Sakau. Jei kiši tarp HTML tagų, htmlspecialchars(). Kitiems atvejams escapinti yra atskiros priemonės (pvz. kokie nors JS stringai, ir pan., turės jau kitokias sintaksės taisykles). Tarkim, jei kiši inputą į kokius HTML atributus, tada užduotis sunkėja, bet htmlspecialchars() su ENT_QUOTES turėtų būt žingsnis į tinkamą pusę.

3. Bent jau local file inclusion tada bus pamiršta :) O taip pat galiausiai jei tikiesi tam tikro dalyko (paveikslėlio), tai naudoti kokį nors API tam (GD?) ir tikrinti, ar ten tikrai normalūs duomenys.

4. Realiai gali šifruoti, bet nėra gero sprendimo laikyti šifravimo raktams... Nes, jei jau įsilaužėlis pateko pas tave, tai ir šifravimo raktas gulės kur nors šalia.

4.1. Ar darysi kokias klases, ar ką, priklauso nuo tavęs. Kvailokas klausimas. Klasės jau su saugumu nesusiję, čia grynai architektūrinis sprendimas. Manau, tos funkcijos ir taip yra gerai padarytos ir jokios sudėtingos objektinės API čia nereikia.

Kazka suintrigavau parasysiu del upload

viena problemu - gal jau isnykusi - nepatestavau

http://httpd.apache.org/docs/2.2/mod/mod_negotiation.html

realiai esant aktyviam siam moduliui

tarkim failas

aaaaaaaa.php.gif - butu ivykdomas kaip PHP

serveriai.lt lyg atjungtas sis modulis

kitas gvildentas klausimas, upload direktorijoje .htaccess failo deka galima kad vietoj php failu vykdymo pvz padaryti source rodyma