Bezpłatne skrypty PHP z pewnością przynoszą wiele korzyści. Otwarcie sklepu internetowego czy portalu zajmuje tylko chwilę. Niestety, bezpłatne niekoniecznie oznacza bezpieczne. Zobaczmy, jak bez ogromnej wiedzy programistycznej zabezpieczyć wartościową stronę, dochodowy sklep czy cenne forum przed atakami hakerów.

Dziś już tylko pasjonaci wpadają na pomysł, by własnymi siłami stworzyć, na przykład, forum dyskusyjne. Po pierwsze oznaczałoby to konieczność włożenia ogromu pracy, która nie zwróciłaby się w postaci zysków. Po drugie oprogramowanie autorskie oferowałoby najwyżej połowę funkcjonalności w porównaniu do najpopularniejszego phpBB. Takich gotowych skryptów oferujących określone usługi jest setki. Łączy je jedna cecha: są podatne na ataki.

Musimy uświadomić sobie, jaką drogę przechodzi oprogramowanie tworzone na licencji open source (z otwartym źródłem). Do projektu zasiada najczęściej jeden lub kilku-, kilkunastu programistów, w zależności od skali projektu. Każdy z nich tworzy określony fragment kodu, który następnie składany jest w całość, opierając wszystko o schematy założeń, poczynione na początku prac. Oprogramowanie wysyła się na rynek poprzez publikację w sieci.

Co oczywiste, zainteresowani webmasterzy instalują je na swoich stronach. Odkrywane są błędy i dziury w zabezpieczeniach, dodawane nowe funkcje. W ten sposób kod jest aktualizowany i odsyłany z powrotem do webmastera. To od właściciela serwisu zależy czy zainstaluje nową wersję oprogramowania, czy też zdecyduje się pozostać przy starej.

Na dwoje babka wróżyła

Oprogramowanie należy aktualizować, ponieważ:

• jest odporne na luki odkryte w poprzednich wersjach,
• zawiera nowe funkcje, które mogą okazać się cenne dla użytkowników korzystających z usługi,
• dane, które gromadzimy w bazach są wartościowe i w razie przejęcia mogłoby zagrozić naszej pozycji w sieci,
• programiści najczęściej oferują łatki (ang. patche), które można zainstalować w niecały kwadrans,
• programiści przepisali oprogramowanie i teraz jest szybsze.

Oprogramowania nie należy aktualizować, ponieważ:

• zawiera więcej funkcji, które mogą szybko okazać się podatne na ataki,
• więcej funkcji to mniejsza wydajność aplikacji i serwer mógłby sobie z takim obciążeniem nie poradzić (strzelamy do własnej bramki),
• aplikacja była już modyfikowana (dostosowywana do potrzeb strony) i aktualizacja mogłaby przynieść niepożądane skutki.

Kto jest winny

Czy to forum dyskusyjne, czy cały system portalowy, każdy skrypt musi być oparty o określony język programowania i bazę danych, która przechowuje wszystkie potrzebne informacje (dane klientów, zamówienia itd.).

W polskich realiach to PHP 4.x.x i MySQL.4.x. Te z kolei do pracy wymagają jeszcze serwera (najczęściej Apache) i linuksopochodnego systemu operacyjnego. Cała ta technologia tworzy szereg punktów, o których zabezpieczenie starają się:

• administrator serwera, będący pracownikiem firmy hostingowej,
• webmaster odpowiedzialny za instalację i sprawowanie kontroli nad swoją stroną WWW,
• grupa programistów przygotowująca oprogramowanie dla webmastera.

Do zadań administratora należy:

• aktualizowanie oprogramowania zainstalowanego na serwerze, tak by nie zaszkodzić dotychczasowym skryptom, a zapewnić lepszą ochronę przed atakami,
• instalowanie dodatkowych rozszerzeń i modułów, które pozwalają webmasterom wykonywać bardziej zaawansowane zadania,
• konfigurowanie zainstalowanego oprogramowania, by oferowało maksymalnie dużą swobodę działania przy optymalnym poziomie ryzyka,
• pasywną pomoc (oferowanie rad) webmasterowi w bezpiecznym konfigurowaniu jego oprogramowania, lecz w czasie nie dłuższym niż 1 dzień od zadania pytania,
• zapewnienie odpowiedniej wydajności łączy i serwera, by twoje aplikacje nie wyświetlały błędów i nie uszkadzały baz danych.

Jeżeli administrator nie spełnia jednego z tych założeń, to twój biznes jest zagrożony i powinieneś zastanowić się nad zmianą firmy hostingowej.

