Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [władza] Własny język
Forum PHP.pl > Forum > PHP > Pro > Archiwum Pro
Jabol
Piszę ten wątek tutaj ponieważ nie pasuje on chyba na php pro gdyż jego tematyka jest zbyt swawolna, a php to już nie to.

Ostatnio sporo myślałem nad systemem php.pl i doszłem do wniosku, że cały system (a raczej kontrola jądra nad modułami -> bezpieczeństwo) będzie w dużej częsci polegała nie na funkcjonalności jądra, ale na zauwafniu, że nikt z develeperów nie będzie umieszczał tam (w kodzie modułów) koni trojańskich ani nic takiego. Mówie tutaj, że jakiś moduł zamiast proszenia BSP o plik sam go sobie weźmie za pomocą sql-layer (tak to bede nazywał) zdobytej przez funkcje global. Może nie byłoby tak z samym systemem ale np. nieoficjalne wtyczki...

Wtedy z pomocą przyszedł mi matrix 2 (sam nie wiem czy był taki nudny, że miałem czas pomyśleć spokojnie, czy wyciągnąłem wnioski z samego filmu winksmiley.jpg ). Co prawda system (matrix) dał się złamać, ale oglądając go doszłem do pewnych wniosków jak dać jądrze kontrole nad aplikacją. W sumie doszłem do takiego wniosku.
Jeżeli chcemy wiedziec co robi aplikacja (mówie ogólnie, w naszym przypadku moduł), czego używa a czego nie i jeszcze na dodatek to wszystko kontrolować, to aplikacja musi działać o poziom niżej w hierarchi od jądra. Innymi słowy aplikacja nie powinna być wykonywana przez parser języka (w naszym przypadku php), ale przez naszą aplikację. W ten sposób każda czynność, każda linijka kodu mogłaby być sprawdzana pod kontem niebezpieczeństw.
Teraz następny problem. Ale jak to zrobić? Ano jak w temacie trzeba napisać własny język. Myślałem o tym. Nie pisałem jeszcze własnego języka i nie mam w tym doświadczenie, ale wymyśliłem jak mógłby wyglądać taki język naprzykład stworzony w XML'u. Pokarze tutaj jak wyobrażam sobie taki "hello world" dodatkowo ze sprawdzaniem parametru z GET'a.
php:[php:1:adb267e0b1]<?php
if( $_GET['say']==1 ) {
print "Hello World";
}
else {
print "I won't say hello to you";
}
?>[/php:1:adb267e0b1]
Własny język w XML'u:
Kod
<application>

<if>

<warunek>

<equal>

<param source="get" name="say" />

<int>1</int>

</equal>

</warunek>

<then>

<out>

<text>Hello World</text>

</out>

</then>

<else>

<out>

<text>I won't say hello to you</text>

</out>

</else>

</if>

</application>
Nie wiem jak tam z moją angielszczyzną, ale mam nadzieje, że założenie jest zrozumiałe. Teraz w XML'u możemy każdą instrukcję sprawdzić i dopiero potem wykonać. Można by było definiować obiekty, a nawet np. stworzyć jezyk obiektowy za pomocą znaczników typu <math:sqrt><int>9</int></math:sgrt>.
Teraz moja największa obawa. Wydajność... Jak by to działało pod względem szybkości. Przy moich założeniach, że każde rozszeżenie poza standart (core) byłoby includowane specjalnym znacznikiem (jak use w perlu, import w pythonie czy dl w php) pamięc nie byłaby zbytnio obciążona.

Takie coś wcale nie jest trudne do wykonania a daje olbrzymie możliwości, jak całkowia kontrola aplikacji instruckja po instrukcji i np. Jeszcze można np.dodac obsługe userów (napisane w php, jako część języka, a potem sprawdzać czy user ma dostęp do wykonywania określinych instrukcji), BSP (z poziomu języka nie można byłoby mieć dostępu do normalnego systemu plików) i można byłoby zboduwać naprawdę potęrzne środowisko do pisania aplikacji w których ważne jest to, że nie mamy całkowitego zaufania do kodu źródłowego.


