Slaptas katalogiukas yra tokio pat adreso, kaip ir kitas lietuviams prieinamas žurnalas, tik subkatalogas vadinasi phpmag. Na, URL’as susideda iš šio serverio adreso ir subkatalogo. Jei kam nors kas neaišku, klauskite bet kuriuo kontaktavimo būdu, kokiu tik galite mane rasti. Už šitą gėrį turime būti dėkingi vyrukui, kurio nickas yra drawgas.

Apribokime sistemos resursus

max_execution_time, standartiškai yra nustatytas 30 (sekundžių). Tai reiškia, kad skriptui bus leista naudotis procesoriumi iki 30 sekundžių vieno paleidimo metu. Šis nustatymas yra naudingas hostingo paslaugų teikėjams, kadangi apsaugo nuo piktai nusiteikusių vartotojų, norinčių pakenkti, taip pat ir dedicated serveriams - apsisaugoti nuo kreivai parašytų savų ar trečios šalies skriptų. Dažnai šis nustatymas yra interpretuojamas klaidingai - “skriptas negali suktis ilgiau nei 30 sekundžių“. Iš tiesų, gali. Laikas skaičiuojamas tik tada, kai skriptas naudoja CPU, nors veikti skriptas gali valandų valandas. Pavyzdžiui:

while (true)
{
sleep(100);
}

Toks skriptas naudoja itin mažai CPU, todėl miegodamas gali veikti net ir ištisą mėnesį. Jeigu serveryje naudojate tik web puslapius, protinga apriboti šį nustatymą į kur kas mažesnę reikšmę, pvz. 5. Jei puslapis serveryje generuojamas ilgiau nei 1 sekundę, tai jau laikoma ilgai. Kuo mažesniu laiku jį apribosim, tuo daugiau laiko liks kitoms užduotims. Šį nustatymą galima keisti ir skripto išorėje, ir viduje, su set_time_limit() funkcija.

max_input_time yra skirtas nustatyti, kiek laiko skirti vartotojo įvedimui. Jis defaultu būna 60 sekundžių. Taip pat, kaip ir vykdymo nustatymas, jis įskaičiuoja tik tą laiką, kurį naudoja CPU savo skaičiavimams. Didelio failo uploado laukimas nepaveiks šio limito. Šis nustatymas skirtas apsisaugoti nuo daugiamačių masyvų perdavimo, kurie gali itin paveikti sistemos resursus. Nepaisant to, 60 sekundžių yra ryškiai per daug, joks skriptas neturėtų švaistyti tiek daug savo laiko vartotojo įvedimui apdirbti. Nustatymą siūloma apriboti iki 2-5 sek. Šis nustatymas gali būti keičiamas tik skripto išorėje, kadangi vartotojo įvedimas apdirbamas dar prieš skripto pradžią.

memory_limit - dar vienas nustatymas, apribojantis sistemos skiriamą atmintį. Šis nustatymas yra prieinamas tik tuo atveju, jei php sukompiliuotas su atminties ribojimo palaikymu. Lengvai tai patikrinsite, kadangi memory_get_usage funkcija prieinama tik jei atminties ribojimas yra :

if (function_exists(’memory_get_usage’)) echo ‘Ok!’;
else ‘Ne Ok!’

Atminties limitas yra defaultu nustatytas iki 8MB. Šis nustatymas dauguma atvejų yra tinkamas ir paprastai nereikia jo keisti. Sistemai pakenkti gali būti naudojami skriptai, pasiimantys didelę dalį atminties ir nueinantys miegoti. Pavyzdžiui:

