nowy_pehapowiec
14.10.2009, 11:37:02
Muszę w jakiś sposób zabezpieczyć napisane kody w php. Ale muszą normalnie działać i generować strony. Ale sam podgląd plików nie może pokazywac normalnego kodu tak jak go napisałem. Czy da się to zrobić? Wydaje mi się, że to musi być jakiś algorytm szyfrujący pozwalający programiście na zaszyfrowanie kodu i serwerowi na odszyfrowanie. Jak bardzo to spowolni ładowanie stron? Jakie są do tego najlepsze narzędzia, najlepiej darmowe?
pozdro
jmail
14.10.2009, 11:42:50
wyszukaj w google obfuscator. Jeszcze inna sprawa, że możesz kod ropowszechniać już w postaci zinterpretowanej - wtedy masz na pewno zabezpieczone
Dumdas
14.10.2009, 12:18:50
php żadnym sposobem nie podejrzysz. No, chyba, że edytując plik przez menadżera na serwerze...
angel2953
14.10.2009, 12:20:21
możesz też skorzystać z Zend Guard'a (pod warunkiem, że na serwerze jest zainstalowany przynajmniej Zend Optimizer) wtedy kod będzie w postaci binarnej
Dumdas
14.10.2009, 12:41:44
Ale po co go zabezpieczać, spoko nie da się po prostu podejrzeć kodu php z zewnątrz, gdyś php działa po stronie serwera, a tylko wyniki wysyłane są do klienta. Nie ma sposobu, żeby podejrzeć kod PHP od strony klienta. Więc po co "zabezpieczać" i tylko serwer obciążać?
phpion
14.10.2009, 12:47:52
@Dumdas:
A kto mówi o podglądaniu kodu przez przeglądarkę? Chodzi o zabezpieczenie się przed fizyczną kradzieżą skryptu (plików) i jego modyfikacją.
Dumdas
14.10.2009, 12:55:15
Nikt nie mówi o przeglądarce. Klient to ten, kto łączy się z serwerem, nie program (w tym wypadku przeglądarka). Tak, czy siak - serwer parsuje php przed wysłaniem danych do klienta...
phpion
14.10.2009, 12:57:21
Klient to również osoba zlecająca prace nad skryptem. Oddając klientowi skrypt do testów (o ile prześlesz mu pliki) narażasz się na ich kradzież. Ciężko to pojąć?
jmail
14.10.2009, 13:15:20
Dumdas skąd Ty tego klienta wziąłeś? Kolega pytał o zabezpieczenie kodu przed podglądem kodu tak jak go on pisał. No nie wiem, ale ja nie potrafię pisać skryptów PHP przez przeglądarkę 8)
Dumdas
14.10.2009, 13:24:42
Wziąłem go stąd, że jedyna możliwość połączenia z serwerem to stanie się takim lub innym klientem. A będąc klientem nie można podejrzeć kodu PHP, chyba, że zezwoli na to sam serwer (file menagery na serwerach).
No pliki tak, czy siak zostaną przesłane, ale nawet jak się je zakoduje, to i tak można je rozkodować (PHP musi być przecież parsowane).
krowal
14.10.2009, 13:30:58
Cytat(Dumdas @ 14.10.2009, 14:24:42 )

No pliki tak, czy siak zostaną przesłane, ale nawet jak się je zakoduje, to i tak można je rozkodować (PHP musi być przecież parsowane).
To rozkoduj pliki zakodowane takim np Zend guardem i powiedz czy można czy nie

