--=REKLAMA=--

Jak wybierać pewne i bezpieczne rozszerzenia?

Z Joomla!WikiPL

Wersja Zwiastun (dyskusja | edycje) z dnia 08:49, 16 kwi 2009

(różn.) ← poprzednia wersja | przejdź do aktualnej wersji (różn.) | następna wersja → (różn.)

Najważniejszą rzeczą jaką każdy może zrobić, to podjąć właściwą decyzję w sprawie wyboru rozszerzenia, które zostanie użyte na stronie. Jeżeli niepewne lub podejrzane rozszerzenie zostanie zainstalowane, zniszczenie strony staje się prawdopodobne. Nie istnieje ŻADEN sposób, by zabezpieczyć lub zablokować komponent przed dostępem do tabel bazy danych, do których nie powinien mieć dostępu. Nie istnieje sposób, aby zablokować komponent przed przesłaniem wszystkich wykradzionych informacji do strony włamywacza. Jeżeli niepewny czy podejrzany komponent został zainstalowany, cała Twoja strona jest zagrożona.

Pomimo tego, co wyżej powiedziano, istnieje kilka łatwych wskazówek co do wyboru rozszerzenia do instalacji.

Kiedy została wydana ostatnia wersja? 
Jeżeli ponad rok temu, poszukaj czegoś innego. Nie instaluj starych komponentów.
Jaki to rodzaj wydania? (stabilny, kandydujący (RC), Beta, Alpha) 
Dla stron produkcyjnych powinieneś stosować tylko wydania stabilne, jak tylko to możliwe. Jeżeli nie możesz czekać, aż ukaże się wydanie stabilne, wydania kandydujące są jedyną opcją, którą powinieneś rozważyć. Nie zaleca się nikomu instalowania wersji Beta czy Alfa na czynnej stronie. Wydania te zawierają błędy, nie zostały dostatecznie przetestowane oraz mogą mieć pewną liczbę błędów funkcjonalnych i z zakresu bezpieczeństwa, które nie zostały naprawione, i co gorsze, zostały już ujawnione.
Czy rozszerzenia mają historię dobrych praktyk z zakresu bezpieczeństwa?
To jest nieco subiektywne, ale wciąż jest ważną miarą przyszłego zaufania. Wymaga odrobiny śledzenia i badania. Przejrzyj ich stronę ładowania, czy jest tam wiele aktualizacji wydań i łatek? Czy są raporty na temat włamań przez to rozszerzenie? Czy developerzy są doświadczeni i świadomi zagrożeń? Co inni członkowie społeczności sądzą o tym rozszerzeniu? Jeden przykład który przychodzi mi do głowy ma niewiele wspólnego z samym Joomla! (z tego powodu przytoczenie tego przykładu wydaje się uczciwe) - jest to phpBB. Ten skrypt ma więcej wydań bezpieczeństwa niż można sobie wyobrazić, i rutynowo wydają się być ujawniane nowe problemy. Z tego powodu ja nigdy nie użyłbym phpBB. W mojej opinii nie jest to skrypt wart zaufania i istnieje wysokie prawdopodobieństwo, że ujawnione zostaną w nim nowe problemy.
Czy istnieje grupa wsparcia dla tego rozszerzenia? 
To bardzo ważne dla świadomości zagrożeń i funkcjonalności. Jeżeli jest wsparcie społeczności dla tego rozszerzenia, istnieje większa szansa, że zagrożenia zostaną zlokalizowane i naprawione. Wsparcie społeczności oznacza, że ludzie chcą użytkować tego rozszerzenie i będą o nie dbali. To zwiększa prawdopodobieństwo, że zagrożenia zostaną szybko ujawnione i usunięte.
Czy dla tego rozszerzenia istnieje tylko wersja dla Mambo? 
Ten fakt sam w sobie nie czyni rozszerzenia niepewnym, ale jest raczej miarą wsparcia (kiedy było ostatnie wydanie i co z dalszym wsparciem?). Niewielkie jest prawdopodobieństwo, że komponent Mambo będzie współpracował z 1.5, więc oszczędź sobie kłopotu i znajdź komponent przeznaczony do pracy z Joomla! Ułatwisz sobie życie.
Czy rozszerzenie jest wolne od błędów? 
Wspomniałem o tym nieco w pkt 3, ale sądzę, że warto ten temat pogłębić. Praktycznie jest prawie niemożliwe, aby rozszerzenie było całkowicie wolne od błędów, jednak czym mniejsza ilość błędów, tym lepiej. Jeśli są błędy w oprogramowaniu, to oznacza nic innego, że są błędy w oprogramowaniu. Czym więcej błędów, tym większe ryzyko problemów z funkcjonalnością i bezpieczeństwem. Problemy z bezpieczeństwem są często wynikiem nie jednego, ale kilku błędów lub złych praktyk. Na przykład, ostatnie błędy rozszerzeń pozwalające zdalnym plikom wklejenie kodu są rezultatem:

Złe praktyki

  1. Włączenie w PHP register globals.
  2. Używanie przestarzałych lub porzuconych rozszerzeń.
  3. Niewłączanie innych dyrektyw bezpieczeństwa dla PHP (url_fopen off, open_basedir, wyłączenie funkcji PHP).
  4. Złe skonfigurowanie praw do plików.
  5. Niefiltrowanie wywołań albo brak programowego firewalla (jak mod_rewrite rules czy mod_security).

Błędy

  1. Niewpisywanie deklaracji ('_VALID_MOS') or die...
  2. Źle skonstruowana deklaracja include().

Chociaż kod Joomla! jest bezpieczny, jeżeli został prawidłowo skonfigurowany, rozszerzenia to świat różnej jakości i wieku. Jeżeli absolutnie nie ufasz developerowi, zawsze przejrzyj kod przed instalacją. Poniżej jest lista typowych obszarów takiego przeglądu

1. Jak złożone jest rozszerzenie?

Czym jest większe, tym bardziej prawdopodobne, że sprawi problemy. Powinieneś je przejrzeć bardzo dokładnie. Jeżeli nie potrafisz zrozumieć jak działa, nie ufaj mu.

2. Czy rozszerzenie czyta lub zapisuje pliki na Twoim serwerze?

Programy, które czytają pliki, mogą niechcący zmienić prawa dostępu, które ustawiłeś, lub przekazać wrażliwe informacje do włamywaczy. Programy, które zapisują pliki, mogą potencjalnie zmodyfikować lub zniszczyć istniejące pliki, albo zainstalować konie trojańskie.

3. Czy rozszerzenie współdziała z innymi programami Twojego systemu?

Na przykład wiele rozszerzeń wysyła e-maile w odpowiedzi na wysłanie danych formularza przez otwarcie połączenia z serwerem sendmail. Czy robią to w bezpieczny sposób?

4. Czy rozszerzenie działa z przywilejem suid (set-user-id)?

Generalnie to bardzo niebezpieczne, rozszerzenia muszą mieć poważny powód, by tak działać.

5. Czy rozszerzenie waliduje wszystkie wejścia użytkownika, takie jak w polach formularza i w URL?

6. Czy rozszerzenie używa prostych ścieżek przy wywołaniu zewnętrznych programów?

Stosowanie zmiennej środowiskowej PATH dla rozwiązania nazw ścieżek jest niebezpieczną praktyką.

7. Czy rozszerzenie jest wystarczająco zabezpieczone przed bezpośrednim dostępem przez URL?

Na przykład: www.twojastrona.com/components/com_bad_extension.php?tu_duzo_zlego_kodu

8. Czy rozszerzenie jest odporne na zdalne wklejenie pliku?

9. Czy rozszerzenie jest odporne na SQL injections (wstrzykiwanie SQL)?

10. Czy rozszerzenie jest odporne na ataki Cross Site Scripting (XSS)?

11. Czy rozszerzenie potrzebuje włączenia register_globals, lub Joomla! RG Emulation?

Jeśli tak to prawdopodobnie naruszono pkt 7.

12. Czy rozszerzenie zapewnia dostęp do bazy danych wysokiego poziomu dla użytkowników o niskich prawach?

Na przykład, czy pozwala gościom lub użytkownikom zarejestrowanym przeglądać dane przeznaczona dla wydawców lub administratorów?

Dziękujemy za wkład

» Stefan Wajda [zwiastun],