$a = str_repeat(’a', 100000000);
ignore_user_abort(true);
sleep(1000000);

Šis skriptas bando nugriebti ~100MB atminties ir nueiti miegoti, ignoruodamas vartotojo veiksmus, ty. net jei uždaroma naršyklė, jis ir toliau būna vykdomas. memory_limit neišsprendžia problemos iki galo, kadangi su tokiu skriptu galima paleisti kelias jo instancijas, kurių kiekviena pasiims maksimalų atminties kiekį. Be abejo, tokie įvykiai negali praeiti nepastebėti sistemos administratorių, taigi problemą anksčiau ar vėliau reikia išspręsti. Kitiems atvejams, kai kenkia ne žmogus, o kreivai parašytas skriptas, arba pvz. siunčiamas didelis duomenų kiekis iš išorinio šaltinio, tai be abejo yra naudingas nustatymas.

default_socket_timeout - leidžia apriboti laiką, skirtą inicijuoti sujungimui. Defaultu ši reikšmė yra 60 sekundžių. Dažnai sistema, atidarydama socketą praleidžia daug laiko prisijungdama prie lėtų serverių, todėl kenkėjas gali efektyviai išnaudoti sistemos resursus, atidaręs keletą tokių prisijungimų. Kol sistema eikvos laiką beprasmiams sujungimams, neliks resursų tikrų vartotojų užklausoms. Reikia atminti, kad šis nustatymas galioja tik prisijungimo inicializavimo procesui ir neturi efekto skaitymui ir rašymui jau atidarytame sockete, taigi verta naudoti ir stream_set_timeout() jei reikia apsisaugoti nuo gaišimo laukiant skaitymo ar rašymo veiksmų. default_socket_timeout gali būti pakeistas bet kurioje vietoje, protinga jį būtų sumažinti iki 5-10 sekundžių.

URL includinimas

Viena iš php streams galimybių yra elgtis su išoriniais URL lygiai taip pat, kaip ir su vietiniais failais. Pavyzdžiui, fopen() gali būti taip pat sėkmingai panaudota nuskaityti “http://www.php.net”, kaip ir “/etc/passwd”. Tai sukelia nemažai saugumo spragų, kaip pvz. kodo injekcija per išorinį šaltinį, naudojant tokias funkcijas, kaip fopen(), file_get_contents(), readfile(), taip pat didelių duomenų arba lėtai veikiančių URL įkėlimas. Taipogi, gali būti sukuriamas amžinas ciklas, skriptui nuskaitant patį save. Kartais net web serverio perkrovimas neišgelbsti, kadangi keletas užklausų lieka buferyje ir jie vėl toliau sėkmingai ryja sistemos resursus. Serveris turi būti sustabdomas keletui sekundžių ir tada paleidžiamas iš naujo.
Į pagalbą ateina allow_url_fopen nustatymas, kurį nustačius į false, skriptas galės pasiekti išorinius šaltinius tik su curl arba socketais. Blogiausia, kad streamai suteikia priėjimą prie išorinių šaltinių ir tokioms funkcijoms, kaip require ar include. Jei tokių funkcijų parametruose pasitaiko vartotojo įvedamų duomenų, kenkėjas gali nesunkiai paleisti savo rašytus skriptus. Tai dar viena rimta priežastis išjungti defaultu įjungtą allow_url_fopen. Nepaisant visko, su fopen() atidarinėti išorinius URL yra pakankamai saugu (arba/ir reikalinga), ir dabartinėje versijoje (5.2) jau galima pasinaudoti nauju nustatymu allow_url_include, kuris išjungtas defaultu. Jis atskiria URL apdirbimo funkcionalumą, kadangi leidžia kontroliuoti ar leisti tik nuskaitymus, ar ir include/require. Abu šie nustatymai gali būti keičiami tik skripto išorėje, dėl saugumo sumetimų.

Funkcijų ir klasių draudimas

Jei galvojate, kad php turi daug nustatymų, pasidomėkite, kiek yra funkcijų Be abejo, visos funkcijos yra naudingos vienais ar kitais atvejais, tačiau kai kuriomis iš jų paslaugų teikėjai nenori leisti naudotis vartotojams. Tokios funkcijos, kaip exec() leidžia apeiti safe_mode ir open_basedir nustatymus, arba mail() - gali būti panaudota išsiųsti dideliems kiekiams spamo. Tam yra skirti nustatymai disable_functions ir disable_classes, kurioms galima pateikti kableliais atskirtą sąrašą draudžiamų funkcijų ar klasių. Skriptui, bandant naudoti uždraustą funkciją ar klasę bus grąžintas fatal error. Šis nustatymas, nors ir labai naudingas, deja, turi vieną apribojimą. Jis gali būti keičiamas tik php.ini faile, o tai reiškia, kad negalima vieniems vartotojams leisti, o kitiems apriboti tam tikrų funkcijų. Visiems bus vienodi draudimai. Po šio nustatymo keitimo taip pat būtina perkrauti web serverį.

Modulių dinaminis įkrovimas

enable_dl - leidžia pasirinkti ar leisti skriptui įkrauti modulį dinamiškai. Defaultu šis nustatymas įjungtas, todėl suteikia gan patogų dalyką - skripto metu galima įkrauti extensioną, tačiau tai yra didelė saugumo spraga. Nėra būdo žinoti, ką daro įkraunamas modulis, jis gali suteikti priėjimą vartotojui prie to, kas šiaip yra uždrausta ar atlikti bet kokias sistemos operacijas. Net ir be vartotojo piktų kėslų, modulis gali būti parašytas prastai, nekokybiškai, o tai taipogi gali paveikti visą sistemą. Rekomenduojama šį nustatymą išjungti php.ini arba virtual hosto lygmenyje.

Pabaiga

Sėkmės, būkite saugūs! Greitai pasirodys dar viena viso šio romano dalis

PHP standartinėje versijoje yra virš 500 INI nustatymų direktyvų. Šis skaičius gali išaugti, jei įdiegsite PECL ar kokių kitų išorinių modulių. Didžioji dalis nustatymų yra palikti veikti standartiškai (default), gali būti, kad jų judinti niekad ir neprireiks. Nenuostabu, kad turbūt nė vienas žmogus šių visų nustatymų negalėtų mintinai mokėti, tačiau yra keletas svarbesnių, susijusių su saugumu, į kuriuos verta atkreipti dėmesį. Pilnas INI nustatymų aprašymas yra čia.

PHP INI nustatymai taipogi turi keletą “nustatomumo lygių”. Kai kurie nustatymai, pavyzdžiui, yra tik “system” tipo, tai reiškia, kad jį galima pakeisti tik php.ini faile, taigi priėjimas prie jo yra draudžiamas ir skriptams, ir web serverio per-virtualaus hosto nustatymus, ir .htaccess failui. INI sąraše tokie nustatymai žymimi “PHP_INI_SYSTEM”.

Kai kurie nustatymai turi “PHP_INI_PERDIR” lygį. Tokiu atveju nustatymas gali būti keičiamas php.ini faile arba web serverio virtualaus hosto nustatymuose, arba jo .htaccess faile. Dažniausiai tokie nustatymai įtakoja pavyzdžiui, vartotojo įvedamus duomenis, o jie yra apdirbami dar prieš startuojant php skriptą, taigi skripto viduje, kad ir pirmoje eilutėje kreipimasis pakeisti nustatymą, neduotų jokio naudingo rezultato.

Didžioji nustatymų dalis patenka į “PHP_INI_ALL”, tai reiškia, kad nustatymas gali būti keičiamas bet kur, t.y. be jau minėtų būdų, dar papildomai ir pačiame skripte per ini_set() funkciją.

Register globals
Neverta apie juos daug aušinti burnos. Tiesiog reikia išjungti ir tiek Nuo 4.1 versijos išjungti default, tačiau dėl senų skriptų palaikomumo būna daug kur įjungti (ypač shared-hostinge). Šis nustatymas paliečia vartotojų įvedamus duomenis dar prieš vykdant skriptą, todėl jį apdirbti racionaliausia php.ini faile (register_globals=0), virtual host nustatymuose (php_admin_flag register_globals 0) arba .htaccess faile (php_flag register_globals 0). Patikrinti galime per phpinfo() funkciją arba ini_get(”register_globals”).

Magic Quotes
Panašiai gan nemenką žalą darantis nustatymas, kaip ir register globals. “magic_quotes_gpc” nustatymą verta išjungti ne tik dėl saugumo, bet ir dėl tam, kad skriptai būtų vykdomi greičiau - automatinis visų duomenų eskeipinimas taip pat atima resursų, be to, galbūt visai nebūtinas, juk ne visi įvedami duomenys yra naudojami SQL užklausose, be to, magic_quotes veikia ne itin korektiškai, ir vistiek gali palikti spragų saugume. Tai įvedimo apdirbimo nustatymas, taigi jis taip pat yra “PHP_INI_PERDIR” tipo. Dar vienas nustatymas “magic_quotes_runtime” yra panašus, tačiau priešingai nei “magic_quotes_gpc”, yra išjungtas defaultu. Bet kokiu atveju, verta patikrinti, jog abu jie būtų išjungti.

open_basedir
Labai naudingas dalykas shared-hostinge, tam, kad kiti vartotojai, vykdydami skriptus per web serverį, negalėtų landžioti po jūsų failus. Nustatymas keičiamas tik per php.ini failą arba apache virtual hostams. Kadangi atskiriems vartotojams reikia prieiti prie tam tikrų bendrų katalogų ir savo namų katalogo, tai nustatymo keitimas php.ini faile yra beprasmis, reikia diferencijuoti šį parametrą pagal vartotojus. Pvz. php_admin_value open_basedir “/tmp/:/home/user1/”. Reikia atminti, kad būtina katalogą iš abiejų pusių atskirti slashais, nes užrašymas “/home/user1″ leis priėjimą ir prie /home/user1, ir prie /home/user123 ir kitiems katalogams, kurių pradžia būtent tokia, o tai jau yra rimta saugumo spraga.

Safe Mode
Šio nustatymo idėja buvo labai kilni, tačiau pavadinimas gali būti apgaulingas. Safe mode režimas apriboja daug nustatymų susijusių su saugumu, tačiau visus juos galima reguliuoti atskirai ir daug lanksčiau (apie juos kitoje dalyje). Vienas iš svarbiausių dalykų, kad safe mode režime, kai skriptas kreipiasi į failą, tikrinamas skripto savininkas ir failo savininkas. Jei jie sutampa, tuomet operacija leidžiama. Tačiau tokiu būdu galima lengvai prarasti priėjimą prie failų, kurie sukuriami pačių skriptų. Be to, šį apribojimą galima lengvai apeiti su daugeliu funkcijų, pvz. copy(). Nors safe_mode įjungimas ir nekenkia tiesiogiai, tačiau jis sukūria papildomo apkrovimo serveriui, tikrinant failo UID, todėl rekomenduojama išjungti ir protingai suderinti kitus saugumo nustatymus, taip pat atskiriant vartotojus į virtualius hostus bei naudojant gudrias priėjimo teises (chmod).

Expose PHP
expose_php nustatymas įjungtas standartiškai, tačiau nauda iš jo menka, o žala didelė. Įjungimas reiškia, kad kiekvienos užklausos metu siunčiama informacija apie PHP versiją, naudojama serveryje. O tai be abejo naudinga hackeriams, ieškantiems pažeidžiamų senesnių versijų, be to tai yra ir papildomi nereikalingi duomenys, naudojantys saito pralaidumą. Nebūtina visam pasauliui žinoti kokia kalba parašytas tinklapis. Statistikos rinkimui užtenka panaudoti kad ir header(”X-Powered-By: PHP”); kuris nerodo PHP versijos. expose_php nustatymas reguliuojamas tik php.ini faile.

Display Errors
display_errors būna įjungtas default, o tai reiškia, kad visos klaidos bus išvedamos tiesiai į browserį. Be abejo, tokia informacija naudinga norintiems pakenkti. Geriausias variantas yra uždrausti lankytojams matyti klaidas, tačiau leisti programuotojui prie jų prieiti. Klaidų nustatymai gali būti keičiami visuose lygiuose (pačiame PHP skripte - taip pat):

error_reporting(E_ALL | E_STRICT);
ini_set(’display_errors’, 0);
ini_set(’log_errors’, 1);
ini_set(’error_log’, ‘/var/home/user/logs/php.log’);

Pabaiga
Pirmos dalies pabaiga

1. CRUD (Create Read Update Delete), CRUD saugumas, Kaip kiekvieną modelį galima supaprastinti iki CRUD (siūlytojas, berods, araki)
2. Struktūrinai šablonai, praktinis jų panaudojimas (Design patterns) (araki)
3. Kodėl Yahoo ant PHP? PHP in enterprise (Lakūnas?)
4. Ruby on Rails, kaip viską padaryti per 15min? (Yozaz?)
5. Paymentai (apmokėjimai) naudojant PHP (teibaz?)
6. Zend Core for WINDOWS (saint)
7. Migracijos gidas iš PHP į ASP.NET ir atvirkščiai (palete?)
8. PHP brandingas (įvaizdis) (araki?)
9. Naujasis Filter extensionas, duomenų filtravimas ir eskeipinimas (medutis)
10. PHP ateitis, PHP6, namespaces, unikodas, etc. (medutis)
11. Django, SOA! (midgrad)
12. Apkrovimo mažinimas ir dalinimas, scaling, mySQL5 navarotai (index merge, innodb), mod_proxy_balancer, (midgrad)

Neišsigąskite, skliausteliuose nurodyti siūlytojai (nebūtinai skaitovai), entuziastų skaitovų, beje, neatsirado, tačiau galvoju, kad tai nebus didelė bėda O dabar laukiu kokių nors komentarų, pasisakymų, galbūt konkrečių idėjų ir pasiūlymų, skaitovai taip pat welcome. Palete jau lyg ir beveik pasižadėjo, jog suorganizuos vietą (viešbučio konferencijų salė arba koks nors univeras).

Beje, jau yra naujasis php|arch gruodžio numeris, ten pat, kur ir visad. Ramių švenčių ir gerų dovanų!

Reikalingas web (PHP/MySQL) programuotojas.
Darbo pobūdis: freelanceriniai projektai.
Techninio dizainerio gabumai būtų privalumas.
Paskutinio darbo URL arba CV siųsk į mikauzeris@gmail.com

Pervertęs šį numerį pagalvojau apie mūsų PHP bendruomenės (ir Lietuvoje, ir pasaulyje) tolerantiškumą. Padariau išvadą, kad PHP’istai yra labai tolerantiški Nustebino tai, jog žurnale yra ir straipsnis pavadinimu “learning from Ruby on Rails”, labai smagu, jog programuotojai sugeba žvelgti plačiau ir mokytis ne tik virdami “savo sultyse”, bet ir pažvelgdami į kitas (galbūt net šiek tiek konkurentines) kalbas. Kitas pavyzdys: pernai įvykusioje PHP konferencijoje taipogi turėjo būti pranešimas apie “migravimą iš PHP į ASP.NET”, deja autorius negalėjo (ar pabijojo) atvykti. Nors buvo pasisakymų, jog toks pranešimas tik padarytų gėdą konferencijai, buvo ir manančių, jog paklausyti apie tai būtų gan įdomu, pasimokyti kažko iš skirtingos technologijos. Niekas nebūtų priešinęsis tam, kad jis būtų įvykęs, o galbūt ir pavadinimas visai neatspindi galimos naudos. Galbūt dar ir šiemet įvyksianti (tokie planai prie alaus bokalų buvo rezgami :)) konferencija taip pat be pranešimų apie kitas kalbas ar “migravimus” gali neapsieiti. Keletas PHP programuotojų savo bloguose taip pat nevengia brūkštelti apie ruby on rails, juose yra ir pagyrimų, ir kritikos (objektyvios!).

