Firmowy serwis internetowy – rozwiązania opensource kontra dedykowane – w kontekście bezpieczeństwa (cz. 1.)

24 października 2013, 11:25 | Teksty | komentarzy 7
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.
Od redakcji – publikujemy dzisiaj pierwsze dwie części tekstu bl4de, który otrzymał drugie miejsce w konkursie  organizowanym przez Securitum (2012r.) Dla przypomnienia: pierwsze miejsce zdobył vizzdoom publikacją „Kompendium bezpieczeństwa haseł” (część 2. oraz część 3.)

Wstęp

W dobie powszechnego dostępu do Internetu posiadanie własnego serwisu WWW stało się standardem. Dziś trudno znaleźć firmę, która nie posiada choćby prostej wizytówki w postaci np. statycznej strony internetowej w HTML. W przeważającej większości są to jednak rozbudowane serwisy oferujące m.in. korzystanie z oferowanych usług bądź dokonywanie zakupów bezpośrednio z poziomu przeglądarki internetowej. Platformy aukcyjne, systemy bankowości online, portale ogłoszeniowe to tylko niektóre spotykane rozwiązania wspierające firmy w ich działalności.

Rozwój technologii umożliwiających przeniesienie części bądź całości prowadzonej działalności do sieci przyniósł ze sobą nowy rodzaj zagrożeń: przestępczość internetową. Nie ma dnia, by serwisy monitorujące bezpieczeństwo systemów informatycznych nie informowały o nowych atakach. Powszechne stały się włamania do serwisów przechowujących istotne z punktu widzenia przestępców informacje: numery kont bankowych czy dane kart kredytowych. Dotyczy to w szczególności wszelkiego rodzaju sklepów internetowych, choć często są to też serwisy społecznościowe, a nawet blogi. W ostatnich latach bardzo dynamicznie rozwija się także czarny rynek, na którym handluje się wykradzionymi danymi.

Z tymi zjawiskami wiąże się nierozerwalnie pojęcie crackera, do którego często będę się tu odnosił.

(…) Słowo cracker używane jest (…) jako określenie osoby włamującej się na serwery w sposób niezgodny z prawem. Używanie go w tym kontekście propaguje społeczność hakerska, według której stawianie znaku równości między hakerami, a włamywaczami sieciowymi (co jest w mediach praktyką nagminną) jest błędne. Według społeczności hakerskiej, haker to komputerowy pasjonat o dużej wiedzy, który nie wykorzystuje jej do szkodzenia innym. Crackerem natomiast określają osobę łamiącą zabezpieczenia w celu dokonania przestępstwa (np. kradzieży danych osobowych z serwera).

za: Wikipedia

interesowanych odsyłam do zwięzłego, ciekawego porównania autorstwa Łukasza Michalika na jego blogu w serwisie GadżetoMania – Haker, cracker, phreaker. Czym różnią się od siebie sieciowi przestępcy? .

Nieświadomość wielu czychających zagrożeń związanych z prowadzeniem jakiejkolwiek działalności w Internecie to bolączka wielu organizacji od lat zajmujących się badaniem i propagowaniem idei bezpiecznej sieci. Jedną z takich organizacji jest OWASP – Open Web Application Security Project (będę często nawiązywał do projektów prowadzonych przez tę organizację). Zachęcam również do odwiedzenia strony domowej OWASP , warto zorientować się, czym jest organizacja, jakie stawia sobie cele, jakie projekty prowadzi oraz znaleźć inne informacje o tematyce i skali prowadzonej działalności. Programiści aplikacji webowych znajdą tam także masę praktycznych informacji o tym, w jaki sposób zapewnić maksymalne bezpieczeństwo tworzonych przez siebie projektów.

 

Garść statystyki

Inną organizacją zajmującą się tematyką bezpieczeństwa aplikacji internetowych jest WASCWeb Application Security Consortium. Podobnie jak OWASP, WASC prowadzi wiele zróż nicowanych projektów. Jednym z nich jest raportowanie statystyczny zagrożeń występujących w sieci, tworzony na podstawie testów penetracyjnych serwisów WWW. Na stronie Web Application Security Statistics można zapoznać się z pełną wersją raportu opracowanego przez WASC, tutaj przytoczę tylko kilka najistotniejszych faktów.