Wow, ale tekst wyskrobałem.
Bardzo proszę o komentarze (jeżeli komuś będzie się chcuało to czytać) ponieważ dużo o tym myślałem i jestem ciekwa co Wy o tym sądzicie.
Jeżeli są jakieś niejasności to pytajcie (ja mam wizje i wiem o co mi chodzi ale Wy nie jesteście mną winksmiley.jpg ).
spenalzo
Ja nie z działu od jądra systemu ale się wtrącę:
aby "język" taki działał musi być szczegółowo napisany i opisany (dokumentacja). Trochę czasu zajęłoby pewnie przyswojenie sobie tego języka. Jednak ja jestem przeciwny:
1. jeżeli php da się złamać, to taki język też.
2. wyważanie otwartych drzwi?

Sorry, Jabol - uważam, że pomysł godny pochwały, ale nakład pracy będzie niewspółmierny do wyników.

PS. Nie wiem czy dobrze zrozumiałem Twój post...
Jabol
post dobrze zrozumiałeś, ale nie miałem tutaj zamiaru podawać propozycji do wykorzystania z php.pl (gdybym tak chciał to bym napisał w php.pl - jądro), bo wiem jak to wszystko wygląda (php.pl jest tutaj po prostu przykładem). Chciałem poznać Wasze opinie oraz może również poznać Wasze pomysły na kontrole aplikacji.

Ad. 1. Co do dokumentacji takiego języka to oczywiście, że trzeba by było coś takiego zrobić (niestety, jakby dokumentacją nie mógł by być kod języka sad.gif ).
Ad. 2. Czemu wyważanie otwartych drzwi. Nie znam sposobu kontroli skryptu w php. Jeżeli wykonuje się pewna część skryptu to się wykonuje i nie ma możliwości jej kontroli.
Ad. Sorry, Jabol. Każdy pomysł wymaga odpowiedniego nakładu pracy, niestety jedne więcej inne mniej.
Seth
Po pierwsze to przezuce to do jadra bo to troche odbiega od hydeparkowego klimatu winksmiley.jpg

System dlatego bedzie na BSP aby uchronic pliki przed ich modysikacja przez nieautoryzwowane moduly. Modul nie bedzie mial dostepu do zmiennych globalnych w tym i do GET, POST itp. Bedzie on mial jedynie dostep do warstwy posredniej komunikaci z jadrem i min za jej posrednictewm majac odpowiednie prawa do bazy (ale nie calej). Modul bedzie mial tez swoje miejsce w BSD zarezerwowane tylko dla niego gdzie bedzie mogl gromadzic dane jak a dysku. Reasumuac nie bedzie mial mozliwosci ingerencji w kod - bedzie jednak trzeba jakos zabezpieczyc pliki, ktore nie beda w BSP ale o tym jeszcze sie pomysli.

Co do Twojego pomyslu z wlasnym jezykiem to hmmm jest to jakies rozwiazanie ale nie zmuisisz nikogo do pisania prgramu w innym jezyku. Dlatego malo osob bylo by tym zainteresowanym. Poza tym wydajnosc tez zmaleje.

_________ update
"po pierwsze" jest juz nie aktualne winksmiley.jpg
spenalzo
Cytat
Ad. 1. Co do dokumentacji takiego języka to oczywiście, że trzeba by było coś takiego zrobić (niestety, jakby dokumentacją nie mógł by być kod języka sad.gif ).

W sumie taka dokumentacja mogła by wyglądać tak:
Kod
<application> - znacznik rozpoczynający aplikację

<if> - początek pętli if()

<warunek> - znacznik zawierający sprawdzenie warunku zawartego w znaczniku <if>

Ale aby dorównać funkcjonalności php, trzeba by opracować tysiace takich znaczników, napisać parser - a to na pewno zajmie trochę czasu...

Cytat
Ad. 2. Czemu wyważanie otwartych drzwi. Nie znam sposobu kontroli skryptu w php. Jeżeli wykonuje się pewna część skryptu to się wykonuje i nie ma możliwości jej kontroli.

Chodzi o to, że twórcy php nieustannie dokładają starań, aby język był jak najbardziej bezpieczny. Ale zawsze znajdzie się ktoś, kto obejdzie te zabezpieczenia. Tak samo moze być w przypadku Twojego języka.

Cytat
Ad. Sorry, Jabol. Każdy pomysł wymaga odpowiedniego nakładu pracy, niestety jedne więcej inne mniej.