Kartais tenka išgirsti java ar .net programuotojų pašiepiančių, ar net įžeidžiančių pasisakymų apie php. Galbūt tolerancija ir PHP kūrėjų plačios pažiūros leidžia šiai kalbai išsilaikyti viena iš lyderių?

Kadangi deja, šiandien vis dar dirbame ir su senosiomis PHP4 versijomis, ir su skirtingų konfigūracijų PHP, susimislijau būdą kaip gražiai ir universaliai apeiti magic_quotes. Manau ir Jums visai pravers, jei jau skaitote šį blogą. Trumpi komentarai: į tai, kas vadinama “request” mano manymu neturi patekti COOKIES, todėl naudojame tik POST ir GET. Su COOKIES ir FILES elkitės kaip norite, kolkas mano klasėj jie neapdirbti Paprastai prasukti foreach visam masyvui negaliu, nes kartais tenka perdavinėt ir dvimačius ar net trimačius masyvus, o array_walk_recursive, kaip žinia yra rekursinė funkcija, kuri su tam tikrais vartotojo įsikišimais gali ir užlaužti serverį, jei naudojama netinkamai. Pvz. jeigu naudosime array_walk_recursive ir “hakeris” sugalvos papost’inti serveriui labai ilgamatį masyvą, pvz. foo[][][][][]…, PHP kintamųjų stekui baigsis atmintis ir viskas gali baigtis crashu. Masyvo dimensiją galite lengvai pasikoreguoti pakeitę $array_level.