Do zadań webmastera należy:

• dbanie o odpowiedni poziom bezpieczeństwa własnych danych poprzez stosowanie odpowiednio skomplikowanych haseł, wielu kont i innych zabezpieczeń,
• instalowanie oprogramowania o wiadomym pochodzeniu, które stwarza pozory oprogramowania mogącego zapewnić bezpieczeństwo witryny, serwera.

Opierając swój sklep internetowy np. o osCommerce, własne oprogramowanie lub jakiekolwiek inne płatne skrypty, tylko ty ponosisz ryzyko ataku. Jednak ryzyko to rozkłada się za każdym razem inaczej.

Programista powinien:

• mieć kilkuletnie doświadczenie w pisaniu aplikacji,
• dołożyć wszelkich starań, by pisane przez niego oprogramowanie było maksymalnie bezpieczne, przez co rozumie się odpowiednią walidację danych (sprawdzenie, czy struktura informacji pobranej od użytkownika jest prawidłowa) i określenie punktów, w których wymagane jest zapewnienie szczególnego bezpieczeństwa przepływających danych,
• zasugerować webmasterowi kroki jakie powinien poczynić w celu uzyskania większego bezpieczeństwa jego aplikacji.

Programista może być osobą anonimową, twoim zleceniobiorcą czy pracownikiem. Jeżeli masz taką możliwość, najpierw sprawdź, a później zapytaj w jaki sposób rozwiązał problem bezpieczeństwa. Pamiętaj, że programować w PHP można już po kilku godzinach nauki. Do perfekcji dochodzi się latami.

Jak zmierzyć bezpieczeństwo?

Problem bezpieczeństwa strony może wydawać się mało złożony lub wręcz odwrotnie, bardzo skomplikowany, a już szczególnie dla kogoś, kto nie miał nigdy nic wspólnego z prawdziwym programowaniem. Jednak istnieje taki prosty przykład, by pokazać na czym ogólnie polega problem bezpieczeństwa. Otwórz swoją stronę i poszukaj na niej formularzy. Mogą to być formularze służące do:

• wysyłania e-maila do obsługi klienta, tzw. formularz kontaktowy,
• komentowania i wydawania opinii do przedstawionego wcześniej materiału (artykułu, zdjęcia, filmiku itp.).

W pierwszym przypadku wypełnij formularz kontaktowy bez zwracania uwagi na treść. Kliknij Wyślij. Gdy na stronie pojawi się podziękowanie za wysłanie informacji, odśwież stronę. Wówczas ukaże się pytanie, czy jeszcze raz wysłać te same dane. Zaakceptuj. Zrób tak kilka, kilkadziesiąt razy.

Teraz przejdź do swojego konta mailowego i zobacz ile wiadomości dostałeś. Pomyśl, co by się stało, gdyby ktoś napisał program, który wyśle do ciebie nie 10, a 100 tys. różnych wiadomości. Nie będziesz ich w stanie łatwo odfiltrować, a na wykasowanie zawartości całego konta e-mail przecież nie możesz sobie pozwolić.

Jeżeli masz na stronie formularz do dodawania nowych komentarzy, sprawdź, czy działa podobna sztuczka. W tym przypadku na pewno twój programista zadbał o rozwiązanie tego błahego problemu. Na pewno też nie zezwolił na umieszczanie takiego kodu HTML w treści komentarza:

Cześć!

Gdyby tego nie zrobił, użytkownicy mogliby publikować komentarze o dowolnym formatowaniu, np. publikując tekst o bardzo dużych literach. To może nie tylko spowodować gorszą czytelność strony, lecz także zaburzyć jej rozmiary czy proporcje.

Możliwości jest więcej, bo do treści komentarza można dołączyć skrypt JavaScript.

Można go uruchomić niekoniecznie posługując się tagiem {html}script>{/html}. O ile nie są to przykłady drastyczne i mogące sparaliżować twoją stronę, to pokazują jak blisko nas znajduje się problem bezpieczeństwa.

Jeżeli strona nie istnieje w sieci przez godzinę, to w tym czasie nie zarabia. Dlatego należy rozważyć za i przeciw, decydując się na oprogramowanie do obsługi sklepu internetowego czy portalu. Dochodziły do mnie głosy o włamaniu się na serwer, gdy w użyciu był system portalowy PostNuke. Absolutnie nie nakłaniam do rezygnacji z tego systemu.