Nie lepiej dobrać zaufane osoby? Przecież wystarczy kontrolować kod, czy ludzie nie robią jakiś świństw, a jeżeli tak, to kasować te rzeczy a ludzi usuwać z listy. Oczywiście zawsze znajduje się jakaś czarna owca, która tylko myśli jak coś spieprzyć innym.
Jabol
Cytat
Po pierwsze to przezuce to do jadra bo to troche odbiega od hydeparkowego klimatu winksmiley.jpg
Ups. źle przeczytałem (myślałem, że sygerujesz mi przeniesienie) i przeniosłem do php pro, gdzie myślę będzie lepiej pasował.

Można byłoby napisać sam parser i moduł core oraz dokumentacje z udokumentownym pisaniem własnych wtyczek-modułów do języka w zależności od potrzeb. Niestety Seth ma racje. php już jest troszkę powolny, a co dopiero język w php, to by była potrójna interpretacja... Coś takiego natomiast można by było napisać np. w c/c++ jako aplikacje do celów wyżej wymienionych, która byłaby zdecydowanie bezpieczniejsza. Ale to już z koleji jest wyważanie otwartych drzwi ze względu na istnieine np. php.
coder
[ciach! wszystko]

Takie cos juz wymyslono. Nazywa sie to ColdFusion Markup Language (CFML) i szczerze mowiac nie widze powodu, aby takie 'jezyki' byly komus potrzebne. Sa latwe do opanowania to fakt, ale przy tym ogromnie wydluzaja kod zrodlowy i sa po prostu.. niewygodne.

Pozdrawiam
Teodor
Witam
Ja moze mam malo wspolnego z "Pro" ale wtrace cosik.
Pomysl wlasnego jezyka jest niezly - tylko jak @spenalzo zauwazyl - jezeli da sie zlamac podstawe na ktorej dziala to i sam jezyk da sie zlamac...
Z drugiej jednak strony komercyjne skrypty dzialaja wlasnie na tej zasadzie -> CPanel np. (choc wiecej z tego problemow niz zyskow smile.gif)
Ja uwazam ze kazdy system musi bazowac na zaufaniu bo nie ma sytemu w 100% bezpiecznego. Chec idealnego zabezpieczenia powoduje paranoje smile.gif
Bo zabezpieczysz swoj skrytpt(od strony php) w 99% to nagle wyjdzie kolejny bug Apache, jak nie Apache to zostaje jadro linuxa albo jezeli to Windows kolejny "ukryty ficzer Billa".
Jezeli chcecie zabezpieczyc sie w pewniejszy sposob (nie automatycznie) to wstawcie w waszym wykresie miedzy "modules" a "queue system" - pozycje "approval"
A jezeli chcecie kontrolowac co robi dany modul/wystrzec sie koni trojanskich - to stworzcie cos w stylu SMARTY dla kodu - bo gdy samemu sie okresla granice nie trzeba potem specjalnie kontrolowac (modul nie zrobi nic innego niz moze).

To tylko takie moje czysto teoretyczne rozwazania - jak pisalem z PRO mam malo wspolnego...

