10 najczęstszych luk w zabezpieczeniach sieci Web

W przypadku zbyt wielu firm najlepsze praktyki w zakresie bezpieczeństwa sieci stają się priorytetem dopiero po wystąpieniu naruszenia bezpieczeństwa. Podczas moich lat pracy jako specjalista ds. Bezpieczeństwa IT, raz po raz widziałem, jak niejasny może być świat problemów związanych z bezpieczeństwem tworzenia stron internetowych dla tak wielu moich kolegów programistów.

Skuteczne podejście do zagrożeń bezpieczeństwa sieci musi z definicji być proaktywne i defensywne. W tym celu ten post ma na celu rozbudzenie postawy bezpieczeństwa, miejmy nadzieję, że wstrzyknie czytelnikowi zdrową dawkę paranoi.

W szczególności ten przewodnik skupia się na 10 typowych i znaczących pułapkach bezpieczeństwa sieci, o których należy pamiętać, w tym zaleceniach, jak można je złagodzić. Skupiono się na 10 najważniejszych lukach w zabezpieczeniach sieci Web zidentyfikowanych przez Open Web Application Security Project (OWASP), międzynarodową organizację non-profit, której celem jest poprawa bezpieczeństwa oprogramowania na całym świecie.

Mały elementarz cyberbezpieczeństwa zanim zaczniemy – uwierzytelnianie i autoryzacja

Rozmawiając z innymi programistami i specjalistami IT, często spotykam się z niejasnością dotyczącą rozróżnienia między autoryzacją a uwierzytelnianiem. I oczywiście fakt, że skrót auth jest często używany dla obu, pomaga zaostrzyć to powszechne zamieszanie. To zamieszanie jest tak powszechne, że być może ten problem powinien zostać uwzględniony w tym poście jako „Common Web Vulnerability Zero”.

Więc zanim przejdziemy dalej, wyjaśnijmy różnicę między tymi dwoma terminami:

• Uwierzytelnianie: Weryfikacja, czy dana osoba jest (lub przynajmniej wydaje się być) określonym użytkownikiem, ponieważ poprawnie podała swoje dane uwierzytelniające (hasło, odpowiedzi na pytania zabezpieczające, skanowanie odcisków palców itp.).
• Autoryzacja: Potwierdzenie, że określony użytkownik ma dostęp do określonego zasobu lub ma uprawnienia do wykonania określonej akcji.

Innymi słowy, uwierzytelnianie to wiedza, kim jest podmiot, podczas gdy autoryzacja to wiedza, co dany podmiot może zrobić. Mając to na uwadze, przejdźmy do 10 najważniejszych problemów związanych z bezpieczeństwem w Internecie.

Powszechny błąd w zabezpieczeniach sieci Web nr 1: wady wstrzykiwania

Błędy wstrzykiwania wynikają z klasycznego niepowodzenia filtrowania niezaufanych danych wejściowych. Może się to zdarzyć, gdy przekażesz niefiltrowane dane na serwer SQL (wstrzyknięcie SQL), do przeglądarki (XSS – o tym porozmawiamy później), na serwer LDAP (wstrzyknięcie LDAP) lub gdziekolwiek indziej. Problem polega na tym, że atakujący może wstrzykiwać tym podmiotom polecenia, co skutkuje utratą danych i przejęciem przeglądarek klientów.

Wszystko, co Twoja aplikacja otrzymuje z niezaufanych źródeł, musi być filtrowane, najlepiej według białej listy. Prawie nigdy nie powinieneś używać czarnej listy, ponieważ uzyskanie tego prawidłowego jest bardzo trudne i zwykle łatwe do ominięcia. Oprogramowanie antywirusowe zazwyczaj zapewnia znakomite przykłady nieudanych czarnych list. Dopasowywanie wzorców nie działa.

