Około rok temu uruchomiliśmy DataLine do wyszukiwania i analizowania podatności w aplikacjach IT. Usługa oparta jest o rozwiązanie chmurowe Qualys, o którego działaniu chodzi . W ciągu roku pracy z rozwiązaniem przeprowadziliśmy 291 skanów różnych witryn i zebraliśmy statystyki dotyczące typowych podatności w aplikacjach internetowych.
W poniższym artykule pokażę Ci dokładnie, jakie luki w bezpieczeństwie stron internetowych kryją się za różnymi poziomami krytyczności. Zobaczmy, jakie luki skaner wykrywał szczególnie często, dlaczego mogą wystąpić i jak się chronić.
Qualys dzieli wszystkie luki w aplikacjach internetowych na trzy poziomy krytyczności: niski, średni i wysoki. Jeśli spojrzeć na rozkład według „dotkliwości”, wydaje się, że nie wszystko jest takie złe. Istnieje kilka luk o wysokim poziomie krytyczności, w większości wszystkie są niekrytyczne:
Ale bezkrytyczny nie znaczy nieszkodliwy. Mogą również spowodować poważne szkody.
Najważniejsze „niekrytyczne” luki w zabezpieczeniach
- Luki w zabezpieczeniach o mieszanej zawartości.
Standardem bezpieczeństwa stron internetowych jest przesyłanie danych pomiędzy klientem a serwerem za pośrednictwem protokołu HTTPS, który obsługuje szyfrowanie i zabezpiecza informacje przed przechwyceniem.
Niektóre witryny używają zawartość mieszana: Niektóre dane są przesyłane za pośrednictwem niezabezpieczonego protokołu HTTP. W ten sposób jest to najczęściej przekazywane treść pasywna – informacje wpływające jedynie na wyświetlanie strony: zdjęcia, style CSS. Ale czasami w ten sposób jest to przekazywane zawartość aktywna: skrypty kontrolujące zachowanie witryny. W tym przypadku za pomocą specjalnego oprogramowania można analizować informacje z aktywną treścią przychodzącą z serwera, na bieżąco modyfikować swoje odpowiedzi i sprawić, że maszyna będzie działać w sposób niezamierzony przez jej twórców.
Nowsze wersje przeglądarek ostrzegają użytkowników, że witryny z mieszaną zawartością są niebezpieczne i blokują takie treści. Twórcy witryn internetowych otrzymują także ostrzeżenia przeglądarki w konsoli. Na przykład tak to wygląda :
Niż niebezpieczne: osoby atakujące korzystają z niezabezpieczonego protokołu w celu przechwytywania informacji o użytkowniku, zastępowania skryptów i wysyłania żądań do witryny w jego imieniu. Nawet jeśli odwiedzający witrynę nie wprowadził danych, nie chroni to go przed wyłudzanie informacji – pozyskiwania informacji poufnych metodami oszukańczymi. Na przykład za pomocą skryptu możesz przekierować użytkownika do niebezpiecznej witryny, która udaje znajomą użytkownikowi. W niektórych przypadkach złośliwa witryna wygląda nawet lepiej niż oryginał, a użytkownik może samodzielnie wypełnić formularz i przesłać poufne dane.O czym powinien pamiętać twórca stron internetowych: Nawet jeśli administrator witryny zainstalował i skonfigurował certyfikat SSL/TLS, może wystąpić luka w zabezpieczeniach wynikająca z błędu ludzkiego. Przykładowo, jeśli na jednej ze stron nie umieścisz linku względnego, a link absolutny z http, a dodatkowo nie ustawiłeś przekierowań z http na https.
Możesz wykryć mieszaną zawartość witryny za pomocą przeglądarki: przeszukaj kod źródłowy strony, przeczytaj powiadomienia w konsoli programisty. Jednak programista będzie musiał majstrować przy kodzie przez długi czas i żmudnie. Możesz przyspieszyć ten proces dzięki zautomatyzowanym narzędziom analitycznym, na przykład: , darmowe oprogramowanie Lighthouse lub płatne oprogramowanie Screaming Frog SEO Spider.
Luka może również wynikać z problemów ze starszym kodem - kodem, który został odziedziczony. Na przykład, jeśli niektóre strony są generowane przy użyciu starego szablonu, który nie uwzględnia przejścia witryn na https.
- Pliki cookie bez flag „HTTPOnly” i „bezpieczne”.
Atrybut „HTTPOnly” chroni pliki cookie przed przetwarzaniem przez skrypty wykorzystywane przez osoby atakujące do kradzieży danych użytkownika. Flaga „bezpieczne” nie pozwala na wysyłanie plików cookie w postaci zwykłego tekstu. Komunikacja będzie możliwa tylko wtedy, gdy do wysyłania plików cookie używany będzie bezpieczny protokół HTTPS.
Obydwa atrybuty określone są we właściwościach pliku cookie:
Set-Cookie: Secure; HttpOnlyNiż niebezpieczne: Jeśli twórca witryny nie określił tych atrybutów, osoba atakująca może przechwycić informacje o użytkowniku z pliku cookie i wykorzystać je. Jeżeli do uwierzytelniania i autoryzacji wykorzystywane będą pliki cookies, będzie on mógł przejąć sesję użytkownika i wykonywać w jego imieniu działania w serwisie.
O czym powinien pamiętać twórca stron internetowych: Z reguły w popularnych frameworkach te atrybuty są ustawiane automatycznie. Ale nadal sprawdź konfigurację serwera WWW i ustaw flagę: Set-Cookie HttpOnly; Bezpieczne.
W takim przypadku atrybut „HTTPOnly” sprawi, że pliki cookie będą niewidoczne dla Twojego kodu JavaScript.
- Luki w zabezpieczeniach oparte na ścieżkach.
Skaner zgłasza taką lukę, jeśli znajdzie publicznie dostępny plik lub katalog stron internetowych zawierający potencjalnie poufne informacje. Na przykład wykrywa pojedyncze pliki konfiguracyjne systemu lub dostęp do całego systemu plików. Taka sytuacja jest możliwa, jeśli prawa dostępu są ustawione nieprawidłowo na stronie.
Niż niebezpieczne: Jeśli system plików „wystaje”, osoba atakująca może wpaść do interfejsu systemu operacyjnego i spróbować znaleźć foldery z hasłami, jeśli są zapisane w postaci zwykłego tekstu (nie rób tego!). Możesz też ukraść skróty haseł i brutalnie wymusić hasło, a także spróbować podnieść uprawnienia w systemie i zagłębić się w infrastrukturę.
O czym powinien pamiętać twórca stron internetowych: Nie zapomnij o prawach dostępu i skonfiguruj platformę, serwer WWW, aplikację internetową tak, aby nie było możliwości „ucieczki” z katalogu internetowego.
- Formularze do wprowadzania danych wrażliwych z włączoną opcją autouzupełniania.
Jeśli użytkownik często wypełnia formularze na stronach internetowych, jego przeglądarka przechowuje te informacje, korzystając z funkcji autouzupełniania.
Formularze na stronach internetowych mogą zawierać pola zawierające poufne informacje, takie jak hasła lub numery kart kredytowych. Dla takich pól warto wyłączyć funkcję autouzupełniania formularza w samej witrynie.
Niż niebezpieczne: jeśli przeglądarka użytkownika przechowuje poufne informacje, osoba atakująca może je później przechwycić, na przykład poprzez phishing. Krótko mówiąc, twórca stron internetowych, który zapomniał o tym niuansie, konfiguruje swoich użytkowników.
O czym powinien pamiętać twórca stron internetowych: W tym przypadku mamy klasyczny konflikt: wygoda vs bezpieczeństwo. Jeśli twórca stron internetowych myśli o doświadczeniu użytkownika, może świadomie wybrać autouzupełnianie. Na przykład, jeśli ważne jest przestrzeganie – zalecenia dotyczące dostępności treści dla użytkowników niepełnosprawnych.
W większości przeglądarek można wyłączyć autouzupełnianie za pomocą atrybutu autocompete="off", na przykład:
<body> <form action="/pl/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Ale to nie będzie działać w Chrome. Można to obejść za pomocą JavaScript, można znaleźć wariant przepisu .
- Nagłówek X-Frame-Options nie jest ustawiony w kodzie witryny.
Ten nagłówek wpływa na tagi ramki, iframe, embed i object. Za jego pomocą możesz całkowicie zabronić osadzania swojej witryny w ramce. Aby to zrobić, musisz określić wartość X-Frame-Options: deny. Możesz też określić opcje X-Frame: sameorigin, a następnie osadzanie w elemencie iframe będzie dostępne tylko w Twojej domenie.
Niż niebezpieczne: Brak takiego nagłówka może zostać wykorzystany na złośliwych stronach przechwytywanie kliknięć. W przypadku tego ataku atakujący tworzy przezroczystą ramkę na przyciskach i oszukuje użytkownika. Na przykład: oszuści umieszczają w witrynie internetowej strony sieci społecznościowych. Użytkownik myśli, że klika przycisk na tej stronie. Zamiast tego kliknięcie jest przechwytywane, a żądanie użytkownika wysyłane do sieci społecznościowej, w której trwa aktywna sesja. W ten sposób napastnicy wysyłają spam w imieniu użytkownika lub zdobywają subskrybentów i polubienia.
Jeśli nie wyłączysz tej funkcji, osoba atakująca może umieścić przycisk Twojej aplikacji w złośliwej witrynie. Może być zainteresowany Twoim programem poleceń lub Twoimi użytkownikami.
O czym powinien pamiętać twórca stron internetowych: Luka może wystąpić, jeśli na serwerze WWW lub module równoważenia obciążenia ustawiono opcję X-Frame-Options o sprzecznej wartości. W takim przypadku serwer i moduł równoważący po prostu przepiszą nagłówek, ponieważ mają one wyższy priorytet w porównaniu z kodem zaplecza.
Wartości deny i sameorigin nagłówka X-Frame-Options będą zakłócać działanie przeglądarki internetowej Yandex. Aby umożliwić korzystanie z ramek iframe dla przeglądarki internetowej, musisz napisać osobną regułę w ustawieniach. Na przykład dla nginx możesz skonfigurować to w ten sposób:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Luki w zabezpieczeniach PRSSI (import arkusza stylów zależnych od ścieżki).
Jest to luka w stylu witryny. Dzieje się tak, jeśli w celu uzyskania dostępu do plików stylów używane są łącza względne, takie jak href="/pl/somefolder/styles.css/". Osoba atakująca wykorzysta to, jeśli znajdzie sposób na przekierowanie użytkownika na złośliwą stronę. Strona wstawi względny link do swojego adresu URL i zasymuluje wywołanie stylów. Otrzymasz żądanie takie jak badsite.ru/…/somefolder/styles.css/, które może wykonywać złośliwe działania pod przykrywką stylu.
Niż niebezpieczne: Oszust może wykorzystać tę lukę, jeśli znajdzie inną lukę w zabezpieczeniach. W rezultacie możliwa jest kradzież danych użytkownika z plików cookies lub tokenów.
O czym powinien pamiętać twórca stron internetowych: Ustaw nagłówek X-Content-Type-Options na: nosniff. W takim przypadku przeglądarka sprawdzi typ zawartości stylów. Jeśli typ jest inny niż tekst/css, przeglądarka zablokuje żądanie.
Krytyczne luki
- Strona z polem hasła jest przesyłana z serwera niezabezpieczonym kanałem (formularz HTML zawierający pola hasła jest obsługiwany przez protokół HTTP).
Odpowiedź serwera za pośrednictwem niezaszyfrowanego kanału jest podatna na ataki typu „Man in the Middle”. Osoba atakująca może przechwycić ruch i zaklinować się pomiędzy klientem a serwerem podczas przesyłania strony z serwera do klienta.
Niż niebezpieczne: Oszust będzie mógł podmienić stronę i wysłać użytkownikowi formularz z poufnymi danymi, który trafi na serwer atakującego.
O czym powinien pamiętać twórca stron internetowych: niektóre witryny zamiast hasła wysyłają użytkownikom jednorazowy kod e-mailem/telefonem. W tym przypadku luka nie jest tak krytyczna, ale mechanizm skomplikuje życie użytkownikom.
- Wysłanie formularza z loginem i hasłem niezabezpieczonym kanałem (formularz logowania nie jest przesyłany przez HTTPS).
W tym przypadku formularz z loginem i hasłem przesyłany jest od użytkownika do serwera kanałem nieszyfrowanym.
Niż niebezpieczne: W przeciwieństwie do poprzedniego przypadku, jest to już krytyczna luka. Łatwiej jest przechwycić wrażliwe dane, ponieważ nie trzeba nawet pisać kodu, aby to zrobić.
- Korzystanie z bibliotek JavaScript ze znanymi lukami w zabezpieczeniach.
Podczas skanowania najczęściej używaną biblioteką była jQuery z dużą liczbą wersji. Każda wersja ma co najmniej jedną lub więcej znanych luk. Skutki mogą być bardzo różne, w zależności od charakteru luki.
Niż niebezpieczne: Istnieją exploity wykorzystujące znane luki, na przykład:
O czym powinien pamiętać twórca stron internetowych: Regularnie powracaj do cyklu: szukaj znanych luk - napraw - sprawdź. Jeśli celowo korzystasz ze starszych bibliotek, na przykład do obsługi starszych przeglądarek lub w celu zaoszczędzenia pieniędzy, poszukaj możliwości naprawienia znanej luki. - Skrypty między witrynami (XSS).
Cross-Site Scripting (XSS), czyli cross-site scripting, to atak na aplikację internetową, w wyniku którego do bazy danych zostaje wprowadzone złośliwe oprogramowanie. Jeśli Qualys znajdzie taką lukę, oznacza to, że potencjalny atakujący może lub już wprowadził do kodu witryny własny skrypt js w celu wykonania szkodliwych działań.Przechowywane XSS bardziej niebezpieczne, ponieważ skrypt jest osadzony na serwerze i wykonywany za każdym razem, gdy zaatakowana strona jest otwierana w przeglądarce.
Odzwierciedlone XSS łatwiejsze do przeprowadzenia, ponieważ do żądania HTTP można wstrzyknąć złośliwy skrypt. Aplikacja odbierze żądanie HTTP, nie zweryfikuje danych, spakuje je i natychmiast wyśle. Jeśli atakujący przechwyci ruch i wstawi skrypt taki jak
<script>/*+что+то+плохое+*/</script>wówczas w imieniu klienta zostanie wysłane złośliwe żądanie.
Uderzający przykład XSS: sniffery js, które symulują strony do wprowadzania kodu CVC, daty ważności karty i tak dalej.
O czym powinien pamiętać twórca stron internetowych: W nagłówku Content-Security-Policy użyj atrybutu script-src, aby wymusić na przeglądarce klienta pobieranie i wykonywanie kodu wyłącznie z zaufanego źródła. Na przykład skrypt script-src 'self' umieszcza na białej liście tylko wszystkie skrypty z naszej witryny.
Najlepszą praktyką jest kod wbudowany: zezwalaj tylko na wbudowany JavaScript, używając wartości unsafe-inline. Ta wartość umożliwia użycie wbudowanego formatu js/css, ale nie zabrania dołączania plików js. W połączeniu z script-src 'self' uniemożliwiamy wykonywanie zewnętrznych skryptów.Pamiętaj, aby rejestrować wszystko za pomocą report-uri i przyjrzyj się próbom zaimplementowania tego w witrynie.
- Zastrzyki SQL.
Podatność wskazuje na możliwość wstrzyknięcia kodu SQL do serwisu WWW, który uzyskuje bezpośredni dostęp do bazy danych serwisu. Wstrzykiwanie SQL jest możliwe w przypadku, gdy dane od użytkownika nie są sprawdzane: nie są sprawdzane pod kątem poprawności i są od razu wykorzystywane w zapytaniu. Dzieje się tak na przykład, jeśli formularz na stronie internetowej nie sprawdza, czy wprowadzone dane odpowiadają typowi danych.Niż niebezpieczne: Jeśli atakujący wprowadzi zapytanie SQL do tego formularza, może spowodować awarię bazy danych lub ujawnienie poufnych informacji.
O czym powinien pamiętać twórca stron internetowych: Nie ufaj temu, co pochodzi z przeglądarki. Musisz chronić się zarówno po stronie klienta, jak i po stronie serwera.
Po stronie klienta napisz walidację pola za pomocą JavaScript.
Wbudowane funkcje w popularnych frameworkach pomagają także w ucieczce od podejrzanych znaków na serwerze. Zaleca się także stosowanie sparametryzowanych zapytań do bazy danych na serwerze.
Określ, gdzie dokładnie w aplikacji webowej odbywa się interakcja z bazą danych.
Interakcja ma miejsce wtedy, gdy otrzymamy jakąkolwiek informację: żądanie z identyfikatorem (zmiana identyfikatora), utworzenie nowego użytkownika, nowy komentarz, czy też nowe wpisy w bazie. W tym miejscu mogą wystąpić zastrzyki SQL. Nawet jeśli usuniemy rekord z bazy, możliwy jest zastrzyk SQL.
Ogólne zalecenia
Nie wymyślaj koła na nowo – korzystaj ze sprawdzonych frameworków. Z reguły popularne frameworki są bezpieczniejsze. Dla .NET - ASP.NET MVC i ASP.NET Core, dla Pythona - Django lub Flask, dla Ruby - Ruby on Rails, dla PHP - Symfony, Laravel, Yii, dla JavaScript - Node.JS-Express.js, dla Java - Wiosenny MVC.
Śledź aktualizacje dostawców i regularnie aktualizuj. Znajdą lukę, napiszą exploita, udostępnią go publicznie i wszystko stanie się ponownie. Subskrybuj aktualizacje stabilnych wersji od dostawcy oprogramowania.
Sprawdź prawa dostępu. Po stronie serwera zawsze traktuj swój kod tak, jakby od pierwszej do ostatniej litery został napisany przez Twojego najbardziej znienawidzonego wroga, który chce zepsuć Twoją witrynę, naruszyć integralność Twoich danych. Co więcej, czasami jest to prawdą.
Używaj klonów, miejsc testowych, a następnie używaj ich do produkcji. Pomoże to, po pierwsze, uniknąć błędów i pomyłek w środowisku produkcyjnym: środowisko produkcyjne przynosi pieniądze, proste środowisko produkcyjne jest krytyczne. Dodając, naprawiając lub zamykając jakiś problem, warto popracować na środowisku testowym, następnie sprawdzić znalezione funkcjonalności i podatności, a następnie zaplanować pracę ze środowiskiem produkcyjnym.
Chroń swoją aplikację internetową za pomocą i integruj z nim raporty ze skanera podatności. Na przykład DataLine wykorzystuje Qualys i FortiWeb jako pakiet usług.
Źródło: www.habr.com