Pozdrawiam
Nalfein][WR
Nie przesadzacie tutaj? Może chcecie napisać interpreter w języku interpretowanym? I to miałoby być przetwarzane przy każdym żądaniu? laugh.gif

Jeśli już zakładamy, że nie można ufać programistom to wydzielmy osoby, które weryfikowałyby nowy kod. Mógłby on być wtedy zatwierdzony lub nie (można by nawet wprowadzić a'la certyfikaty) i tyle. Jednak nikomu by się nie chciało żmudnie przeczesywać kod za każdym razem - można by napisać skrypt sprawdzający nowe moduły podczas instalowania pod kątem "niebezpiecznych" struktur. Taki prosty parser php w php, ale wywoływany jednokrotnie, tylko przy instalacji lub aktualizacji modułu. Jeśli odnajdzie w kodzie wywołanie funkcji, którą monitoruje to sprawdzi uprawnienia użytkownika i ostrzeże bądź od razu odrzuci podejrzany moduł. Nie byłoby to łatwe w implementacji (trzeba bedzie obsłużyć wariacje w stylu $func = 'mysql_query'; $func('DROP TABLE...')), ale jest do zrobienia smile.gif

Innym rozwiązaniem byłoby jakby wykonywanie kodu modułu jakby w innym środowisku, w którym nie byłyby dostępne zewnętrzne funkcje. Raczej nie będziemy wywoływać php.exe, bo i tak tam mamy dostęp do
wszystkich funkcji bibliotecznych. Nadzieją jest PHP5, który wg. tego co piszą odziedziczy z innych języków widoczność zmiennych sterowaną blokami, tj. co zadeklarujemy w głównym skrypcie będzie widoczne niżej, bez konieczności uzycia global. Analogicznie w drugą stronę: nie możemy z poziomu funkcji utworzyć zmiennej, która będzie widoczna w zewnętrznym bloku, jeśli nie zostanie tam wcześniej zadeklarowana. Jeśli deweloperzy Zenda pójdą jeszcze dalej to może umożliwią wywołanie parsera php na bloku kodu z wybraniem bibliotek, które możemy w nim uzywać. Wtedy takie coś jak php_safe mode nie będzie już potrzebne, a my będziemy mogli zrobić sobie własną Wirtualną Maszynę php czy php Runtime Framework rodem z .Net tongue.gif
kurtz
Cytat
[WR"]Nadzieją jest PHP5, który wg. tego co piszą odziedziczy z innych języków widoczność zmiennych sterowaną blokami, tj. co zadeklarujemy w głównym skrypcie będzie widoczne niżej, bez konieczności uzycia global. Analogicznie w drugą stronę: nie możemy z poziomu funkcji utworzyć zmiennej, która będzie widoczna w zewnętrznym bloku, jeśli nie zostanie tam wcześniej zadeklarowana.
eh - poki co wyczytalem ze z php5 wyrzucono namespace'y - dla mnie oznacza to ze php nadal bedize jezykiem o 1000 funkcji.. a w tym momencie staorzenie modulowego zestawu potrzebnych elmentow troskze wymyka sie spod kontroli. odpukac. zobaczymy jak to bedzie na koncu.


pozdrawiam
Jabol
Z tymi namespacami to wlasciwie mozna je latwo zastompic (np. klasami, ktore maja byc bardzo rozbudowane).
A tak wogole to zna ktos z was jakas przewidywalna date pojawienia sie php5.0.0 stable ? Bo jak na razie trzeba korzystac z dev a te to so codzienne nowe wersje i jakbym chcial byc na czasie to byloby trudno.
[/list]
scanner
Cytat
[WR"]Jeśli już zakładamy, że nie można ufać programistom to wydzielmy osoby, które weryfikowałyby nowy kod. Mógłby on być wtedy zatwierdzony lub nie (można by nawet wprowadzić a'la certyfikaty) i tyle.
Dokumentacja jest przygotowana na przyjęcie opisów zatwierdzonych oficjalnie przez devTeam modułów pochodzących ze źródeł "zewnętrznych".
Nalfein][WR
Cytat
eh - poki co wyczytalem ze z php5 wyrzucono namespace'y - dla mnie oznacza to ze php nadal bedize jezykiem o 1000 funkcji.. a w tym momencie staorzenie modulowego zestawu potrzebnych elmentow troskze wymyka sie spod kontroli.


Ciekawe. Nie wiem jak zamierzają obyć się bez przestrzeni. Dosłownie zamienią je na klasy? A może jeszcze powstaną takie pokręcone, kobylaste wrappery na biblioteki w stylu PEAR? Z tego co widzę i czytam na grupach Zenda połowę nowych ficzersów zmałpowali po Javie, więc możliwe, że będą chcieli zrealizować coś podobnego - domenowe przestrzenie nazw, właśnie mapowane na klasy. Aż boję się pomyśleć jaki mutant może z tego wyjść winksmiley.jpg Ja już studiuję materiały o J2EE...
e-Gandalf
Mam podobne przemyslenia do autora watku. Koncze wlasnie CMS, nad ktorym troche czasu spedzilem i rowniez natknalem sie na problem "jednej warstwy". W najwiekszym uproszczeniu problem sprowadzilem do jednego przykladu.

1) Zalozmy, ze CMS posiada obsluge kont
2) Zalozmy, ze instalujemy modul X
3) modul X jest blokiem jezyka php poprzez API CMSa zintegrowany z jadrem, ale API jest tutaj "grzecznosciowe", bo modul moze sobie robic co chce.
4) Jak mozna zablokowac mu mozliwosc zmiany hasla dowolnego konta z bazy?

