ugrás a tartalomhoz

PHP és biztonság ( :-) )

H.Z. v2 · 2011. Jún. 9. (Cs), 19.26
Tudom, antagonisztikus ellentét, de... :-)
Azon gondolkodtam, hogy ha végre eljutok odáig, hogy összerakjak egy működő lapot, akkor az nem egyetlen file-ból fog állni. Ezen file-ok egy része (elméletileg) tartalmazhat olyan kódot, aminek a végrehajtása jogosultsághoz kötött.
Ilyenkor mi a korrekt módszer?
Minden egyes file elejére tegyem be az ellenőrzést, akkor is, ha az őt hívó oldal egyébként elvégzi? Kicsit túlzásnak érzem.
Mennyire gázos/hibás/stb. az az elképzelés, hogy a site gyökérkönyvtárában lévő valamennyi lap végez ellenőrzést, az alkönyvtárakban (mondjuk ilyenek, mint lib/, classes/ stb.) lévők nem, viszont... a .htaccess-be teszek egy RewriteRule-t, amivel ezen könyvtárakba irányuló kéréseket átirányítom a főoldalra, hibára stb.
Az include/require nem megy át a rewrite-on, tehát működőképes marad a program, viszont ha valaki bele akar nézni ezekbe a file-okba/futtatni próbálja őket, akkor kapásból átirányítom egy semleges oldalra.
‹ cookie letárolás Törlés gomb létrehozása ›
 ■
1

Függvények

Poetro · 2011. Jún. 9. (Cs), 19.39
Minden fájlban, az index.php-t kivéve csak osztályok illetve függvények legyenek, és akkor nincs semmi, amihez hozzá tudna férni. Ez alól kivételt képezhetnek a konfigurációs fájlok, amik ugye nem írnak ki semmit, illetve a template fájlok, amik ugye adatok hiányában nem fognak értelmezhető eredményt produkálni.
2

Nem akarok kötekedni, de...

H.Z. v2 · 2011. Jún. 9. (Cs), 20.41
Nem akarok kötekedni, de... mondjuk ellenpéldának ott a phpBB ;-)
Igaz, ott minden lap ellenőriz, amibe belenéztem.
Mondjuk, amíg saját szerveren fut a cuccom, addig nincs gond, mert kirakom az egyéb file-okat oda, ahol a webről nem lehet közvetlenül elérni őket. Gond az ingyenes tárhelyeken lehet belőle, mert ott meg van kötve az ember keze, ami a könyvtárstruktúra kialakítását illeti.

Végülis ez sem rossz módszer:

if (!defined('IN_PHPBB'))
{
        exit;
}
3

Ellenpéldának?

Poetro · 2011. Jún. 9. (Cs), 20.56
Mire ellenpélda a phpBB? A biztonságos programra, vagy arra, hogy nem kell ellenőrzés a fájl elején. Minden attól függ, hogy hogyan működik az alkalmazásunk, és az abban levő logikát hogyan strukturáltuk.
4

A "csak az index.php-ben

H.Z. v2 · 2011. Jún. 9. (Cs), 21.02
A "csak az index.php-ben legyen működő kód, a többi csak osztály definíció"-ra. :-)
5

és biztonságos alkalmazásra...

thgab · 2011. Jún. 10. (P), 08.14
http://goo.gl/vCbWu
6

Ez mi? (azon túl, hogy egy

H.Z. v2 · 2011. Jún. 10. (P), 08.44
Ez mi? (azon túl, hogy egy URL rövidítő, ami nálam tiltva van, ergo nem tudom megnézni a lapot)
7

Asszem erre mondják...

vbence · 2011. Jún. 10. (P), 08.55
"Egyéni szoc. probléma" :)
8

Nem baj. Ő koptatja a

H.Z. v2 · 2011. Jún. 10. (P), 09.08
Nem baj. Ő koptatja a billentyűzetét, vesztegeti az idejét, én meg nem tudok mit kezdeni vele, mert honnan tudjam, hogy szakmai lapra, pornóoldalra, netán vírusfarmra irányít? ;-)
(annyit kiszedtem belőle, hogy valahova az exploit-db.com-ra vinne, de tovább nem mazsolázgattam - nem túl jó a belém programozott HTML/JS interpreter. :-) )
9

PhpBB exploitok

blacksonic · 2011. Jún. 10. (P), 09.45
pedig érdemes ránézni, ha már a PhpBB-t hoztad "ellenpéldának", hogy lásd mennyire hemzseg a banális exploitoktól :)
10

Emlékeim szerint a többi

H.Z. v2 · 2011. Jún. 10. (P), 10.06
Emlékeim szerint a többi tartalomkezelő (pl. drupal rémlik a régmúltból, de könnyen lehet, hogy rosszul) sem úgy épül fel, hogy egyetlen index.php, a többiben csak függvény és osztálydefiníciók vannak. Ha más nem, html kódok vannak sokfelé. Ezeket szeretném elrejteni a kíváncsiskodók elől.

Tényleges biztonság más téma. PHP esetében nem is számítok ilyesmire igazán. :-)
11

