Tekst źródłowy strony Czy bezpieczne jest umieszczanie wszystkich plików Joomla w katalogu public html?

'''Krótka odpowiedź'''

Potencjalnie, tak. Twoja witryna jest bezpieczna, ale musisz być ostrożny i czujny.

'''Dłuższa odpowiedź'''

Podstawową zasadą zabezpieczenia zasobów serwera jest utworzenie różnych poziomów bezpieczeństwa, a następnie przydzielanie uprawnień na każdym poziomie tylko w koniecznym zakresie. Na serwerach UNIX realizuje się to poprzez przyznawanie praw do katalogów i plików użytkownikom, grupom, i innym (światu). 

Z reguły najbardziej niebezpiecznym katalogiem na serwerach UNIX jest katalog służący do obsługi wymiany danych z siecią zewnętrzną, zwykle nazywany public_html. Katalog ten musi być dostępny publicznie, dopuszczając każdego do czytania jego zawartości, a w przypadku systemów zarządzania treścią CMS, powinien zezwalać nawet na zapisywanie do plików. Ten status czyni go z definicji ekstremalnie niebezpiecznym.

Dopóki nie przeszkadza ci, że cały świat może oglądać zawartość tego katalogu, problemu nie ma. Został stworzony dokładnie do tego celu. Kiedy jednak chcesz cokolwiek ukryć przed innymi, pojawia się problem. Jeżeli w tym katalogu umieścisz np.:
* pliki konfiguracyjne z poufnymi danymi,
* skrypty zapisujące dane do bazy danych,
* skrypty modyfikujące inne pliki,
* skrypty dopisujące dane do logów,
* skrypty zapisujące tymczasowe dane w pamięci podręcznej,
* skrypty które obsługują zapisywanie plików i grafiki na serwer,
* skrypty które obsługują formularze,
* skrypty które przetwarzają dane osobowe lub finansowe,

to ten katalog z prawami tylko do czytania, zmienia się na katalog z prawami także do zapisu.  

Jeżeli są jakiekolwiek słabe punkty w jakimkolwiek pliku w katalogu public_html, cały serwer staje się potencjalnie zagrożony, a nie tylko Twoja strona. Słabe punkty pozwalają włamywaczom na dostęp do skryptów obsługujących Twoją stronę. PHP, Perl i inne języki skryptowe to narzędzia potężne i łatwe do użycia. Jeżeli błędy programowe pozwalają atakującemu na wywołanie różnych poleceń, cały serwer staje się otwartym celem.

Jedynym dobrym sposobem zablokowania atakujących jest lokowanie potencjalnie zagrożonych plików za bezpieczną barierą. Z tego powodu zaleca się umieszczanie w katalogu public_html tylko tych plików, które wymagają bezpośredniego dostępu z sieci. Inne pliki powinny być ładowane do aplikacji takimi poleceniami jak ''include'' (wstaw) i ''require'' (przywołaj). Aby dostać się do takich plików włamywacz musi najpierw spenetrować Twój serwer, np. przez odkrycie Twojej nazwy użytkownika i hasła.

'''Bezpieczeństwo przede wszystkim'''

Aby zapewnić łatwą instalację Joomla! stosuje się zróżnicowany dwupoziomowy  model bezpieczeństwa. Na pierwszym poziomie możliwe jest proste przeprowadzenie instalacji z przeglądarki, z katalogu instalacyjnego dostępnego dla całej sieci. Drugi poziom to wymaganie usunięcia tego katalogu natychmiast po instalacji.  

Przyznanie programowi instalującemu praw do zapisywania plików znajdujących się poza katalogiem public_html byłoby ogromną dziurą w bezpieczeństwie. Dlatego domyślnie pliki Joomla! w końcu lądują w dostępnym dla całej sieci public_html. Nieprzypadkowo, jest to katalog będący celem wszystkich włamywaczy sieciowych.

Obecnie większość rozszerzeń Joomla! ma ograniczone wsparcie (dostęp) do plików znajdujących się poza katalogiem public_html. To spuścizna (legacy) po instalacyjnym modelu Joomla 1.0.x .

'''Obrona Joomla!'''

W związku z potencjalnie niebezpiecznym umiejscowieniem, Joomla! stosuje różne efektywne metody do blokowania exploitów. Główną wśród nich jest dodanie linii kodu na początku każdego pliku PHP który wymaga specjalnego zabezpieczenia. Metoda ta jest bardzo efektywna jeżeli KAŻDY plik wymagający takiego zabezpieczenia będzie je posiadał. Jeden błąd, jeden niezabezpieczony plik, naraża na atak wszystkie zasoby strony! 

'''Wyzwanie'''