Zapobieganie: Dobra wiadomość jest taka, że ​​ochrona przed wstrzykiwaniem jest „po prostu” kwestią odpowiedniego filtrowania danych wejściowych i zastanowienia się, czy można im zaufać. Ale złą wiadomością jest to, że wszystkie dane wejściowe muszą być odpowiednio filtrowane, chyba że można im bez wątpienia ufać (ale powiedzenie „nigdy nie mów nigdy” przychodzi tu na myśl).

Na przykład w systemie z 1000 wejść pomyślne odfiltrowanie 999 z nich nie jest wystarczające, ponieważ nadal pozostawia jedno pole, które może służyć jako leczenie Achillesa, aby obniżyć system. I możesz pomyśleć, że umieszczenie wyniku zapytania SQL w innym zapytaniu jest dobrym pomysłem, ponieważ baza danych jest zaufana, ale jeśli obwód nie jest, dane wejściowe pochodzą pośrednio od facetów z malintentami. Jeśli jesteś zainteresowany, nazywa się to wstrzykiwaniem SQL drugiego rzędu.

Ponieważ filtrowanie jest dość trudne do wykonania poprawnie (jak krypto), zwykle radzę polegać na funkcjach filtrujących twojego frameworka: udowodniono, że działają i są dokładnie przeanalizowane. Jeśli nie używasz frameworków, naprawdę musisz się zastanowić, czy ich nieużywanie ma sens w kontekście bezpieczeństwa twojego serwera. W 99% przypadków tak się nie dzieje.

Powszechny błąd w zabezpieczeniach sieci Web nr 2: zepsute uwierzytelnianie

Jest to zbiór wielu problemów, które mogą wystąpić podczas nieprawidłowego uwierzytelniania, ale nie wszystkie wynikają z tej samej przyczyny.

Zakładając, że w 2014 roku ktoś nadal chce rzucić swój własny kod uwierzytelniający (o czym myślisz??), odradzam. Niezwykle trudno jest to zrobić dobrze, a istnieje mnóstwo możliwych pułapek, żeby wymienić tylko kilka:

1. Adres URL może zawierać identyfikator sesji i przeciekać go w nagłówku odsyłacza do kogoś innego.
2. Hasła mogą nie być szyfrowane podczas przechowywania lub przesyłania.
3. Identyfikatory sesji mogą być przewidywalne, więc uzyskanie dostępu jest trywialne.
4. Możliwe jest ustalenie sesji.
5. Możliwe jest przechwycenie sesji, niewdrożone limity czasu lub korzystanie z protokołu HTTP (brak zabezpieczeń SSL) itp.

Zapobieganie: najprostszym sposobem uniknięcia tej luki w zabezpieczeniach sieci jest użycie frameworka. Być może uda Ci się to poprawnie zaimplementować, ale to pierwsze jest znacznie łatwiejsze. Jeśli chcesz rzucić swój własny kod, bądź skrajnym paranoikiem i edukuj się, jakie są pułapki. Jest ich sporo.

Powszechny błąd w zabezpieczeniach sieci Web nr 3: Cross Site Scripting (XSS)

Jest to dość powszechny błąd sanityzacji danych wejściowych (zasadniczo szczególny przypadek powszechnego błędu nr 1). Osoba atakująca podaje Twojej aplikacji internetowej tagi JavaScript podczas wprowadzania danych. Gdy dane wejściowe zostaną zwrócone użytkownikowi w stanie nieoczyszczonym, przeglądarka użytkownika je wykona. Może to być tak proste, jak stworzenie linku i przekonanie użytkownika do jego kliknięcia, lub może to być coś znacznie bardziej złowrogiego. Podczas wczytywania strony skrypt uruchamia się i może być używany na przykład do wysyłania plików cookie do atakującego.