Owszem wszystko można, tak samo można zrobić reverse enginering programu napisanego w C i grzebać sobie potem w kodzie assemblera
dr4ko
14.10.2009, 14:19:26
@Dumas nowy_pehapowiec zapewne chce sprzedać aplikację webową "as it is" czyli żeby klient mógł ją postawić u siebie na serwerze, mógł z niej korzystać ale nie mógł jej zmieniać i nie miał wglądu do kodu.
Zaszyfrowanie kodu php często polega na jego prekompilacji i w rezultacie nie dosyć, że zabezpieczamy kod to jeszcze przyśpieszamy jego działanie
nowy_pehapowiec
15.10.2009, 12:35:49
phpion ma rację. Chodzi o klienta zlecającego robotę. Zrobiłem prostą stronę dla pizzerii i po tygodniu sklep zoologiczny z tej samej ulicy ma łudząco podobną stronę. Identyczny sposób działania, ten sam układ stron i prawie ten sam wygląd (tylko kilka obrazków zmienionych). Nawet nazwy klas w css są te same. Zawartość strony (menu, teksty, zdjęcia) jest zarządzana przez bazę i łatwa do zmienienia. Po prostu jedna "biznesłumen" dała albo odsprzedała drugiej całą stronę. Najbardziej wkurzający jest fakt, że na obu stronach zniknęło info o autorze strony. Zarówno z mety w html i ze stopki, a to już było w plikach php a nie w bazie. To była pierwsza strona jaką zrobiłem za kasę i to śmiesznie małą, właśnie po to aby były na niej info o mnie i odnośnik mejlowy. Byłem już u obu tych "biznesłumen" i nie bardzo nawet zaprzeczają. Teraz widzę, że złą umowę miałem i nie przewidziałem takiej sytuacji

Teraz już chyba wszystko jasne. Chce w przyszłości uniknąć takich sytuacji.
Czy jest jakieś sensowne zabezpieczenie nie wymagające zmian na serwerze? Jeśli tak to jakie|?
A jeśli nie to potrzebuje takiego zabezpieczenia, które będzie free. A solucja Zenda jest chyba płatna. Byłoby super jeśli takie szyfrowanie dałoby się połączyć z prekompilacją, żeby kod działał szybciej i strony ładowały się szybciej.
pozdro
Quantum
15.10.2009, 13:09:54
Sam spotkałem się jakiś czas temu z takim problemem, postanowiłem przetestować kilka programów, niestety wynik nie był zadowalający, wszystkie kończyły się na eval, wystarczyło podmienić na echo i miałem oryginalny kod, wyjątkiem był SourceCop, w którym wprowadzili pseudo-zabezpieczenie przed wyświetlaniem zdekodowanego źródła, polegało na sprawdzeniu czy ową funkcję zamieniono na (sprintf, print, echo, var_dump etc.), usunąłem jedną linijkę tego "zabezpieczenia" i wypluwało cały kod (moim zdaniem dużo lepszym rozwiązaniem byłoby sprawdzić czy !eval, ale nie ja to pisałem). Podsumowując nie polecam takich rozwiązań, to odstraszy tylko laików, mogę za to polecić ionCube, teraz możliwe jest zakodowanie pojedynczego skryptu czy aplikacji online bez kupowania licencji na program, cena zależy od ilości użytych znaków (w porównaniu do premii, którą otrzymasz za skrypt to grosze). Wymaga zainstalowanego rozszerzenia na serwerze, ale na większości współdzielonych jest zainstalowane, nie mówiąc o dedyku gdzie sam możesz to zrobić. Z darmowych zostają Ci tylko "obfuscatory", po których kod staje się nieczytelny dla człowieka, ale to tylko utrudnienie - nie uniemożliwienie.
Fafu
15.10.2009, 14:59:38
Może nie zabezpieczenie ale utrudnienie przed modyfikacją - usunięcie wszystkich białych znaków (spacji, enterów itp)
jmail
15.10.2009, 15:11:33
jeżeli chodzi o rzeczy "dokładane" do serwera to możena spróbować tego
http://turck-mmcache.sourceforge.net/index_old.html#aboutzawsze możesz sprawdzić, czy na docelowym serwerze działa funkcja dl jak działa to Ci to wciągnie bez problemów i masz problem z głowy.
Jak nie działa to nie zadziała