Odrzucilem jednak z miejsca teorie stworzenia jezyka, bowiem nie mam sil mierzyc sie z podobnym zadaniem, zwlaszcza, ze wymagaloby to spowolnienia wykonywania skryptu, a na takie koszty nikt sie nie zgodzi.
Postanowilem przeanalizowac problem bez dzielenia na warstwy...

Mozna rozroznic trzy elementy z ktorych sklada sie problem.

1) Blokada odczytu/zapisu konkretnych zmiennych/walsciwosci oraz uruchamiania konkretnych funkcji/metod
2) Blokada odczytu/zapisu bazy danych zwiazanych z CMSem
3) Blokada odczytu/zapisu plikow na dysku

Jesli pozwolicie zaczne od konca, bo najlatwiej.

Punkt trzeci mozna rozwiklac poprzez blokade konkretnych funkcji (ktorych wcale nie jest tak duzo) lub tez ich podmiane w kodzie. Pierwszy sposob jest ladniejszy, ale nie mam pojecia jak z jego realizacja w php (tzn. wiem, ze istnieja funkcje, ale nie probowalem). Druga metoda jest "brzydsza", ale ma swoje zalety. Mozna np. przyinstalacji modulu zamienic wszystkie wywolania funkcji X na wywolania wlasnej funkcji Y, ktora nie odpali X jesli jednym z argumentow nie bedzie prawidlowy klucz, albo jesli zmienna globalna M nie jest true. I doszlismy do problemu punktu pierwszego. O tym na koncu.

Drugi punkt tez mozna latwo sprowadzic do punktu pierwszego. Mozna wytworzyc piaskownice dla modulu, jesli CMS bedzie mial dwoch uzytkownikow w DB - admina i moduly. Admin dziala sobie z kontami newraligcznymi, takimi jak |accounts|,|privilages|,|session| a przed odpaleniem przelogowuje sie na konto |modul| nie majace do powyzszych uprawnien. Pytanie jak zabezpieczyc sie, zeby modul znowu sie nie przelogowal. Proste. Modul nie mozna znac hasla... i znowu wracamy do punktu wyjscia (czyli punktu pierwszego)

Punkt pierwszy jest najtrudniejszy. Sprowadza sie do pytania, jak stworzyc blok, w ktorym nie bedzie mozna odczytac dowolnych danych bedacych w pamieci.
Z pomoca przyszedl mi blad istniejacy w php (blad/nieblad... moim zdaniem wada). Otorz bedac w strodku metody nie mozemy poznac nazwy obiektu, w ramach ktorego zostala odpalona metoda.
Ta metoda dla mnie dziala, ale ma pare wad. Jak wszystkie opierajace sie na dirty-hackach. Wymaga ciaglego "ukrywania" nazw przed modulem. A to nie wyglada ladnie w kodzie winksmiley.jpg

Ogolnie doszedlem do wniosku, ze najlepiej poczekac na piatke. Wowczas mozemy zrobic klase CMS, ktorej potomkami beda wszystkie newralgiczne |accounts|,|session|,|access|,|groups| i tak dalej, oraz beda one final. Wowczas wlasciwosci newralgiczne dajemy private, i mamy spokoj. Zaden niegrzeczny modul nie podepnie sie pod nie.... bo mu na to nie pozwalamy smile.gif A nie majac dancyh (hasel itp.) nie bedzie mogl zalogowac sie do DB, ani podmienic nic innego.