Zapobieganie: Jest proste rozwiązanie bezpieczeństwa w sieci: nie zwracaj tagów HTML do klienta. Ma to dodatkową zaletę polegającą na ochronie przed wstrzykiwaniem HTML, podobnym atakiem, w którym atakujący wstrzykuje zwykłą zawartość HTML (taką jak obrazy lub głośne niewidzialne odtwarzacze flash) – nie ma dużego wpływu, ale z pewnością irytuje („proszę, zatrzymaj to!”). Zwykle obejście polega po prostu na przekonwertowaniu wszystkich encji HTML, tak aby <script> był zwracany jako <script> . Inną często stosowaną metodą oczyszczania jest używanie wyrażeń regularnych do usuwania znaczników HTML za pomocą wyrażeń regularnych w < i > , ale jest to niebezpieczne, ponieważ wiele przeglądarek dobrze zinterpretuje poważnie uszkodzony kod HTML. Lepiej przekonwertować wszystkie znaki na ich uciekinierów.

Częsty błąd w zabezpieczeniach sieci WWW nr 4: niezabezpieczone bezpośrednie odniesienia do obiektów

Jest to klasyczny przypadek zaufania do danych wprowadzanych przez użytkownika i zapłacenia ceny w postaci powstałej luki w zabezpieczeniach. Bezpośrednie odwołanie do obiektu oznacza, że ​​obiekt wewnętrzny, taki jak plik lub klucz bazy danych, jest widoczny dla użytkownika. Problem z tym polega na tym, że atakujący może dostarczyć to odniesienie i jeśli autoryzacja nie jest wymuszona (lub jest zepsuta), atakujący może uzyskać dostęp lub zrobić rzeczy, przed którymi powinien być wykluczony.

Na przykład kod zawiera moduł download.php , który odczytuje i pozwala użytkownikowi pobierać pliki, używając parametru CGI do określenia nazwy pliku (np. download.php?file=something.txt ). Programista pominął autoryzację w kodzie przez pomyłkę lub z powodu lenistwa. Atakujący może teraz użyć tego do pobrania dowolnych plików systemowych, do których użytkownik korzystający z PHP ma dostęp, takich jak sam kod aplikacji lub inne dane pozostawione na serwerze, takie jak kopie zapasowe. O o.

Innym typowym przykładem luki w zabezpieczeniach jest funkcja resetowania hasła, która opiera się na danych wprowadzonych przez użytkownika w celu określenia, czyje hasło resetujemy. Po kliknięciu prawidłowego adresu URL atakujący może po prostu zmodyfikować pole username w adresie URL, aby powiedzieć coś w stylu „admin”.

Nawiasem mówiąc, oba te przykłady to rzeczy, które sam widziałem, często pojawiające się „na wolności”.

Zapobieganie: przeprowadzaj autoryzację użytkowników prawidłowo i spójnie oraz umieszczaj wybrane opcje na białej liście. Najczęściej jednak można uniknąć całego problemu, przechowując dane wewnętrznie i nie polegając na tym, że są one przekazywane od klienta za pomocą parametrów CGI. Do tego celu dobrze nadają się zmienne sesji w większości frameworków.

Powszechny błąd dotyczący bezpieczeństwa sieci Web nr 5: błędna konfiguracja zabezpieczeń

Z mojego doświadczenia wynika, że ​​serwery internetowe i aplikacje, które zostały źle skonfigurowane, są znacznie bardziej powszechne niż te, które zostały poprawnie skonfigurowane. Być może dlatego, że nie brakuje sposobów, aby schrzanić. Kilka przykładów:

1. Uruchamianie aplikacji z włączonym debugowaniem w środowisku produkcyjnym.
2. Posiadanie włączonej listy katalogów na serwerze, z której wyciekają cenne informacje.
3. Uruchamianie przestarzałego oprogramowania (pomyśl o wtyczkach WordPress, starym PhpMyAdmin).
4. Posiadanie niepotrzebnych usług uruchomionych na komputerze.
5. Nie zmieniamy domyślnych kluczy i haseł. (Zdarza się znacznie częściej, niż myślisz!)
6. Ujawnianie atakującym informacje dotyczące obsługi błędów, takie jak ślady stosu.