o patrz właśnie się doczytałem
Cytat
Standalone Loader
You can use files encoded by Turck MMCache without it. For this reason you must use TurckLoader. It is a regular PHP extension that can be used with other accelerators or without them. It can be loaded on startup or in runtime by dl(). TurckLoader is not need with Turck MMCache, becuse it is already compiled in. For more information about TurckLoader see README.loader file.
Czyli całość instalujesz u siebie, następnie ładujesz do projektu tego ancodera, którego w projekcie wciągasz przez funkcję dl - zawsze możnaby poprosić admina, żeby tego ext'a dorzucił na serwerze - wątpię, żeby się zgodził, ale czemu nei spróbować?
Quantum
15.10.2009, 18:11:51
Cytat(jmail)
Czyli całość instalujesz u siebie, następnie ładujesz do projektu tego ancodera, którego w projekcie wciągasz przez funkcję dl - zawsze możnaby poprosić admina, żeby tego ext'a dorzucił na serwerze - wątpię, żeby się zgodził, ale czemu nei spróbować?
hm no tak, ale jeżeli chcesz sprzedawać swoje skrypty (a o to chodzi autorowi wątku) to nie możesz prosić administratora serwera klienta o zainstalowanie "jakiegoś tam" rozszerzenia. Produkt, który sprzedajesz powinien być jak najbardziej kompatybilny.
jmail
15.10.2009, 18:51:50
dajesz w zastrzeżeniach, że na serwerze musi działać funkcja dl i masz problem z głowy. napisz drobnym maczkiem i nikt nie przeczyta
potreb
15.10.2009, 18:57:28
Cytat(phpion @ 14.10.2009, 12:57:21 )

Klient to również osoba zlecająca prace nad skryptem. Oddając klientowi skrypt do testów (o ile prześlesz mu pliki) narażasz się na ich kradzież. Ciężko to pojąć?
Jaka umowa taka kradzież. Rozumiem, ze boicie się o swoje prace ale bez przesady.
dr4ko
16.10.2009, 08:59:06
W tym wypadku to wina umowy ale np gdy dajesz klientowi aplikację z licencją np na 5 użytkowników a każdy nowy użytkownik ponad limit wymaga dodatkowej opłaty to chciałbyś móc zabezpieczyć kod przed ingerencją

Z resztą zabezpieczenie kodu jest łatwiejsze niż ciąganie się z klientem po sądach.
nowy_pehapowiec
16.10.2009, 10:12:32
Dzięki za wszystkie posty

Oczywiście sam się na to naraziłem nie zawierając odpowiedniego zastrzeżenia w umowie. To moja pierwsza umowa, bo php zajmuje się hobbystycznie. Ale mam nadzieje, że nie ostatnia, choć trochę mi się odechciało po tym wszystkim.

Czy php można prekompilować to postaci binarnej? W jaki sposób? Wtedy chyba nie musiałbym nic dodawać na serwer?
Czy obfuscatory mają jakieś znane ograniczenia i błędy? Czy nie wsypują się przy jakiś konstrukcjach języka albo coś takiego? Czy trzeba zwracać na coś uwagę podczas pisania kodu, żeby potem nie było niespodzianke po działaniu obfuscatorem?
pozdro
Pilsener
16.10.2009, 10:57:46
Dając klientowi kod możesz tylko utrudnić jego kradzież.
Moim zdaniem należy iść w dwóch kierunkach:
1. Serwer uwierzytelniający - coś takiego jak gra po necie, nie masz oryginalnego klucza to nie pograsz - jak to rozwiązać praktycznie to już można by napisać pracę licencjacką pewnie

2. Sprzedawaniu nie skryptu, lecz świadczonej przez niego usługi - np. klient chce system newsów taki a taki. Skrypt piszesz, wrzucasz na swój serwer, dajesz dostęp do PA a newsy na stronie klienta są pobierane z Twojego serwera.
dr4ko
16.10.2009, 12:34:24
Nie rozwiązuje to problemu dużych klientów którzy ze względu na wewnętrzne procedury bezpieczeństwa wymagają trzymania wszystkich danych na ich własnych serwerach.
mkdes
16.10.2009, 13:10:30
Ja koduje ioncube encoder.
http://www.ioncube.com/sa_encoder.phpNie opóźnia wykonywania plików, wręcz przeciwnie przyśpiesza jak jest dużo linijek kodu.
Większość hostingów ma zainstalowane encodery, a jak nie to instalacja jest tak prosta że pewnie nie ma problemów by doinstalowali.
nowy_pehapowiec
19.10.2009, 12:02:55
mkdes
20.10.2009, 07:30:51
Nie, chodzi mi o "ionCube Encoder". Podałem ci linka do produktu.
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.