(hmm, slowo wyjasnienia. Jestem tu nowy i zielony, wiec jesli cos niezgodnie z zasadami forum walnalem, to przepraszam *^^*)
Nalfein][WR
Cytat
Odrzucilem jednak z miejsca teorie stworzenia jezyka, bowiem nie mam sil mierzyc sie z podobnym zadaniem, zwlaszcza, ze wymagaloby to spowolnienia wykonywania skryptu, a na takie koszty nikt sie nie zgodzi.


Ale można zrobić język kompilowany przy pierwszej interpretacji do php, tak jak jest ze Smarty. Tylko jaką by miał składnię? Najlepiej podobną do php smile.gif I jesteśmy w punkcie wyjścia. Może PHP5 nas wybawi smile.gif


Cytat
Z pomoca przyszedl mi blad istniejacy w php (blad/nieblad... moim zdaniem wada). Otorz bedac w strodku metody nie mozemy poznac nazwy obiektu, w ramach ktorego zostala odpalona metoda.
Ta metoda dla mnie dziala, ale ma pare wad. Jak wszystkie opierajace sie na dirty-hackach. Wymaga ciaglego "ukrywania" nazw przed modulem. A to nie wyglada ladnie w kodzie winksmiley.jpg


Ta "luka" na nic się nie zda, jesli trafi się ktoś sprytniejszy. W PHP4 masz metodę get_class() i pochodne, za pomocą której możesz określić jakiej klasy jest dany obiekt. Mając jeszcze dostęp do $GLOBALS nasz użytkownik może dostać się do wszystkiego co ma identyfikator. Pozostają singletony (klasy jednoobiektowe, których instancję pobieramy statyczną metodą zwracającą statyczny obiekt np. Core::instance()), ale też jeśli się zna nazwę to wszystko wysiada. To nie jest rozwiązanie.

Cytat
Ogolnie doszedlem do wniosku, ze najlepiej poczekac na piatke. Wowczas mozemy zrobic klase CMS, ktorej potomkami beda wszystkie newralgiczne |accounts|,|session|,|access|,|groups| i tak dalej, oraz beda one final. Wowczas wlasciwosci newralgiczne dajemy private, i mamy spokoj. Zaden niegrzeczny modul nie podepnie sie pod nie.... bo mu na to nie pozwalamy smile.gif A nie majac dancyh (hasel itp.) nie bedzie mogl zalogowac sie do DB, ani podmienic nic innego.


Nieprawda. Jeśli moduły php nadal pozostaną zbiorami funkcji bezpośrednio importowanymi z C to nadal będzie można wywołać np. mysql_query(), które działa wykorzystując domyślnie ostatnio otwarte połączenie. Drzwi otwarte. Podobnie z klasami. Jeśli nie będzie się dało tworzyć klas lokalnych (klasa w klasie, wtedy potomne są zaprzyjaźnione z nadrzędnymi i moga mieć dostęp do jej składowych) to i tak na nic takie ograniczenia w stylu private, gdyż i tak będziesz musiał udostepnić publicznie jakiś interfejs do wymiany danych między modułami, a nie będziesz za każdym razem sprawdzał dostępu przy wywołaniu metody. Zawsze coś się znajdzie, co można wykorzystać.

Pozostaje właśnie piaskownica wbudowana w jezyk, czyli żeby za pomocą kodu inicjować inne środowisko php, które bezpiecznie przetworzy niepewny kod. Może goście z PHP5 o tym pomyślą. Może.
e-Gandalf
Cytat
Ale można zrobić język kompilowany przy pierwszej interpretacji do php, tak jak jest ze Smarty. Tylko jaką by miał składnię? Najlepiej podobną do php smile.gif I jesteśmy w punkcie wyjścia. Może PHP5 nas wybawi smile.gif


Dokladnie. Kompilowalnosc jezyka lub tez jej brak nie jest zadnym rozwiazaniem. Stajemy w punkcie gdy musimy w php obsluzyc inny jezyk nie ograniczajac jego swobody poza niebezpieczne punkty. To, ze musimy ograniczac wynika z zalozenia projektu, to ze nie mozemy powoduje, ze nie mozemy tutaj wstawic innego jezyka, ktorego mozliwosci bylby znacznie mniejsze od php. Najwygodniej byloby gdybysmy mogli "wlaczyc" piaskownice (czyli tryb bez funkcji x,y,z) i wylaczyc ja po wykonaniu kodu include() (ale nie pozwalac na to w samym include!)... tego chyba jednak nie mozemy zrobic (choc... hmm... mozna sprobowac chyba)

Cytat
Ta "luka" na nic się nie zda, jesli trafi się ktoś sprytniejszy. W PHP4 masz metodę get_class() i pochodne, za pomocą której możesz określić jakiej klasy jest dany obiekt. Mając jeszcze dostęp do $GLOBALS nasz użytkownik może dostać się do wszystkiego co ma identyfikator.


Toz mowilem o tym, ze wowczas nalezaloby zachowac sie sprytniej - obiekt przypisac elementowi tablicy albo cus... i niech "hackerski" skrypt sobie szuka... ALe to jest zabawa w kotka i myszke, i broniacy sie zawsze przegra. Wiec odpada

Cytat
Nieprawda. Jeśli moduły php nadal pozostaną zbiorami funkcji bezpośrednio importowanymi z C to nadal będzie można wywołać np. mysql_query(), które działa wykorzystując domyślnie ostatnio otwarte połączenie. Drzwi otwarte.


A! A! Przyecztaj co napisalem. mysql_change_user. Przelogowujemy goscia na czas jego modulu. Jedyne czego musimy pilnowac, to jest, aby nie poznal hasla na usera o wiekszych uprawnieniach.

Cytat
Podobnie z klasami. Jeśli nie będzie się dało tworzyć klas lokalnych (klasa w klasie, wtedy potomne są zaprzyjaźnione z nadrzędnymi i moga mieć dostęp do jej składowych) to i tak na nic takie ograniczenia w stylu private, gdyż i tak będziesz musiał udostepnić publicznie jakiś interfejs do wymiany danych między modułami, a nie będziesz za każdym razem sprawdzał dostępu przy wywołaniu metody. Zawsze coś się znajdzie, co można wykorzystać.


Nie! Myslalem o czyms w stylu klasy nadrzednej CMS w ktorej jest wlasciwosc CMS->db_pass ktora jest dostepna dla jej potomkow (potomkami sa klasy |accounts|,|access| itp) ale niedostepna dla modulu.

Natomiast zasmuciles mnie z klasami lokalnymi. O PHP5 wiem bardzo malo, ale myslalem ze to oczywiste ze bedzie...

Cytat
Może goście z PHP5 o tym pomyślą. Może.


Moze by im to zasugerowac? Model piaskownicy w stylu

[php:1:75942c3e07]<?php
$access->password='x23fe';
mysql_change_user('module','module_pass');
run_sand_box(false, false, false); // can_change_db, allowed_dir_list, allowed_object_list;
include('module.inc');
stop_sand_box();
?>[/php:1:75942c3e07]

bylby piekny dla kazdego autora CMSa posaidajacego API:)