Zapobieganie: Miej dobry (najlepiej zautomatyzowany) proces „buduj i wdrażaj”, który może uruchamiać testy podczas wdrażania. Rozwiązaniem dla biedaków w zakresie błędnej konfiguracji zabezpieczeń są haki po zatwierdzeniu, aby zapobiec wychodzeniu kodu z domyślnymi hasłami i/lub wbudowanymi elementami programistycznymi.

Powszechny błąd w zabezpieczeniach sieci WWW nr 6: narażenie na wrażliwe dane

Ta luka w zabezpieczeniach sieci Web dotyczy ochrony kryptograficznej i zasobów. Wrażliwe dane powinny być szyfrowane przez cały czas, w tym podczas przesyłania i w spoczynku. Bez wyjątków. Informacje o kartach kredytowych i hasła użytkowników nigdy nie powinny podróżować ani być przechowywane w postaci niezaszyfrowanej, a hasła powinny być zawsze zaszyfrowane. Oczywiście algorytm szyfrowania/haszowania nie może być słaby – w razie wątpliwości standardy bezpieczeństwa sieci zalecają AES (256 bitów i więcej) i RSA (2048 bitów i więcej).

I chociaż jest rzeczą oczywistą, że identyfikatory sesji i wrażliwe dane nie powinny podróżować w adresach URL, a wrażliwe pliki cookie powinny mieć włączoną flagę bezpieczeństwa, jest to bardzo ważne i nie można tego przeceniać.

Zapobieganie:

• W tranzycie: użyj protokołu HTTPS z odpowiednim certyfikatem i PFS (Perfect Forward Secrecy). Nie akceptuj niczego przez połączenia inne niż HTTPS. Ustaw flagę bezpieczeństwa na plikach cookie.

• W magazynie: To jest trudniejsze. Przede wszystkim musisz zmniejszyć ekspozycję. Jeśli nie potrzebujesz wrażliwych danych, zniszcz je. Danych, których nie masz, nie można ukraść. Nigdy nie przechowuj informacji o kartach kredytowych, ponieważ prawdopodobnie nie chcesz mieć do czynienia ze zgodnością z PCI. Zarejestruj się w procesorze płatności, takim jak Stripe lub Braintree. Po drugie, jeśli masz poufne dane, których naprawdę potrzebujesz, przechowuj je w postaci zaszyfrowanej i upewnij się, że wszystkie hasła są zaszyfrowane. Do haszowania zalecane jest użycie bcrypt. Jeśli nie używasz bcrypt, edukuj się na stołach do solenia i tęczy.

I ryzykując stwierdzenie oczywiste, nie przechowuj kluczy szyfrowania obok chronionych danych . To jak przechowywanie roweru z zamkiem, w którym jest klucz. Chroń swoje kopie zapasowe za pomocą szyfrowania i zachowaj bardzo prywatność swoich kluczy. I oczywiście nie zgub kluczy!

Powszechny błąd w zabezpieczeniach sieci Web nr 7: Brak kontroli dostępu na poziomie funkcji

To po prostu błąd autoryzacji. Oznacza to, że przy wywołaniu funkcji na serwerze nie została wykonana właściwa autoryzacja. Wiele razy programiści polegają na tym, że strona serwera wygenerowała interfejs użytkownika i uważają, że klient nie może uzyskać dostępu do funkcjonalności, której nie dostarcza serwer. Nie jest to takie proste, ponieważ atakujący zawsze może sfałszować żądania dotyczące „ukrytej” funkcjonalności i nie będzie zniechęcony faktem, że interfejs użytkownika nie zapewnia łatwego dostępu do tej funkcji. Wyobraź sobie panel /admin , a przycisk jest obecny w interfejsie użytkownika tylko wtedy, gdy użytkownik jest faktycznie administratorem. Nic nie stoi na przeszkodzie, aby atakujący odkrył tę funkcję i nadużył jej w przypadku braku autoryzacji.

Zapobieganie: Po stronie serwera autoryzacja musi być zawsze wykonywana. Tak zawsze. Żadne wyjątki ani luki w zabezpieczeniach nie spowodują poważnych problemów.

