mysql backup jól’

Bizonyára akik több oldalt kiszolgáló szervert üzemeltetnek használnak valamilyen jobb/rosszabb megoldást adatbázis napi/heti biztonsági mentésére.

Nos, az én hegesztésem alább található.
Amiben érdekesebb, hogy a mysqldump nem egy file-ba kakilja bele az adatbázis szerver összes adatbázisát, hanem külön szedi őket és külön tárolja sql file-okba – így valamelyik oldalnál egy DB fail utáni helyreállítás talán kevesebb huzavonával fog zajlani.


mkdir $(date +%Y_%m_%d)
for line in $(mysql -u backup -AN -e “show databases”);
do
mysqldump -u backup $line > $(date +%Y_%m_%d)/$line.sql ;
done

Így programozz a webre

A korábbi Weboldalak biztonsága postom után kedvet kaptam a sorozatot folytatni. Mit folytatni – az észt osztani, kemény 4-5 éves php programozói tapasztalattal. 🙂

Tudom, sokféle módszer, program és vélemény létezik – én a saját történetemet mesélem el most itt. Nektek. Hogy könnyebb legyen.

 

Hogyan kezdjünk neki?

Tegyük fel, hogy Windows 7/8-at használsz és nincsen külön szervered még, amire fejlesztesz.

Az alábbiakra lesz szükséged a kezdéshez (később igény esetén készül még ezekről leírás):

  • NetBeans php (IDE, azaz fejlesztőkörnyezet)
  • EasyPHP devserver (szerverprogram, azaz futtatókörnyezet és mysql)
  • Ha igényes vagy github regisztráció, vagy egyéb verziókövető rendszer használata
  • Git Extensions (verziókövető kliens)
  • File olvasgatásra Notepad++
  • Egy számítógép legalább 4 giga rammal és legalább valami kétmagos processzorral (a hatékony munka érdekében)