Praktyka umieszczania wszystkich plików w katalogu public_html, a następnie budowanie bariery bezpieczeństwa przez dodawanie linii kodu w każdym pliku wydaje się administracyjnym koszmarem. Jeden pominięty plik naraża na atak cały serwer! To doskonały przykład modelu bezpieczeństwa typu:

 najpierw zezwól (Allow), a potem zabroń (Deny) 

Model ten wymaga ciągłych, dokładnych aktualizacji, stałego przeglądania logów, i aktywnego neutralizowania nowych dziur w bezpieczeństwie kiedy tylko zostaną ujawnione. Ponieważ musisz być o krok przed atakującymi, to zmusza do pośpiechu, co może niechcący doprowadzić do powstania nowego słabego punktu, a co za tym idzie, powstania nowego zagrożenia.

Podczas instalacji i aktualizacji musisz weryfikować każdą linię kodu każdego nowego pliku pod kątem każdego znanego zagrożenia. Skrypty mogą niezamierzenie wpływać wzajemnie na siebie, nie możesz więc zapomnieć o ich ciągłym testowaniu. To oczywiście generalna zasada dla każdego oprogramowania, ale lokowanie całej aplikacji w katalogu public_html czyni problem ekstremalnie krytycznym.

Ostatnia fala ataków polegających na "wstrzykiwaniu" adresów zasobów (URL injections), w źle napisane rozszerzenia autorstwa osób trzecich, byłaby mniej skuteczna, gdyby pliki te były umiejscowione poza katalogiem public_html, a co za tym idzie niedostępne z poziomu formatu adresowania zasobów, czyli z poziomu URL. W wielu przypadkach znane dziury bezpieczeństwa w plikach  nadal istnieją, ale ponieważ te pliki znajdują się poza katalogiem public_html, nie są narażone na ataki typu URL injections. 

 Zatem najpierw Zabroń, a potem Zezwól - (Deny, then Allow), czy najpierw Zezwól, a potem Zabroń - (Allow, then Deny)?

Ten dobrze znany kwalifikator to model typu - najpierw zezwolenie (Allow), a potem zabronienie (Deny). Innymi słowy najpierw dajemy każdemu dostęp do plików, a potem zabraniamy dostępu do określonych plików przez dodanie linii kodu.

Rozważcie logikę skryptu autentykacji hasła. Zasadniczo mamy dwie opcje:
# Najpierw zezwolenie wszystkim na dostęp, a potem wykluczenie (zabronienie) jakiejkolwiek kombinacji nazwa użytkownika/hasło, która NIE pasuje do listy akceptującej.
# Najpierw odmówienie dostępu wszystkim, a potem zezwolenie na jakąkolwiek kombinację nazwa użytkownika/hasło, która PASUJE do listy akceptującej. 

Oczywiście druga metoda jest lepsza. Prosta znajomość wyrażeń regularnych mówi, że pierwszą metodę jest dużo trudniej bezpiecznie zapisać. Nie zadziała ona za każdym razem, gdy powstają nowe metody ataków i będzie wymagać ciągłych weryfikacji. Z czasem takie weryfikacje staną się tak rozbudowane, że sam system zabezpieczenia może stać się źródłem zagrożenia.

Koncepcyjnie druga metoda jest przykładem budowania silnej bariery bezpieczeństwa obejmującego całą Twoją stronę (Deny), a potem przyznawania ograniczonego dostępu według dobrze zdefiniowanych kryteriów (then Allow). Jeżeli nawet nastąpi włamanie do skryptu, najprawdopodobniej użytkownik, który posiada legalny dostęp, zostanie zablokowany. To kłopot, ale nie przełamanie systemu bezpieczeństwa.

'''Dobre wiadomości'''

# W Joomla! 1.0.x niektóre rozszerzenia i sam szkielet Joomla! po zakończeniu instalacji umożliwiają umiejscowienie krytycznych katalogów poza katalogiem public_html. Jeżeli to tylko możliwe, powinieneś tak zrobić.
# Joomla! 1.5 posiada już dużo lepsze rozwiązania. Dostarcza ona kilka nowych stałych dla określonej lokalizacji szczególnie wrażliwych katalogów, w tym konfiguracji, administratora, bibliotek, i instalacji. 
# Joomla! 1.5 jest w stanie działać jako konto FTP. To pozwala na jeszcze inny sposób zabezpieczenia plików na pliku przez plik i katalogu na bazie katalogu. <span style=color:red>


<noinclude>
==Zobacz także ==
* [[Portal:Bezpieczeństwo|Portal: Bezpieczeństwo]]
[[Kategoria:Bezpieczeństwo]]
[[Kategoria:FAQ - Bezpieczeństwo]]
</noinclude>