?>[/php]
e-Gandalf
Nie ma nic lepszego od uporu smile.gif
php 5:

[php:1:c68c2dc004]<?php
class CMS {
private $in_module = false;

function in_module() {
return $this->in_module;
}

function run_module ($name) {
$this->in_module = true;
$GLOBALS['module']->include_module($name);
$this->in_module = false;
}
}

class DataBase {
private $users = Array('admin'=>'db23x', 'module'=>'w34rt');

function change_user($user) {
if (!isset($this->users[$user]))return false;
if ($user=='admin' && $GLOBALS['CMS']->in_module()) {
print('ALERT! HAXORE TRY!<br>');
return false;
}
print('changed - '.$user.'<br>');
// mysql_change_user();
}
}

class Module {
function include_module ($name) {
include_once($name);
}
}

class Account {
private $current = Array('id'=>12, 'login'=>'Gandalf', 'password'=>'df32421xs');

function getAccount() {
$temp = $this->current;
if ($GLOBALS['CMS']->in_module()) unset($temp['password']);
return $temp;
}
}

$db = new DataBase();

$CMS = new CMS();

$module = new Module();

$account= new Account();

$db->change_user('admin');

// CMS stuff

$db->change_user('module');

//-----------------

print('<br><-- BEGIN OF MODULE --><br><br>');
$CMS->run_module('hackore.inc');
print('<br><-- END OF MODULE< --><br><br>');

//-----------------
$db->change_user('admin');

// CMS stuff
?>[/php:1:c68c2dc004]

Zadanie jest proste. Z poziomu pliku hackore.inc odczytac haslo admina do bazy danych oraz/lub haslo konta.

Oczywiscie nie jest to jeszcze w pelni wykonana robota. Problem pojawia sie kiedy przy uzyciu prawidlowych funkcji ($account->CreateAccount) chcemy operowac na tablicach systemu. Rozwiazaniem jest (sic!) polaczenie rownolegle dwa razy z baza danych. Raz jako uzytkownik admin, a raz jako uzytkownik module. I teraz chcac wykonac cos na bazie danych pobieramy $db->ident() ktory zwraca dla modulu identyfikator polaczenia na konto 'module' a dla CMSu identyfikator polaczenia 'admin'.

Ale da sie smile.gif
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.