Taigi, galite peržvelgti kaip atrodo klasė čia, o parsisiųsti patį sourcą čia. Ačiū už dėmesį.

Mod failą galite rasti čia. Visa idėja trumpai: turiu aš tokį forumėlį, kuris, nors ir neturi daug vartotojų, tačiau yra aktyvus, be kita ko, pastoviai į jį lenda visokio plauko spameriai ir botai. Nepadėjo nei forumo sugriežtinimas - žinutes gali rašyti tik registruoti vartotojai, registracijos metu turi įvesti paveikslėlyje esantį kodą (captcha), o taip pat dar ir patvirtinti emailu gautą nuorodą. Vistiek, pasirodo, spameriai gan rimtai nusprendė susidoroti su vienu iš populiariausių php forumo sistemų. Šio modo idėja - registracijos metu užduoti suktą klausimą, kurio spameris nesupras, tuo labiau nežinos į jį atsakymo. Tikiuosi, kad jam nebus verta gaišti laiko googlinant ar bandant perprasti lietuvių kalbą ir jos politiką Žinoma, modas ganėtinai lanksčiai ir patogiai leis pakeisti inteligentiškąjį klausimą bei atsakymą bet kuriuo metu.

Tikiuosi, kad bus pravartus ne tik man, ir be abejo, lauksiu atsiliepimų.