Powszechny błąd w zabezpieczeniach sieci Web nr 8: Fałszowanie żądań między witrynami (CSRF)

To dobry przykład ataku zdezorientowanego zastępcy, w którym przeglądarka jest oszukiwana przez inną stronę do nadużycia jej uprawnień. Na przykład witryna innej firmy może sprawić, że przeglądarka użytkownika nadużyje swoich uprawnień do zrobienia czegoś dla atakującego.

W przypadku CSRF, strona trzecia wysyła żądania do strony docelowej (np. Twojego banku) za pomocą Twojej przeglądarki z Twoimi plikami cookie / sesją. Jeśli na przykład jesteś zalogowany na jednej karcie na stronie głównej swojego banku i są one podatne na ten atak, inna karta może sprawić, że przeglądarka nadużyje swoich danych uwierzytelniających w imieniu napastnika, powodując problem zdezorientowanego zastępcy. Zastępca jest przeglądarką, która nadużywa swoich uprawnień (pliki cookie sesji) do zrobienia czegoś, co zlecił jej atakujący.

Rozważ ten przykład:

Napastnik Alice chce odciążyć portfel Todda, przekazując jej część swoich pieniędzy. Bank Todda jest podatny na CSRF. Aby wysłać pieniądze, Todd musi uzyskać dostęp do następującego adresu URL:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

Po otwarciu tego adresu URL strona sukcesu jest prezentowana Toddowi i transfer jest zakończony. Alice wie również, że Todd często odwiedza witrynę pod jej kontrolą pod adresem blog.aliceisawesome.com, gdzie umieszcza następujący fragment:

<img src=http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 width=0 height=0 />

Po odwiedzeniu witryny Alice przeglądarka Todda myśli, że Alicja łączy się z obrazem i automatycznie wysyła żądanie HTTP GET w celu pobrania obrazu, ale w rzeczywistości instruuje to bank Todda, aby przelał 1500 dolarów na Alice.

Nawiasem mówiąc, oprócz zademonstrowania luki CSRF, ten przykład demonstruje również zmianę stanu serwera za pomocą idempotentnego żądania HTTP GET, które samo w sobie jest poważną luką. Żądania HTTP GET muszą być idempotentne (bezpieczne), co oznacza, że ​​nie mogą zmieniać zasobu, do którego uzyskuje się dostęp. Nigdy, przenigdy nie używaj idempotentnych metod do zmiany stanu serwera.

Ciekawostka: CSRF jest również metodą, którą ludzie używali w przeszłości do wypychania ciasteczek, dopóki partnerzy nie stali się mądrzejsi.

Zapobieganie: Przechowuj tajny token w ukrytym polu formularza, które jest niedostępne z witryny innej firmy. Oczywiście zawsze musisz zweryfikować to ukryte pole. Niektóre witryny proszą również o podanie hasła podczas modyfikowania poufnych ustawień (takich jak na przykład wiadomość e-mail z przypomnieniem hasła), chociaż podejrzewam, że ma to na celu zapobieganie niewłaściwemu wykorzystaniu porzuconych sesji (na przykład w kafejce internetowej).

Powszechny błąd w zabezpieczeniach sieci Web nr 9: używanie komponentów ze znanymi lukami w zabezpieczeniach

Tytuł mówi wszystko. Ponownie sklasyfikowałbym to jako problem związany z konserwacją/wdrożeniem. Przed włączeniem nowego kodu przeprowadź trochę badań, być może trochę audytu. Używanie kodu otrzymanego od przypadkowej osoby na GitHub lub na jakimś forum może być bardzo wygodne, ale nie jest pozbawione ryzyka poważnej luki w zabezpieczeniach sieci.

Widziałem wiele przypadków, na przykład, w których strony stały się własnością (tj. gdy osoba z zewnątrz uzyskała administracyjny dostęp do systemu), nie dlatego, że programiści byli głupi, ale dlatego, że oprogramowanie innych firm pozostawało nienaprawiane przez lata w produkcji. Dzieje się tak cały czas na przykład w przypadku wtyczek WordPress. Jeśli uważasz, że nie znajdą Twojej ukrytej instalacji phpmyadmin , pozwól, że przedstawię Ci dirbuster.