Prawdopodobnie osoba, która uskarżała się na ataki nie zainstalowała nowszej wersji oprogramowania, dostępnej od dłuższego czasu.

Takie przypadki są nagminne, a odnalezienie witryny, która jest podatna na któryś z ataków nie jest trudne. Zwłaszcza że wszystkie luki i błędy są szczegółowo opisane na stronach z aktualizacjami. Jak łatwo się domyśleć, stanowi to znakomite ułatwienie dla hakerów. Niestety, skrypty, które swoimi rozmiarami przytłaczają każdego, muszą być bardziej narażone na ataki. Podobnych portalowych systemów-kolosów jest wiele.

Źródła oprogramowania

Temat bezpieczeństwa aplikacji internetowych, czyli np. skryptów PHP obsługujących sklepy internetowe, jest bardzo szeroki. Dlatego nie wytłumaczę jak dokonuje się bardziej skomplikowanych ataków. To wymaga wiedzy programistycznej. Należy jednak zdać sobie sprawę z różnicy pomiędzy oprogramowaniem:

• open source (określanym tu jak bezpłatne),
• na licencji (kupujesz program, np. sklep internetowy od firmy),
• pisanym na zamówienie.

Oprogramowanie z otwartym źródłem z jednej strony jest najmniej bezpieczne, bo dostęp do jego źródła mają wszyscy, z drugiej jednak nad bezpieczeństwem takiej aplikacji czuwa największe grono ludzi, a ilość błędów odnajdywanych w takich aplikacjach jest największa. Jeżeli decydujesz się na gotowe oprogramowanie typu open source sprawdź:

• jak szybko po ukazaniu się błędu pojawia się łatka poprawiająca go,
• jak często pojawiają się nowe wersje oprogramowania,
• czy w programie pojawia się więcej błędów niż u konkurencji (uzależnij to od popularności oprogramowania),
• jak ważną funkcję będzie pełnił na twojej stronie ten skrypt (może lepiej go kupić lub zamówić u programisty).

Oprogramowanie sprzedawane na licencji, czyli np. sklep kupiony w średniej wielkości firmie, ma najwięcej cech bezpiecznego oprogramowania. Kod takiej aplikacji może być niejawny, co oznacza, że nie mamy dostępu do jej źródła.

Skrypt od podszewki zna zatem tylko konkretna grupa ludzi pracujących w danej firmie nad rozwojem oprogramowania. To uniemożliwia hakerowi wyłapywanie dziur w oprogramowaniu poprzez analizę kodu źródłowego, lecz także i nam blokuje możliwość dokonywania jakichkolwiek zmian.

Oczywiście zakodowanie źródła nie oznacza, że w takim oprogramowaniu nie ma błędów. Po prostu trudniej je znaleźć. Niestety, gdy ktoś odkryje błąd w oprogramowaniu, może np. szybko przejąć kontrolę nad wszystkimi sklepami opartymi na danym produkcie. Łatwo takie sklepy odróżnić, ponieważ zazwyczaj firma reklamuje się poprzez umieszczenie nazwy sklepu w stopce witryny. Ponadto sklepy jednego producenta wyglądają najczęściej bardzo podobnie. Przyjęty przez firmę układ sklepu nie zmienia się znacząco, nawet jeżeli zastosowano inną grafikę.

Oprogramowanie pisane na własną rękę bądź na zlecenie ma też zgoła inną charakterystykę. Kod programu jest najczęściej tworzony przez jedną lub kilka osób, które nie mają żadnego interesu w tym, by napisaną aplikację udostępniać innym. Można więc założyć, że dostęp do takiego programu od strony jego źródła jest niemożliwy.

Pozostaje więc kwestia bezpieczeństwa, które zachował, czy raczej zaimplementował programista. Najczęściej po języki takie jak PHP sięga duża grupa osób. Zdarza się, że ich programy to zlepek nieuporządkowanego kodu, nie mającego nic wspólnego z inżynierią oprogramowania.

Również i w tym przypadku nie można tego łatwo ocenić, zwłaszcza jeżeli nie zajmujemy się zawodowo programowaniem. Dlatego warto w tym przypadku bazować na portfolio autora, czyli jego dotychczasowych osiągnięciach. Przejrzenie sposobu działania kilku aplikacji napisanych przez programistę daje pewnego rodzaju obraz jego umiejętności. Proszę nie zwracać przy tym uwagi na walory estetyczne, lecz użytkowe.

Instalacja instalacji nierówna

Pobrałeś skrypt z sieci i zabierasz się za instalację. Sprawdź czy:

• pobrałeś jego ostatnią wersję, najbardziej aktualną,
• czy skrypt nie jest w wersji alfa, beta lub gamma (to są wersje testowe, lepiej zainstalować wcześniejszą, ale sprawdzoną),
• jaką wartość przedstawia dla ciebie skrypt i czy nie może być zastąpiony innym (przeanalizuj inne możliwości).

Jeżeli to system portalowy lub sklep internetowy to:

• umieść go na innym koncie FTP z odmiennym hasłem (jeżeli masz serwer wirtualny, to taka operacja utworzenia nowego jest bezpłatna i łatwa do wykonania),
• załóż osobną bazę danych pod instalowaną aplikację, chyba że musisz korzystać z już dostępnych w niej informacji.

Zwróć uwagę na możliwości konfiguracyjne. Warto poświęcić temu procesowi trochę więcej czasu, choć oczywiście musisz zagłębić się w dokumentację. Niestety, w znakomitej większości po angielsku (dotyczy również projektów tworzonych nawet w całości przez Polaków).

Serwer potrafi

Dzisiejsze serwery wirtualne oferują szereg zabezpieczeń, które są w standardzie. Do nich należą:

• bezpieczny katalog dostępny tylko na hasło (możesz dodatkowo zabezpieczyć swój panel administracyjny poprzez ustawienie hasła na ten katalog),
• protokół SSL, czyli szyfrowanie połączenia pomiędzy stroną a użytkownikiem (używany głównie do zabezpieczania transakcji kartami kredytowymi, do konta w banku, czy logowaniu do własnego systemu pocztowego; pamiętaj, że protokół SSL nie zwiększa bezpieczeństwa skryptów jako takich, nie pozwala tylko podsłuchać danych wymienianych pomiędzy klientem a serwerem),
• autoryzacja poczty wychodzącej (wszystkie wiadomości e-mail, które wysyłasz przez protokół SMTP, muszą przejść przez proces autentykacji – podanie loginu i hasła do konta na tym serwerze; ten proces upewnia, że nikt nie wyśle do klienta e-maila rzekomo od ciebie),
• zapobieganie HotLinkowaniu, które polega na tym, że nikt nie może umieścić zdjęcia na swojej stronie, które jest wczytywane z twojego serwera (transfer kosztuje!).

Oprócz powyższej listy kryje się ogromna grupa zagadnień programistycznych, które pozwalają zwiększyć bezpieczeństwo twojej aplikacji. Lecz to zadanie musisz powierzyć programiście.

Obrazki zabezpieczające

Klienci, którzy powierzają programiście napisanie aplikacji, najczęściej nie zdają sobie sprawy z dostępnych możliwości. Dlatego warto wiedzieć o możliwości zabezpieczania formularzy, jaką stanowią obrazki zabezpieczające (z ang. capcha).

Polega on na tym, że zanim wyśle się formularz internetowy, trzeba przepisać z małego obrazka ciąg znaków. Takie zabezpieczenie uniemożliwia stosowanie ataków DoS (Deny of Service), czyli takich, które przeciążają serwer w wyniku zbyt wielu poleceń wykonania czasochłonnego zadania (np. wysłania formularza rejestracji).

Istota ataku

Atakiem jak dowolne działanie poczynione w serwisie, które przynosi niepożądane dla właściciela strony skutki. Wyobraź sobie, że na twojej stronie była luka w oprogramowaniu i przechwycono hasło do bazy danych.

Włamywacz zalogował się do bazy i pobrał z niej wszystkie dane. O całej sytuacji nic nie wiedziałeś i prawdopodobnie nigdy się nie dowiesz. Konkurencja może uciekać się do różnych metod, by przejąć wartościową treść z twojej strony. J

eżeli masz rozległą bazę żartów, filmów czy artykułów, nie zdziw się, gdy pojawi się ona na innej stronie. Co prawda nie zawsze przekopiowanie treści strony musi oznaczać przeforsowanie dostępu do bazy danych, lecz najczęściej to właśnie złe zabezpieczenia powodują, że łatwo przechwycić hasło do bazy.

Przykłady problemów

Problem 1: Strona przestaje działać. Odnośniki są nieprawidłowe albo strona jest niespójna, brakuje pewnych elementów lub wyświetlane są błędy PHP.

Problem 2: W miejsce strony głównej witryny pojawia się strona sporządzona przez hakera.

Problem 3: Serwer jest pusty, brak jakichkolwiek danych na FTP. Baza danych wyczyszczona (przypadek bardzo rzadki).