Amit ajánlok elsajátításra:

  • Bootstrap 3 (gui framework, tehát féligmeddig előre definiált css)
  • Egy php framework (például Codeigniter, Yii, Zend) – lényeg, hogy ismerje az MVC szemléletmódot
  • jQuery 2 és az arra épülő validate.js, blockUI.js, lightbox, stb kliensoldali könyvtárak
  • Egy másik programnyelvet gyakorlásként (mondjuk c#  .net-et, c-t, vagy java-t)

Ami mindenképp kell ahhoz, hogy boldogulj:

  • Informatikai érdeklődés – tudjuk, hogy a programozás manapság már sztárszakma, de tényleg csak akkor vedd komolyan, ha érzel rá elhivatottságot
  • Angol nyelv legalább alap szinten
  • OOP szemléletmód
  • Az MVC-t csak meg kell értened és (nem, nem csak ennyi) idővel ráérzel a dolgokra
  • Elszántság, ne várd azt, hogy majd más megoldja a problémádat – próbálj magad rájönni egy-egy hibára
  • Sok kávé 🙂

És ha már konyítasz ezekhez próbálkozz be cégeknél (akár diákként is), mert irodában, munkatársak között, nyomás alatt az otthoni környezethez képest nagyságrendekkel hatékonyabban tudsz tanulni. Tehát ne várd azt, hogy majd otthon a gép előtt ülve beléd száll minden tudás, ami ahhoz kell, hogy senior legyél… 🙂

 

Ami javadra válik az életben:

Amire számíthatsz:

  • A főnököd valószínűleg szépen fog veled beszélni és a tenyerén fog hordozni, hogy jó munkát végezz (illetve ha jó munkát végzel)
  • Arra is van esélyed, hogy a munkatársaid intelligens, normális emberek lesznek, sőt mi több lesz néhány csendes zseni is, akire érdemes figyelned
  • 120-160 ezer ftos nettó junior kereset (attól függ, hogy vidéken, vagy a fővárosban próbálkozol)
  • Idővel számos álláslehetőség – igen, Magyarország a 10 millió webfejlesztő országa, de a jó szakemberből mindig hiány van
  • Egy 20 éves esze jobban vág, mint egy 40 évesé. 35-40 éves korodig mindenképpen érj el egy magasabb pozíciót, ahol már nem a sebességedre, hanem a tapasztalatodra van szükség!

Weboldalak biztonsága

Mivel egy elég fontos témakör (és junior állásinterjún szeretik kérdezni is) íme összegezve néhány biztonsági javaslat (a teljesség igénye nélkül):


Bemenetek vizsgálata

Ha számot vársz akkor kasztold, ha szöveget akkor regex-el vizsgáld, stb

Tehát pl szám esetén:

$model_obj->where("id", "=", (int)$id);


SQL injection védelem

Vizsgáld a bemenetet és escape-eld a stringeket

mysql_escape_string($szoveg)


Vizsgálj mindig jogosultságot

Ne sajnáld a processzoridőt, minden lekérdezésnél vizsgáld, hogy megfelelő jogokkal rendelkezik-e a látogató a rendszeredben


Éles oldalon display_error = off

Ez üzemeltetés – de azon túl, hogy nem esztétikus még hackerkedő hangulatúaknak is kedvet adhatsz a mókázáshoz, ha látják a hibaüzeneteket


Használj hosszú jelszavakat

Nem éppen php dolog, de előfordul, hogy ftp-n vagy bárhogy belemódosítanak a saját php file-jaidba, ha rájönnek a jelszavaidra.


File post-kor vizsgáld a file formátumát

És mindig ellenőrizd, hogy a szerver .tmp-re varázsolja-e át a nevét amikor azt a temp mappába rakja, nehogy egy illegális php feltöltésekor futtatni tudja azt

 

Használj htmlspecialchars-t vagy strip_tags-et

olyan helyre, ahol a felhasználó korábbi szövege másoknak megjelenik. Ezzel megakadályozod, hogy <script> tag-et (vagy rosszabb esetben <?-t) használhasson.

 

Külön user-ként fuss!

Ez inkább már üzemeltetés – de figyelj arra, hogy egy weboldal egy külön user nevében fusson a szerveren (és az még véletlenül se root legyen), hogy ha még azt az egy oldalt fel is nyomják, ne férjenek hozzá más oldalhoz, vagy az egész filerendszerhez.

 

Sózd a jelszavakat és még kliensoldalon titkosítsd, vagy használj https-t

Igen, lehallgathatók az oldalak kommunikációi, ha hagyományos http protokollt használ az oldalad. És adatbázisba se plain text-be mentsd el őket…! 🙂

 

Különítsd el a meghívható és a futthatható file-okat

Figyeld, hogy a file hogyan lett megnyitva. Vizsgáld pl a config.php-ban, hogy ha a file közvetlenül lett meghívva akkor azonnal exiteljen ki.
pl definiálsz a futtatható elejére egy START makrót és a include-olt file-ok elején vizsgálod:

!defined(‘START’) ? exit(‘Access Denied’) : NULL;

 

Szükség esetén titkosítsd a php kódodat is és éles oldalad forrását ne add tovább

Így még feltörés esetén sem tudnak belemódosítani úgy, hogy észrevétlenek maradjanak. Ja és visszafejteni se tudják.

 

Figyeld a felhasználók által feltöltött anyagok valódiságát

Ha a felhasználónak megengeded, hogy pl saját képet illesszen be az oldaladra akkor beillesztéskor vizsgáld a kép url header-ét. Olyat is láttam már, hogy egy olyan url-t raktak be, amit átengedett a kép url-t validáló, de aztán a link 301-et dobott és átirányított a logout.php-ra 
Ekkor az történt, hogy mivel a böngésző meg akarta jeleníteni a fake image-t megjelenítés helyett mindig vissza kijelentkeztette a user-t az oldalról…

 

N+1

Ha javítasz, debugolsz, fejlesztesz ne éles rendszeren csináld. Töltsd le localhostra, vagy ha nagyon kemény vagy tartsd fenn a szerveren, de készítsd róla egy másolatot egy almappába és azon ügyködj. Senkinek sem jó az, hogy miközben fejlesztesz addig vacakol az oldal…