Lekcja z tego jest taka, że ​​tworzenie oprogramowania nie kończy się wraz z wdrożeniem aplikacji. Musi istnieć dokumentacja, testy i plany dotyczące jego utrzymania i aktualizacji, zwłaszcza jeśli zawiera komponenty innych firm lub komponenty open source.

Zapobieganie:

• Należy zachować ostrożność. Poza oczywistym zachowaniem ostrożności podczas korzystania z takich komponentów, nie bądź koderem kopiuj-wklej. Uważnie sprawdź fragment kodu, który zamierzasz umieścić w swoim oprogramowaniu, ponieważ może zostać złamany i niemożliwy do naprawienia (lub w niektórych przypadkach celowo złośliwy — czasami nieświadomie zachęca się do ataków na bezpieczeństwo sieci).

• Bądź na bieżąco. Upewnij się, że korzystasz z najnowszych wersji wszystkiego, którym ufasz, i masz plan, aby regularnie je aktualizować. Przynajmniej zapisz się do newslettera o nowych lukach w zabezpieczeniach dotyczących produktu.

Powszechny błąd w zabezpieczeniach sieci Web nr 10: Niesprawdzone przekierowania i przekierowania

Jest to ponownie problem z filtrowaniem danych wejściowych. Załóżmy, że docelowa witryna ma moduł redirect.php , który przyjmuje adres URL jako parametr GET . Manipulowanie parametrem może stworzyć adres URL na targetsite.com , który przekierowuje przeglądarkę na malwareinstall.com . Gdy użytkownik zobaczy link, zobaczy targetsite.com/blahblahblah , którą uważa za zaufaną i którą można bezpiecznie kliknąć. Nie wiedzą, że to faktycznie przeniesie je na stronę upuszczania złośliwego oprogramowania (lub jakąkolwiek inną złośliwą) stronę. Alternatywnie, atakujący może przekierować przeglądarkę na targetsite.com/deleteprofile?confirm=1 .

Warto wspomnieć, że upchanie nieoczyszczonych danych wejściowych zdefiniowanych przez użytkownika do nagłówka HTTP może prowadzić do wstrzyknięcia nagłówka, co jest dość złe.

Zapobieganie: Opcje obejmują:

• W ogóle nie rób przekierowań (są rzadko potrzebne).
• Mieć statyczną listę prawidłowych lokalizacji, do których można się przekierować.
• Dodaj parametr zdefiniowany przez użytkownika do białej listy, ale może to być trudne.

Epilog

Mam nadzieję, że tym postem udało mi się trochę połaskotać Twój mózg i wprowadzić zdrową dawkę paranoi oraz świadomość luk w zabezpieczeniach witryny.

Podstawowym wnioskiem jest to, że nie bez powodu istnieją odwieczne praktyki programistyczne, a to, co kiedyś było stosowane w przypadku przepełnienia bufora, nadal ma zastosowanie do marynowanych ciągów w Pythonie. Protokoły bezpieczeństwa pomagają pisać (więcej) poprawne programy, do których wszyscy programiści powinni dążyć.

Korzystaj z tej wiedzy w sposób odpowiedzialny i nie testuj stron bez pozwolenia!

Aby uzyskać więcej informacji i bardziej szczegółowe ataki po stronie serwera, zajrzyj na: https://www.owasp.org/index.php/Category:Attack.

Opinie na temat tego posta i porady dotyczące jego łagodzenia są mile widziane i mile widziane. Planowane są kolejne posty, w szczególności na temat rozproszonych ataków typu „odmowa usługi” (DDoS) i starych (nie webowych) luk w zabezpieczeniach IT. Jeśli masz konkretną prośbę o rodzaj ochrony sieci web, o której pisać, proszę o bezpośredni kontakt pod adresem [email protected].

Oto bezpieczeństwo witryny! Dzięki.