Taipogi atrodo šaunus extension’as yra XMLWriter, teks užnaudot, ir beje, ar žinojot, kad PHP naudojant sesijas, sesijos id cookiui suteikiamas atgalinės datos expiration time - 1981-11-19 08:52 ? Ogi tai PHP sesijų extensiono kūrėjo gimimo data.

Email injekcija atsirado palyginti neseniai, prieš keletą metų. Tiesą sakant, tai tėra tik dar vienas aklo pasitikėjimo vartotojo įvedimu, pavyzdys. Jei Jūs naudojatės mail() funkcija, kurios argumentais leidžiate manipuliuoti vartotojams, jie gali siųsti laiškus per Jūsų serverį. Nieko nuostabaus.
Šiuo metu egzistuoja nemažai būdų kaip pasinaudoti email injekcija PHP skriptuose. Šio tipo pažeidimai yra tikras lobis el.pašto spameriams. Pagrindinė problema, dėlko el.pašto injekcija yra populiari, yra ta, jog programuotojai nesupranta duomenų filtravimo, prieš juos paduodant email funkcijai, svarbos.

Mail() funkcija suteikia ganėtinai neišdirbtą sąsąją siųsti el. paštui. Kaip ir dauguma PHP funkcijų, ši yra labai lanksti - leidžia siųsti beveik bet kokio tipo ir formato laišką.
Mail() funkcijos naudojimas yra labai paprastas, todėl nepatyrusiam programuotojui saugumo spragos dažniausiai nesimato. Pats paprasčiausias būdas išsiųsti laišką:

mail('to@pavyzdys.lt', 'Antraštė', 'Žinutė');
?>

Šis pavyzdys iškart tampa el.pašto injekcija, kai tik pirmąjį argumentą pakeičiame vartotojo įvedamu tekstu:

mail($_POST['email'], 'Antraštė', 'Žinutė');
?>

Tai panašu į bet kokią kitą injekciją, tačiau konkekstas skiriasi. Jei įvesime savo pašto adresą, gausime laišką panašų į šį (supaprastintas vaizdas):

Antraštės “kam” (To) reikšmė yra įvedama vartotojo, taigi kas nors, norėdamas išsiųsti spam žinutę iš Jūsų serverio, paprasčiausiai įves sąrašą adresų, atskirtų kableliais:

Galime įsivaizduoti, jog bus atlikta tokia komanda:

Kiekvienas iš šių adresų gaus laišką, kadangi To antraštė suteikia galimybę siųsti keliems adresatams, atskirtiems kableliais. Taip pat klaidingai galvojama, jog ši problema egzistuoja tik leidžiant vartotojui operuoti pirmuoju argumentu, o nieko blogo nenutiks, jei To reikšmė bus statinė. Daug didesnių bėdų bus, jei bent dalis vartotojo įvedimo bus naudojama ketvirtajame argumente.