Front controller

Ifju · 2011. Jún. 10. (P), 11.13
Ha más nem, html kódok vannak sokfelé. Ezeket szeretném elrejteni a kíváncsiskodók elől.

Éppen ezért érdemes egyetlen index.php-t használni, és minden mást a docrooton kívül tartani. Projekt mérettől és bonyolultságtól függően lehet választani módszerek közt: nem mindenre a kalapács a megfelelő eszköz.

PHP esetében is lehetséges biztonságosan programozni, csak megfelelő tudás szükséges hozzá.
12

Rosszul emlékszel

Poetro · 2011. Jún. 10. (P), 11.24
A Drupal-ban az index.php-n a konfigurációs fájlon (settings.php) és a template fájlokon (.tpl.php) kívül minden fájlban csak függvények vannak, 7.x-től kezdve pedig már osztályok is.
14

Eszerint mégsem. A

H.Z. v2 · 2011. Jún. 10. (P), 11.46
Eszerint mégsem.
A template-ekre emlékez(het)tem.
Jó, nem történik semmi, ha ezeket a template-eket direktben kérem le, de attól még ott vannak és elérhetőek, ha valaki tudja a pontos nevüket. (feltéve, hogy jó helyen néztem)
13

Több belépési pont

blacksonic · 2011. Jún. 10. (P), 11.38
Ha több belépési pont van egy alkalmazásban, akkor a bemeneti értékeket minden belépési pontnál ellenőrizni kell -> több helyen ellenőrzöl, így megnöveled az esélyét h biztonsági rés

más kérdés, hogy ha sokan vagy nagyok csinálnak valamit egyféleképpen az nem feltétlenül jó még attól :)
21

Tárgyi tévedés

fberci · 2011. Jún. 10. (P), 21.01
Ha jobban megnézted volna a listát, akkor láthattad volna, hogy a phpBB-ben magában már évek óta nem volt komoly biztonsági hiba. Az itt szereplő exploitok vagy kiegészítőkre vonatkoznak vagy egy ősrégi verzióra. A 3-as verzión még a kiadása előtt a SektionEins végzett el egy biztonsági auditot (ők vizsgálják elvileg a symfony2-t is, bár ez nem tudom most hogy áll), és azóta (immár majdnem négy éve) nem is volt kihasználható sebezhetőség. Az pedig, hogy boldog-boldogtalan különböző megkérdőjelezhető minőségű módosításokat végez a szoftveren nem egyértelműen a fejlesztők hibája.

Természetesen ez a kód felépítését nem minősíti, számos jobb struktúra létezik, és a kérdezőnek is valószínűleg ajánlatosabb egy másik mintát követni, de így is lehet biztonságos programot létrehozni, és a phpBB3 egy jó példa erre.
22

Köszi a kiegészítést

H.Z. v2 · 2011. Jún. 10. (P), 21.41
A linket ugyan nem követtem (továbbra sem bízom az URL rövidítő szolgáltatásokban :-) ), de a feltételezett céljára, az exploit-db.com-ra elmentem és rákerestem a phpbb-re. Az eredmény kb. egyezik azzal, amit írtál.
15

ha teheted, akkor rakj ki az

Tyrael · 2011. Jún. 10. (P), 12.22
ha teheted, akkor rakj ki az index.php-n kivul minden mas forrasfajlt a DocumentRoot-on kivulre.
ha nem teheted meg, akkor erdemes lehet valami a phpBB-bol linkelt megoldashoz hasonlot belerakni minden fajlba, de ahogy tobben is mar leirtak, jo esetben a template-eken es az index.php-n kivul minden mas php fajlod csak fuggveny/osztalydefiniciokat tartalmaz, emiatt az onmagukban torteno futtatasuk nem igazan okozhat barmifele kodfutast.

Tyrael
16

Köszi, ebben igazatok van,

H.Z. v2 · 2011. Jún. 10. (P), 12.31
Köszi, ebben igazatok van, de...
Rögtön a 2.-ban írtam:
Mondjuk, amíg saját szerveren fut a cuccom, addig nincs gond, mert kirakom az egyéb file-okat oda, ahol a webről nem lehet közvetlenül elérni őket. Gond az ingyenes tárhelyeken lehet belőle, mert ott meg van kötve az ember keze, ami a könyvtárstruktúra kialakítását illeti.


Már nem tudom, hogy mely szervereken, de több helyen is láttam olyat, hogy csak a documentroot-hoz volt hozzáférésem ftp-n keresztül. (szerintem az egyik az fw.hu lehetett, de nem biztos. Elég sokat megnéztem, de még mindig nincs olyan, ami használhatónak tűnik)

Egyelőre nehezen tudom elképzelni ezt a csak definíciókra épülő szerkezetet, ha kezelhető méretű index.php-t akarok, de lehet, hogy csak azért, mert nem rágtam át magam a dolgon, kellő alapossággal...

