4 Bezpieczeństwo stron WWW 6 minut czytania

Zwiększanie poziomu bezpieczeństwa stron www

Reklama Na Blogach

Dawno nie było wpisu poświęconego bezpieczeństwu stron www, a że kilka dni temu dostałem najnowszy numer – 11/2008 - czasopisma HACKIN9 to mi trochę ułatwiło sprawę. Ułatwiło, bo w tym numerze jest artykuł poświęcony bezpiecznym stronom. Dzisiaj skupię się na kilku fajnych sztuczkach z katalogami, plikami przechowującymi dane wrażliwe (loginy i hasła) do poprawnego działania naszej aplikacji i bezpieczeństwie bazy danych.

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).




Akceptuję politykę prywatności

Raz w miesiącu e-mail z najlepszymi artykułami

Zdjęcie autora wpisu - Piotr Cichosz

Piotr Cichosz — autor wpisu

Frontend developer. Tworzę zaawansowane systemy webowe w JS. Swoją wiedzę nt. SEO wykorzystuję do rozwijania własnych projektów (z lepszym lub gorszym efektem). Dużo eksperymentuję i staram się określić jak bardzo można nagiąć cierpliwość algorytmów Google (:. Prowadzę teraz bloga technologicznego oraz bloga o Apple

Komentarze 4

author tomislater www 31.10.2008 17:42:24

Też czytałem ten numer, coś za bardzo streściłeś ten artykuł :D

author LBO www 31.10.2008 21:05:55

A ja się zastanawiam, czemu akurat za przykład podałeś Agavi :> Akurat uważam go za jeden z bezpieczniejszych frameworków... w dodatku, o losie, jest on niszowy, więc wątpię, że potencjalny hakier będzie wiedział co i jak znaleźć.

Pozdrawiam

P.S Struktura Agavi jak (i chyba Symfony) naturalnie skłania ku składowaniu plików projektu ponad public_html.

author shpyo www 31.10.2008 22:40:16

Hehe, agavi dałem jako przykład, bo za sprawą jednego ewangelisty zapoznałem się z frameworkami, a dwa miałem go pod ręką. Co do struktury tych frameworków to jest dokładnie tak jak piszesz - w taki właśnie sposób są "stworzone"

author Paweł Ryznar www 06.11.2008 14:25:44

ciekawy artykuł, ale tak jak autor zaczął, większość rzeczy jest powszechnie znana, gorzej ze stosowaniem

Odnośnie tego numeru HACKIN9 i bezpieczeństwa do dużo ciekawszy jest artykuł "Hakowanie RSS feeds", a na to jeszcze mniej ludzi zwraca uwagę.

Dodaj komentarz