W 2008 roku organizacja WASC objęła badaniem 12186 witryn internetowych, na których stwierdzono łącznie prawie sto tysięcy (dokładnie 97554) różnych błędów związanych z bezpieczeństwem. Analiza wykazała, że 13% z tych witryn było zagrożonych włamaniem tylko przy wykorzystaniu narzędzi w pełni zautomatyzowanych, bez żadnej ingerencji ze strony cyberprzestępców. Około 49% z nich zawierało luki określane mianem wysokiego ryzyka, a 80-96% z nich było narażonych na odnalezienie takich luk po dokładniejszej analizie. Przeprowadzone testy wykazały średnio 91 luk bezpieczeństwa na jedną aplikację. Były to tak zwane testy white-box obejmujące między innymi szczegółową analizę kodu źródłowego aplikacji. W odróżnieniu od testów typu black-box, gdzie pentesterzy nie mają dostępu do kodu i muszą opierać się jedynie na wnioskach wyciągniętych z rezultatów działania oprogramowania do przeprowadzania testów penetracyjnych, podejście white-box daje możliwość kompleksowego zbadania aplikacji. Z różnych względów jednak testy white-box nie zawsze są możliwe. Więcej informacji na temat testów penetracyjnych można znaleźć na stronie Wikipedii – testy penetracyjne.

Z kolei OWASP cyklicznie publikuje listę dziesięciu najczęściej występujących błędów w aplikacjach internetowych. Z jej ostatnią wersją można zapoznać się pod adresem OWASP Top Ten. Od kilku lat w czołówce tej listy znajdują się dwa najbardziej popularne i występujące w praktyce błędy – wstrzykiwania kodu SQL (SQL Injection) oraz możliwość osadzania kodu JavaScript w treści strony (XSS – Cross Site Scripting) (Więcej o tych dwóch podatnościach w dalszej części opracowania).

Tylko te dwa zestawienia ukazują dobitnie, jak zaniedbywane jest bezpieczeństwo aplikacji webowych. Niepokojącym jest fakt, że za większość z nich są odpowiedzialni programiści tych aplikacji, czyli osoby, które z racji wykonywanej pracy powinny mieć największą wiedzę, jak ich unikać. Praktyka pokazuje, że tak się nie dzieje i trend ten, niestety, utrzymuje się na nie zmienionym poziomie. Na naszym rodzimym podwórku mogliśmy przekonać się o tym choćby wiosną 2012 roku, gdy światło dzienne ujrzały fakty związane z udanymi atakami na serwisy rządowe, m.in. Kancelarii Premiera, Sejmu czy Kancelarii Prezydenta. Do ich skutecznego przeprowadzenia doszło w wyniku zaniedbań ze strony osób, które powinny być odpowiedzialne za realizowanie prawidłowo zdefiniowanej polityki bezpieczeństwa.

 

Rodzaje firmowych serwisów internetowych

Zanim skupimy się na szczegółowej analizie problemów bezpieczeństwa serwisu WWW dla małego bądź średniego przedsiębiorstwa, spróbujmy scharakteryzować kilka najczęściej występujących typów oraz wskazać, jakie potencjalnie zagrożenia może nieść ze sobą każdy z nich.

1. Krótka systematyka

Poniższy podział jest dość umowny, a jego głównym kryterium jest ogólna funkcjonalność, jaką serwis udostępnia. Warto pamiętać, że poszczególne implementacje czy zastosowane rozwiązania techniczne mogą się od siebie znacznie różnić nawet w zakresie jednej kategorii.

  • wizytówka w postaci statycznej strony WWW – najczęściej wykonana przy użyciu technologii działających po stronie klienta (HTML, JavaScript, Flash itp.) nie daje praktycznie żadnych możliwości penetracji infrastruktury sieciowej, Problemem może być jedynie nieprawidłowa konfiguracja serwera WWW bądź FTP, służącego do transferu plików;
  • serwis z dynamicznie generowaną treścią (aktualności z życia firmy, artykuły specjalistyczne itp.) – wykonany najczęściej w postaci dynamicznie generowanej strony w językach PHP (php.net), ASP.NET (asp.net) bądź JSP/JSF (Java Server Pages/Java Server Faces – technologie wchodzące w skład Java Enterprise Edition – Java EE Web Application Technologies), często wspierany po stronie przeglądarki internetowej przez JavaScript (np. do walidacji wprowadzanych przez użytkowników danych). W przeważającej większości treść generowana na stronie przechowywana jest w bazie danych (najczęściej spotykane rozwiązanie). Potocznie tego typu serwisy określane są mianem systemów zarządzania treścią (CMS, Content Management System), choć oczywiście mogą spełniać także rolę bazy dla sklepu internetowego czy innego systemu;
  • platforma e-commerce (handel, usługi) – podobnie jak systemy CMS, z reguły mamy do czynienia z dynamicznie generowaną treścią pobieraną z bazy danych, ale w tym przypadku dochodzą jeszcze inne informacje, istotne z punktu widzenia działania: dane o klientach, produktach, zamówieniach, fakturach, statusach realizacji;
  • platforma CRM – platforma do zarządzania relacjami z klientami (Customer Relationship Management) – z reguły bardzo rozbudowana, wielomodułowa aplikacja zawierająca w sobie wszystkie procesy biznesowe w danej organizacji, wspomagająca pracowników w budowaniu i utrzymywaniu relacji biznesowych oraz wspomagająca ich na wszystkich etapach prowadzonej działalności;
  • serwis intranetowy (wewnętrzny, działający tylko w obrębie danej organizacji) z możliwością zdalnego dostępu – tu także znajdziemy elementy składowe wymienione w kategoriach powyżej. Ze względu na potencjał przechowywanych informacji (często poufne dokumenty o działalności firmy, dostępne jedynie dla pracowników) i ich szacunkową wartość np. dla konkurencji, intranet firmowy jest łakomym kąskiem dla cyberprzestępców.