Problem 4: Komunikat na każdej podstronie: \”Nie można uzyskać połączenia z bazą danych\” lub błędy PHP związane z pobieraniem danych z bazy. Baza danych wyczyszczona lub wszystkie dane podmienione przez bezwartościowe ciągi znaków.

Przyczyna:

Oprócz przypadku drugiego przyczyną problemu niekoniecznie musi być atak. Może to być zwykłe zaniedbanie webmastera, błąd programisty, przeciążenie serwera itp. Przyczynami występowania błędów w przypadku ataku mogą być:

• skorumpowane pliki konfiguracyjne,
• usunięte lub podmienione szablony, na których opiera się strona,
• usunięte całkowicie lub częściowo pewne fragmenty bazy danych.

Rozwiązanie:

1. Określenie rodzaju problemu:
   • problem z bazą danych (daje oznaki ingerencji zewnętrznej),
   • problem ze skryptami (wyświetlane są błędy niezwiązane z pobieraniem danych z bazy, np. błędy ładowania szablonów, nieprawidłowe adresy odnośników lokalnych),
   • problem z pracą serwera (aktualizacja oprogramowania, która mogła wywołać błędy).
2. Zmiana hasła do bazy danych (hasło do konta FTP zazwyczaj nie jest przechowywane wewnątrz oprogramowania witryny).
3. Przejrzenie bazy danych ze zwróceniem uwagi na ilość tabel i ich zawartość (czy przypadkiem nie ma pustych tabel).
4. Jeżeli baza została zniszczona lub jest nieprawidłowa, należy zrobić kopię tego, co aktualnie się w niej znajduje i poprosić administratora o przywrócenie kopii zapasowej (może to być kopia sprzed 24, 48 godz. lub z innego okresu, w zależności od systemu tworzenia backupów) – powinno to trwać maksymalnie godzinę,
5. Jeżeli wystąpił problem z punktu 2 na ogół zawiniły skrypty, tj. w którymś z nich znajduje się luka, która umożliwiła atak.
6. Jeżeli doszło do uszkodzenia skryptów, postępujemy analogicznie jak w punkcie 4.
7. Aktualizacja istniejących skryptów (portal, sklep internetowy), zaaplikowanie łatek bezpieczeństwa. Jeżeli projekt przygotowywał niezależny programista, należy poprosić go o sprawdzenie, czy w swoich skryptach:
   • pamiętał o zablokowaniu wyświetlania błędów na stronie przez interpreter PHP lub innego języka,
   • korzystał z zaawansowanej walidacji, czyli dokładnie sprawdził wszystkie zmienne wejściowe (najlepiej przy użyciu wyrażeń regularnych), czyli danych, które wprowadza użytkownik (to dotyczy nie tylko formularzy, lecz także adresu URL),
   • zna mechanizm działania ataków typu SQL Injection; w jaki sposób kontroluje dane pochodzące od użytkownika, na podstawie których budowane jest zapytanie do bazy,
   • czy korzysta z niebezpiecznych funkcji exec(), system(), passthru() (dla PHP) i do czego są mu one potrzebne,
   • czy przechowuje w bazie danych hasła i inne kluczowe dane w sposób jawny, nie poddając ich procesowi szyfrowania.
8. Zadbanie o przywrócenie danych, które zostały utworzone począwszy od momentu przywrócenia bazy do chwili zaatakowania serwisu. Wykorzystujemy do tego celu pozostałości po uszkodzonej bazie danych. Zajęcie dla programisty lub doświadczonego webmastera.

Stare, dobre hasło

Temat ten wraca jak bumerang za każdym razem, gdy omawiane jest bezpieczeństwo. Nie jest powodem do chluby, że większość posiadaczy kont mailowych czy stron WWW korzysta z haseł, których odgadnięcie to kwestia programu ze słownikiem języka polskiego (można go ściągnąć bezpłatnie z internetu – wszystkie odmiany, kilkadziesiąt MB danych).

Przekonań nie zmienię. Przynajmniej staraj się używać innego hasła do łączenia się z serwerem pocztowym, a innego do uzyskiwania dostępu do swojego serwera WWW, na którym trzymasz stronę. Ponieważ do bazy danych nie będziesz logował się bardzo często, zadbaj o zastosowanie tam najsilniejszego hasła. Nie jest niczym złym stosowanie takich haseł: \”l38c21!ghvq\”, o ile masz pamięć programisty/administratora lub karteczkę z hasłami na biurku.