Headerių injekcija

Dažnai mail funkcija naudojama siųsti kontaktams ar atsiliepimams tiesiai iš puslapyje esančios formos. Jei nenurodome specialių headerių, siuntėjo adresas nustatomas web serverio. Dažniausiai formoje vartotojas nurodo savo el. pašto adresą, taigi jei norime imituoti, jog laiškas buvo siųstas būtent iš įvesto adreso, turime nurodyti headerius “From” ketvirtajame argumente.

Aišku, tai, kad galima nurodyti laiško antraštes, mums suteikia papildomo lankstumo, tačiau čia taip pat slypi ir dideli pavojai. Įsivaizduokime tokia komandą:

Ši komanda veiks, taip kaip ir tikitės: laiškas bus išsiųstas, o formoje įvestas email bus nurodytas kaip siuntėjo. Deja, dabar vartotojas turi visišką laisvę operuoti su antraštėmis. Vartotojas, turintis piktų kėslų, į formos ‘email’ laukelį įves:

Be abejo, šis bandymas pakenkti bus pastebėtas, kadangi to@pavyzdys.lt gaus laišką:

Laiškas bus išsiųstas abiems adresatams, tačiau, kad ši saugumo spranga nebūtų pastebėta, blogiukai pasinaudos BCC antrašte ir galės nepastebimai naudotis serveriu ilgą laiką. Įvedame:

Kaip žinia, BCC antraštė nėra rodoma el. laiške, todėl to@pavyzdys.lt matys laišką, kuris tarsi buvo siųstas tik jam. Deja, pasirodys, kad neaišku kiek dar žmonių gavo tą patį laišką, todėl greitai jūsų skriptas taps spamerių numylėtiniu.

Saugumo tikrinimas

Norėdami patikrinti savo skriptus, galite įvesti daugiau nei vieną eilutę į formos įvedimo laukelį. Pavyzdžiui:

Tikri spameriai naudojasi tam tikrais įrankiais, kurie automatiškai prisijungia prie web serverio ir papostina url-užkoduotus tekstus. Pavyzdžiui:

Web serveriui POST kintamieji paduodami panašiai kaip ir GET, šiuo atveju buvo paimti entities naujai eilutei, kuri pažymėta kaip %0D%0A. Šis pavyzdys yra labai paprastas, dažnai būna vykdomos atakos siųsti HTML laiškus, prisegtus failus ir pan. Jei spameriui leidžiama operuoti funkcijos argumentais, jis gali padaryti bet ką, ką leidžia mail() funkcija.

Kaip apsisaugoti?

Tam tereikia filtruoti vartotojo įvedamus duomenis. Žinoma, uždrausti įvedinėti tarpus ar eilutės perkėlimus pačiame žinutės tekste ar jos pavadinime nereikia. Kai kuriuos email adresus išfiltruoti taip pat sudėtinga dėl jo ne itin griežtos specifikacijos. Atpažinti įvedamiems el. pašto adresams gali padėti reguliariosios išraiškos (regexp), taip išvengiant email injekcijos atakos.

Taip pat greitas ir patogus būdas patikrinti ar kintamajame nėra perkėlimų ar naujų eilučių:

Funkcija checkdnsrr() taip pat gali padėti, jei su regexp išraiška galime išgauti domeno vardą. Tuomet su šia funkcija patikriname ar tikrai toks domenas egzistuoja. Deja, checkdnsrr() neveikia windows aplinkoje.

Paprasta apsauga nuo email injekcijų leidžia išvengti atakų, ten kur mažiausiai tikitės - dažniausiai pasitaikančiose nedidelėse kontaktų ar atsiliepimų formose. Šios formelės ypač populiarios mūsuose, taigi verta į tai atkreipti dėmesį.