Poza wymienionymi istnieją także systemy do zarządzania zasobami przedsiębiorstwa (ERP – Enterprise Resource Planning). Wszystkie rodzaje serwisów łączy jedno – cenne dane, do których można uzyskać dostęp z poziomu przeglądarki internetowej.

2. Funkcjonalność

Każde przedsiębiorstwo na pewnym etapie swojego rozwoju staje przed dylematem: jakiego rozwiązania użyć do realizacji firmowego serwisu internetowego. Jest to moment, gdy błędnie lub pochopnie podjęta decyzja może zaowocować wieloma problemami w przyszłości właśnie w kontekście bezpieczeństwa takiego serwisu. Nie mniej ważną kwestią jest wybranie takiego rozwiązania, które w przypadku wystąpienia problemów z zabezpieczeniami, umożliwi w miarę szybką reakcję, usunięcie błędu bądź zablokowanie możliwości jego wykorzystania. Dodatkowo istotną kwestią, o której dość często się zapomina, jest dobrze przemyślany system logowania zdarzeń, które zachodzą w samym serwisie czy w jego infrastrukturze sieciowej. Pozwoli to na podjęcie odpowiednich kroków w celu identyfikacji sprawców.

Zaczniemy od wskazania zalet i wad dwóch zaproponowanych w tytule rozwiązań:

  • opensource, czyli gotowej aplikacji o otwartym kodzie źródłowym dostępnej najczęściej nieodpłatnie
  • aplikacji dedykowanej, czyli zbudowanej na zamówienie).

Następnie przejdziemy do kwestii wymagań związanych ze zdefiniowaniem wymogów bezpieczeństwa, jakie powinna spełnić nasza aplikacja. Posłużę się w tym celu projektem prowadzonym przez OWASP – Application Security Verification Standard (ASVS). Jest to opracowanie definiujące cztery poziomy bezpieczeństwa aplikacji webowych wraz z wymaganiami, jakie muszą zostać spełnione, by można było ją zaliczyć do jednego ze zdefiniowanych poziomów. Wersję polskojęzyczną dokumentu można pobrać bezpośrednio ze strony projektu OWASP ASVS

W zależności od wymagań, jakie będzie musiała spełnić nasza aplikacja, musimy jasno określić, w jakim stopniu dane zgromadzone w infrastrukturze sieciowej, do których będzie można uzyskać dostęp z poziomu aplikacji, są istotne z punktu działania firmy i jaką wartość posiadają, niezależnie od tego, czy jest to raport finansowy, umowa z kooperantem czy plany lub koncepcja nowego produktu. Przykładowo, dostępne w firmowym serwisie WWW informacje na temat aktualnych wydarzeń w firmie (przechowywane jako rekordy w bazie SQL) nie są wartościowe z punktu widzenia atakującego. Jedynym zagrożeniem może tu być możliwość podmiany treści bądź wykasowania takiej informacji z serwisu, jeśli został nieprawidłowo zaimplementowany mechanizm edycji takich wpisów (np. bez konieczności logowania się) albo jeśli sam mechanizm logowania jest prosty do obejścia (np. bazuje na ciasteczku przechowywanym po stronie przeglądarki informującym serwer, że użytkownik jest zalogowany bądź nie).

