Zwiększanie poziomu bezpieczeństwa stron www

Poprawnie zaprojektowana aplikacja wszystkie dane będzie przechowywać w jednym miejscu, jak to zostało ujęte w hacking9 - centralizacja danych wrażliwych. Trzymanie wszystkich danych w różnych plikach, to generalnie zły pomysł. Jeżeli intruz w jakiś sposób zdobędzie dostęp do naszego serwisu lub struktury plików, to wszystko ma ładnie podane na tacy – to raz. Kolejna sprawa to modyfikacja takich danych. Jeżeli chcemy zmienić hasło do bazy danych, to trzeba zmieniać je w X miejscach.
Mając takie dane np. do bazy danych, to już tylko wyobraźnia go ogranicza z tym co chce zrobić z tymi danymi. Zrobić można dużo, pobrać maile użytkowników i na przykład sprzedać spamerowi. Można jeszcze umieścić jakieś kompromitujące informacje a nawet szantażować. Także z takimi danymi można poszaleć, a im większy serwis lub firma to robi się ciekawiej.

Artykuł, który przykuł moją uwagę to „Bezpieczeństwo aplikacji internetowych”. Opisane są tam metody skutecznej ochrony tych wrażliwych danych. Autor w tym artykule pisze, że dostęp do danych w katalogu public_html/ jest różny. Wszystko zależy od ustawień serwera. W zależności od serwera, znajdować się tam mogą specjalne katalogi, do których można się dobrać poprzez wpisanie go w adresie strony np. www.domena.pl/stats. Ten konkretny katalog stats/, to systemowy katalog ze statystykami zbieranymi przez serwer. Teraz, jeżeli ktoś zna np. framework w którym jest napisana aplikacja, to w podobny sposób (znając strukturę plików) można uzyskać dostęp do plików konfiguracyjnych. W frameworku Agavi plik xml z danymi do bazy danych jest pod tą ścieżką: app/config/databases.xml – teraz jeżeli nie ma ustawionych odpowiednich uprawnień do plików xml (np. w .htaccess) to... patrz akapit wyżej.

Do czego zmierzam. Ważne jest aby w naszej aplikacji maksymalnie utrudnić dostęp do tych wrażliwych danych. W artykule jest podpowiedź, aby wszystkie pliki aplikacji (klasy, configi) przechowywać w katalogu wyżej, a w pliku index.php (który jest w public_html/) umieścić tylko jedną funkcję – include().
Ta sztuczka pomimo swojej prosty – paradoksalnie – jest rzadko stosowana. Z tym stwierdzeniem autora zgadzam się w zupełności, bo widziałem już różne skrypty pisane przez różne osoby. Ciężko się przyznać, ale do pewnego momentu, też tego nie robiłem. Pamiętacie aferę z bankiem? Tutaj takie rozwiązanie na pewno by pomogło!

Co w przypadku uzyskania dostępu do tych danych (np. baza danych)? Odpowiedź jest prosta – minimalne przywileje dla użytkowników w obrębie bazy danych oraz jak sprytnie zauważył autor tego artykułu – rozrzucić dane po kilku bazach danych. Ograniczenia poleją na tym, aby uniemożliwić intruzowi usunięcie danych czy nawet skasowanie tabel. A rozrzucenie danych to bardzo ciekawy pomysł, bo zwykła strona (produktowa, dla klientów) potrzebuje tylko tak naprawdę odczytywać informacje z bazy. Zaś dla panelu administracyjnego jest tworzony inny użytkownik z nowymi prawami dostępu.

Artykuł mi trochę rozjaśnił w sprawach bezpieczeństwa stron, pokazał kilka nowych fajnych pomysłów. Ponadto znajdują się tam przykładowe metody sprawdzania danych wejściowych takich jak: ciągi znaków czy sprawdzanie licz (czy na pewno są liczbami).