PODSTAWY PORTALOWANIA,
CZYLI JAK NIE ZAPŁACIĆ FRYCOWEGO.
Część 2
Bezpieczeństwo.
Być
może poruszane przeze mnie zagadnienia nie są ułożone w jakiejś
logicznej kolejności ale myślę, że te podstawowe tematy możemy
sobie tasować. Zatem dziś poruszę kwestię bezpieczeństwa portalu
w sieci. Są to rzeczy, które powinny interesować głównie
techników/programistów ale dobrze by osoby zarządzające portalem
zdawały sobie sprawę z potencjalnych zagrożeń.
Poniżej
poruszę następujące zagadnienia:
a)
podatność systemów CMS na ingerencje poprzez „dziury”
b)
włamania na serwer/FTP
c)
zasady tworzenia zaplecza do zarządzania treścią
Ad.
a)
Przy doborze systemu
zarządzania treścią (CMS) należy zwrócić baczną uwagę przede
wszystkim na jego poziom bezpieczeństwa. Wynika to bezpośrednio z
kodu źródłowego, więc bez znajomości danego języka
skryptowego/programowania nie da się tego tak łatwo ocenić. Na
szczęście można znaleźć wiele rad na stronach o tematyce
darmowych CMS. Główną zaletą darmowych systemów ma być ich
otwarty kod, dzięki czemu każdy będzie mógł coś ulepszyć,
dopisać wtyczkę czy moduł. Co prawda powstaje takich dodatków
bardzo wiele ale prawie całkowicie brakuje kontroli ich jakości.
Nagminną rzeczą jest umieszczanie na oficjalnych stronach darmowych
CMS dodatków napisanych przez początkujących programistów, którzy
nie mają żadnego pojęcia o bezpieczeństwie. Dlatego też odradzam
takie systemy jak „Joomla!”, który bodaj ma najwięcej
dostępnych dodatków i najwięcej dziur. Dodatkowo bardzo łatwo
takie dziury znajdują hackerzy i wykorzystują je do swoich celów.
Przykład: dodatek GCalendar do „Joomli!”.
Nieco inaczej jest przy
płatnych CMS. Tutaj kod jest zamknięty a nawet często
zaszyfrowany, co uniemożliwia wgląd do niego osobom trzecim. Jeżeli
do tego jest napisany solidnie to możemy być spokojni o
bezpieczeństwo naszych danych. Dobrym pomysłem jest też
samodzielne napisanie prostego systemu. Należy jednak wcześniej
zaznajomić się z zasadami tworzenia bezpiecznego oprogramowania.
Ad. b)
Na temat włamań powiem
krótko. Z punktu widzenia hostingobiorcy nic nie poradzimy na
włamania hackerów na serwer. Jeżeli takie rzeczy zdarzają się
często należy zmienić hosting na inny. Natomiast jeżeli włamania
mają miejsce poprzez nasze FTP to powinniśmy zadbać o
bezpieczeństwo haseł. Najlepiej nie zapamiętywać żadnych haseł
w programach do łączenia się przez FTP i dbać o to by w naszym
systemie/komputerze nie zagnieździł się jakiś złośliwy program
szpiegujący. Tutaj pomogą na pewno programy antywirusowe,
antyspyware itp. oraz zdrowy rozsądek. Używając legalnego
oprogramowania z wiarygodnych źródeł ryzyko infekcji komputera
spada do minimum!
Ad. c)
Czas na jakieś detale
jeśli chodzi o tworzenie bezpiecznego kodu. Zacznę od poruszenia
tematu JavaScript. Otóż skrypty JS wykonują się po stronie
klienta, na komputerze odwiedzającego stronę przez przeglądarkę
internetową. Tworząc funkcjonalności w JS pamiętajmy o tym, że
nie możemy zdać się tylko na JS z newralgicznymi rzeczami, takimi
jak logowanie, sprawdzania wprowadzonych danych do formularzy itp.
JS służy wyłącznie jako pomoc w minimalizacji przeładowań
strony i żądań do serwera. Wyobraźmy sobie, że w każdej
przeglądarce można wyłączyć obsługę JS i wtedy jakiekolwiek
zabezpieczenia zawarte w takich skryptach nie działają! Co więcej
skrypty takie można po stronie klienta zmodyfikować i wykonać.
Dlatego bądźmy ostrożni co w nich zamieszczamy.
Druga rzecz to
formularze. Są one niezbędne przy przepływie informacji między
klientem i serwerem (czy też docelowo bazą danych). Budujmy kod
tak, by wykorzystywał formularze i przesyłał dane metodą POST. Bo
jeżeli oprzemy nasze funkcjonalności tylko na parametrach z pasku
adresu (GET) to możemy bardzo szybko się rozczarować tym, że np.
przypadkowo wpisane parametry w linku przez dowolnego użytkownika
kasują nam dane! Zatem stosujmy parametry GET tylko do wyświetlania
treści i formularzy (np. administracyjnych) a wykonywanie
konkretnych akcji edycji czy wstawiania treści do bazy za pomocą
metody POST. Parametry takie w obu przypadkach są przekazywane do
skryptu/programu na serwerze gdzie należy najpierw zadbać o ich
skontrolowanie ze względu na typ danych. Upewnimy się w ten sposób
min. czy ktoś nie próbuje dokleić nam do skryptu fragmentu
zapytania SQL by wyrządzić szkody w naszej bazie danych (SQL
Injection). Przesyłanie parametrów za pomocą POST pozwoli nam na
łatwiejszą kontrolę dostępu do funkcjonalności administracyjnych
portalu. Mówiąc prościej jeżeli użytkownik nie jest uprawniony
np. do edycji treści to bez możliwości ujrzenia i wysłania
formularza nic nie zdziała, co już nie jest takie oczywiste gdy
zbieramy dane wyłącznie z paska adresu przeglądarki.
Dodatkowo do popularnych
funkcjonalności zalecam stosowanie ogólnodostępnych bibliotek czy
też gotowych rozwiązań dostarczanych przez konkretne środowisko
IDE. Komponenty takie zazwyczaj są maksymalnie dopracowane i
napisane przez znakomitych fachowców.
Kamilos |