Klienci firmy mogą też poprzez witrynę uzyskiwać dostęp i pobierać informacje kluczowe z punktu widzenia działalności firmy – szczegóły kontraktów, dokumenty sprzedaży itp. Tu jakikolwiek nieuprawniony dostęp może już za sobą pociągnąć wymierne, negatywne skutki (firma prowadząca konkurencyjną działalność może na bazie takich informacji przygotować korzystniejsze oferty i „podkupić” klientów zaatakowanej firmie).

Jako punkt wyjścia do dalszej analizy zastosowanych rozwiązań przyjmiemy najczęściej dziś spotykany scenariusz ataku: agresor, poprzez błędnie zaprojektowaną i wykonaną aplikację internetową próbuje uzyskać dostęp do danych znajdujących się w popularnej, relacyjnej bazie danych obsługiwanej w języku SQL (MySQL, PosgreSQL, Oracle, MSSQL):

CRACKER –> aplikacja –> DANE (serwer SQL)

Zobacz też: druga część tekstu.

Rafal “bl4de” Janicki [bloorq<at>gmail.com]

O autorze

Rafał ‚bl4de’ Janicki: z komputerami i programowaniem związany od 1992 roku, gdy rodzice zakupili mu pierwszy 8-bitowy komputer. Samouk, programista aplikacji webowych, domorosły badacz zabezpieczeń serwisów internetowych. Gdy nie śpi – z reguły jego palce spoczywają na klawiaturze :)
Od 2007 roku zawodowo związany z programowaniem. W swojej karierze pracował m.in. w Wirtualnej Polsce, obecnie jako JavaScript developer w brytyjskiej firmie zajmującej się oprogramowaniem dla sektora finansowego.
W 2012 roku Autor tego cyklu artykułów zdobył 2. miejsce w konkursie zorganizowanym przez Securitum. Tekst opublikowany na licencji CC – uznanie autorstwa.

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. SebaVegas

    Bardzo fajny art (obie części). Nie zgodzę się jednak z „… Niepokojącym jest fakt, że za większość z nich są odpowiedzialni programiści tych aplikacji, czyli osoby, które z racji wykonywanej pracy powinny mieć największą wiedzę, jak ich unikać…”. Brak zabezpieczeń, lub ich niepoprawne zastosowanie nie wynika ze słabej wiedzy programistów na temat bezpieczeństwa. W Polsce pomijany (bądź niewystarczające środki) jest bardzo ważny etap wytwarzania oprogramowania – testowanie, tu też testowanie bezpieczeństwa. Właśnie myślenie, że programista jest dobry i sobie poradzi z zabezpieczeniami, przez co nie zrobimy testów (bo po co wydawać dodatkowe pieniądze) doprowadza do przełamania zabezpieczeń.

    Odpowiedz
  2. bl4de

    @SebaVegas
    Podczas pracy w kilku firmach zajmujących się tworzeniem dedykowanych aplikacji miałem do czynienia zarówno z osobami mającymi pojęcie o temacie, jak i takimi, dla których przekazanie parametrów z GET bezpośrednio do kwerendy SQL nie stanowiło najmniejszego powodu do niepokoju ;)

    Ale zgadzam się, że w większośi przypadków testowanie (z uwagi na proces wytwarzania oprogramowania – „ma działać na wczoraj”) leży i kwiczy. Zwłaszcza w projektach nie korzystających z technologii, gdzie testowanie jest naturalnym etapem (choćby JEE)

    Odpowiedz
  3. MateuszM

    Bardzo ciekawy artykuł. Dobrze się go czyta, nie ma w nim głupot i kolokwializmów, są za to odniesienia do źródeł. Jednym słowem – pozytywnie.

    Odpowiedz
  4. bl4de

    @MateuszM
    Dziękuję :)

    Jeśli będziesz miał jakiekolwiek pytania bądź sugestie – chętnie odpowiem.

    Odpowiedz
  5. lechu

    Bardzo profesjonalnie, i rzeczowo.
    Pozdrawiam.
    Lechu

    Odpowiedz
  6. Infern0_

    bl4de – czemu nie pracujesz jako security guy, tylko JS developer?
    Art spoko, pozdro.

    Odpowiedz
  7. Bardzo fajny artykuł

    Odpowiedz

Odpowiedz