-----
sajnos így, hogy max. napi félórát van kedvem foglalkozni a témával, elég lassan mennek a dolgok... :(
17

Drupal index.php

Poetro · 2011. Jún. 10. (P), 13.25
Hát a Drupal index.php-ja eléggé kezelhető méretű:
<?php
define('DRUPAL_ROOT', getcwd());

require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
menu_execute_active_handler(); 
?>
20

:-) Mondjuk ebben van

H.Z. v2 · 2011. Jún. 10. (P), 16.24
:-)
Mondjuk ebben van valami.
:-)

Egyébként egy szóval sem mondtam, hogy lehetetlennek tartom, csak azt, hogy én nem tudom magam elé képzelni a kivitelezését.
Persze hülyeség, mert meg is nézhettem volna valahol (pl. a drupal forrást)

De ha ez vigasztal, elsőre azt sem igazán tudtam összehozni magamban, hogy a PHP-t hogy lehet összepároztatni az objektum orientált programozással, mert objektumok kapcsán nekem egyre valami alkalmazásszerver-féleség járt az eszemben. Kicsit nehezen tudtam megemészteni, hogy egy-egy objektum életciklusa=egy lap letöltésével.
18

Bocs, ha hülyeséget beszélek,de...

Hellhammer · 2011. Jún. 10. (P), 14.04
csak mert van konkrét tapasztalatom hasonló problémában pont az fw.hu-n.
ftp-n keresztül belépve van egy public_html nevű mappád, melyben elhelyezel egy darab fájlt index./html/,/php/,/valami/ névvel és egy darab index_elemei nevű mappát; csak ebben az esetben működik..

Az oldal egyébként egy hallgatótársaimmal létrehozott cucc volt, fájlokat osztottunk meg, infókat adtunk egymásnak, stb. Csak egy idő után megjelent rengeteg olyan külső felhasználó, aki nem vett részt a kommunikációban, csak elmentette könyvjelzőnek a fileletöltes.php fájl elérési útját külön, és azt nézegette, hogy van-e új fájl.. nos, mivel nem azért hoztuk létre az oldalt, hogy mi dolgozzunk, más meg még arra se vegye a fáradtságot, hogy elolvassa a kezdőlapon közzétett megjegyzéseket, kérdéseket, azt találtuk ki, hogy:

/kicsit szakbarbár megoldás talán, csak azért írom le, hogy ha nem is 100%os, de használható példát mutassak talán, ingyen tárhelyes biztonsági ötletre:/

Az index.php fájl abból állt, hogy két div, egy menüs fejléc és egy div id=tartalom.
A menü nem vitt el sehová a index.php-ról, a gombok szerepe az volt, hogy a kezdőlapon a tartalom div-be más-más dolgokat include-oljon be: példa:
A kezdőlap tfh annyi, hogy behívja a hirek.php-t.
ugye ez jelen esetben úgy nézne ki, hogy:

<?php
include("index_elemei/hirek.php");
?>

Mivel a hírek megjelenítését több helyen, többféleképpen is megtettük, ezért értelem szerint, -Poetro megjegyzéseihez hasonló módon- nem egy darab vaskos hirek.php fájl volt a szerveren, hanem a benne esetegesen használt függvények, stb több helyen használt kódrészletek külön-külön fájlokban foglaltak helyet;
Folytatva a példa szerinti struktúrát: volt egy mappa, hogy: index_elemei/hirek_osszetevoi/
És mivel a hirek.php az index.php részeként volt hivatott működni, ezért az összetevőinek használata úgy történt, hogy: a hirek.php fájl kódjában úgy írtuk az elérési utakat:
/persze nem feltétlenül include-dal, de: /

<?php
include("index_elemei/hirek_osszetevoi/osszetevo1.php");
?>
Ez alapján, ha az ember nem úgy állt neki böngészni, hogy http://felhasznalonev.fw.hu
hanem, hogy http://www.felhasznalonev.fw.hu/index_elemei/hirek.php , nos, akkor nem jelenítette meg a kívánt fájl, mivel:
Amikor az index.php részeként include()-dal hívjuk, akkor a helyes megjelenítést kaptuk; az összetevő a felhasznalonev.fw.hu/index_elemei/hirek_osszetevoi/osszetevo1.php útvonalról érkezett.
Megpróbálva külön megnyitni pedig, a felhasznalonev.fw.hu/index_elemei/index_elemei/hirek_osszetevoi/osszetevo1.php elérési utat próbálta végrehajtani, ami ugye rossz.

Bocs, ha nagyonnagy hülyeséget írtam, tudom, hogy ez nem feltétlenül egy tökprofi megoldás, csak a kommentben olvasott problémára próbáltam egy használható, pár nem feltétlenül precíz alternatívát mondani..
19

Azért is írtam feltételes

H.Z. v2 · 2011. Jún. 10. (P), 16.20
Azért is írtam feltételes módban, mert nem voltam biztos benne, hogy náluk botlottam ilyesmibe. Eszerint náluk működik ez a felállás is (csak a mysqli és a mysql+PDO nem :( ).
Sajnos annyi helyen kóboroltam, megfelelő tárhelyet keresve, hogy alig emlékszem egy-kettőre... :(