2009-11-08 12 views
6

Gdzie jest najbezpieczniejsze miejsce do przechowywania poufnego kodu na serwerze (np. Autoryzacja php, skrypty kontaktów, wrażliwy lub chroniony javascript)?bezpieczne miejsce do zapisania kodu

Chłopaki/dziewczęta mają jakieś wskazówki lub porady dotyczące ochrony tego rodzaju rzeczy?

+0

Czym jest ta "dziewczyna", o której mówisz? – Hello71

Odpowiedz

6

Możesz użyć .htaccess, aby odciąć zdalny dostęp do skryptów PHP (oczywiście nadal będziesz mieć do nich dostęp lokalnie z dołączaniem po stronie serwera). Zakładam, że twoje skrypty kontaktowe to także skrypty PHP. Mogą być obsługiwane w ten sposób. Tak czy inaczej, jeśli PHP działa na twoim serwerze, nawet jeśli użytkownik zna lokalizację pliku PHP, i tak nie będzie mógł zobaczyć kodu źródłowego. Zapobiega to tylko pewnemu nieautoryzowanemu wykonaniu.

Jeśli chodzi o wrażliwy lub chroniony kod JavaScript, można użyć kompresora JS, takiego jak this, aby zaciemnić kod, ale ponieważ JS jest wykonywany po stronie klienta, użytkownik będzie mógł zobaczyć dowolny kod źródłowy, który mu poda.

+0

Dobry pomysł z .htaccess, pomówię z tym pomysłem. Dziękuję Ci! – justin

+0

Obfuskacja jest definitywnie jedynym sposobem ochrony twojego js. –

4

Niektóre obserwacje

Problemem jest to, że trzeba, aby użytku każdym tego kodu, to musi być czytelne przez co proces używa go (zazwyczaj serwer www). Sam ten fakt sprawia, że ​​uzyskanie dodatkowych zabezpieczeń jest niepraktyczne, o ile nie można zastosować przetwarzania oczekującego w trybie offline.

Zasada # 1 - trzymać ją z DocumentRoot (chyba powinno być tam)

Zasada # 2 - uruchomić własny serwer (lub VPS) i trzymać innych ludzi poza nim

Reguła # 3 - zamknij skrzynię mocno - port 22 (z określonych adresów IP) i 80/443 z globalnego

PS. JavaScript jest wykonywany w przeglądarce internetowej - niewiele można zrobić, aby go zabezpieczyć (poza zaciemnieniem), ani nie musisz (np. NIE ufanie zewnętrznym danym jest regułą # 0).

2

Inną taktyką jest przechowywanie takich skryptów PHP nad publicznym folderem sieciowym. Twoje skrypty wciąż mają do nich dostęp. Często używam tego dla danych, które chcę udostępnić zalogowanym użytkownikom do pobrania. Muszę utworzyć skrypt, aby pobrać i wysłać dane, kiedy jest to potrzebne, ale nikt nie może uzyskać dostępu do tych danych, chyba że są one zalogowane i skrypt przesyła je do nich.

Skrypty są jeszcze prostsze - nie można uzyskać do nich dostępu. Twoje własne skrypty mogą je oczywiście zawierać, a używanie .htaccess do kontrolowania dostępu jest kolejnym wartym uwagi krokiem.

Powiązane problemy