Czy słyszałeś o Code Spaces? Było to repozytorium kodu źródłowego podobne do GitHub.
Najprawdopodobniej nigdy o nim nie słyszałeś, ponieważ mimo że był to obiecujący produkt, zniknął niemal natychmiast w czerwcu 2014 roku po ogromnym naruszeniu bezpieczeństwa. W wyniku tego naruszenia firma straciła wszystkie dane swoich klientów i została zmuszona do zakończenia działalności.
Po tym incydencie wszyscy w cyfrowym świecie, w tym menedżerowie produktu, wyciągnęli lekcję, której nigdy nie należy zapominać—PRODUKTY MUSZĄ BYĆ BEZPIECZNE.
W tym poradniku przedstawię Ci świat bezpieczeństwa produktów i pomogę Ci pamiętać o bezpieczeństwie podczas zarządzania produktami.
Dlaczego menedżerowie produktu powinni dbać o bezpieczeństwo danych
W teorii codzienna praca w ramach zarządzania produktem powinna skupiać się wyłącznie na utrzymaniu użytkowników, wywiadach z użytkownikami i innych nietechnicznych kwestiach, bez konieczności martwienia się o bezpieczeństwo.
Żyjemy jednak w świecie pełnym złych ludzi o niegodziwych zamiarach, którzy z przyjemnością ukradliby Twoje dane (aby później je gdzieś sprzedać), zaszyfrowali je, zażądali za nie okupu (czyli wykorzystali oprogramowanie ransomware) lub po prostu wyrządzili szkodę dla samej przyjemności wyrządzania szkody.
Dlatego oprócz aktywizacji i utrzymania użytkowników powinieneś również przejmować się ogromnym ryzykiem biznesowym, jakie dla Twojego produktu może stwarzać niedostateczne bezpieczeństwo. Wystarczająco poważne naruszenie bezpieczeństwa zaszkodzi Twojej reputacji tak bardzo, że wszystkie lata ciężkiej pracy zespołów marketingu, rozwoju produktu i sprzedaży mogą zniknąć w ciągu jednego dnia.
Co więcej, możesz stanąć w obliczu działań prawnych ze strony partnerów i klientów, których danych nie udało Ci się ochronić.
Dlatego moim zdaniem niezwykle ważne jest, aby menedżerowie produktu byli „świadomi bezpieczeństwa” podczas tworzenia i rozwijania swoich produktów.
4 najczęstsze luki w bezpieczeństwie podczas tworzenia produktów
Jako menedżer produktu nie musisz posiadać dogłębnej wiedzy na temat najnowszych metod hakerskich ani sposobów ochrony przed nimi. To zadanie zespołów ds. bezpieczeństwa i inżynierii, które powinny je wdrażać i obsługiwać.
Musisz jednak mieć podstawowe techniczne rozeznanie w tym, jak działają niektóre z najczęstszych problemów bezpieczeństwa i jak hakerzy mogą je wykorzystać. Dzięki temu Twój proces decyzyjny będzie bardziej „świadomy bezpieczeństwa”.
Przyjrzyjmy się wspólnie czterem takim lukom w bezpieczeństwie i zrozummy, na czym polegają.
Have an account? Log In
1. Wstrzyknięcie SQL
Kiedy byłem młodym menedżerem produktu, postanowiłem nauczyć się trochę programowania i napisałem mały (i okropny) kod PHP, który służył jako zaplecze formularza kontaktowego na stronie internetowej. Przyjmował wiadomość, zapisywał ją w bazie danych i tworzył wiadomość e-mail skierowaną do mnie, zawierającą jej treść.
Kiedy pokazałem to mojemu znajomemu programiście, oprócz ledwo powstrzymywanego rozbawienia (mój kod był po prostu niewiarygodnie zły), zapytał mnie, czy oczyściłem dane wejściowe. Jak się domyślasz, nie miałem pojęcia, co miał na myśli, więc wyjaśnił mi, że bez oczyszczania danych wejściowych moje bazy danych były narażone na wstrzyknięcie SQL.
Wstrzyknięcie SQL to proces, w którym haker wpisuje specjalny kod SQL zamiast tekstu w polach wejściowych, a następnie doprowadza do wykonania tego kodu w zapleczu, uzyskując nieuprawniony dostęp do produktu lub kradnąc informacje z baz danych.
Wyobraź sobie, że LinkedIn używał tego zapytania SQL do sprawdzania Twojego hasła podczas logowania (zastrzeżenie: z pewnością stosują coś bardziej zaawansowanego niż przedstawione tutaj zapytanie SQL).
Gdyby teoretycznie pola na stronie logowania nie były oczyszczane, mógłbyś wpisać ' OR '1'='1 w polach nazwy użytkownika i hasła, a następnie kliknąć przycisk Zaloguj się.
W takim przypadku zaplecze dodałoby Twoje ' OR '1'='1 do zapytania SQL, które wyglądałoby mniej więcej tak.
To zapytanie zwróci wartość „prawda.” Oznacza to, że można byłoby zalogować się do LinkedIn bez posiadania prawidłowej nazwy użytkownika i hasła.
Jak już wspomniałem, możesz uniknąć tego problemu, oczyszczając dane wejściowe. Oczyszczanie w tym kontekście oznacza zapewnienie, że wszystko, co wpisujesz w polach wejściowych, jest traktowane jak zwykły tekst, nawet jeśli wpisujesz kod lub zapytanie SQL.
W przypadku oczyszczonych danych wejściowych LinkedIn spróbuje wyszukać w bazie danych użytkownika o nazwie ' OR '1'='1, zamiast wykonywać kod. Ostatecznie nie znajdzie takiej osoby i wyświetli błąd informujący, że na LinkedIn nie ma takiej osoby.
Uwaga
Oczywiście, powyższy przykład jest uproszczeniem, a cyberataki w rzeczywistości są znacznie bardziej złożone. Jeśli jednak chcesz poznać szczegóły techniczne i dowiedzieć się więcej o tych atakach, polecam zajrzeć do książki Justina Clarke-Salta dotyczącej
Ochrona przed wstrzyknięciami SQL to jeden z podstawowych kroków, które możesz podjąć, aby zabezpieczyć dane swoich klientów oraz uniknąć szkodliwych wycieków danych i nieautoryzowanego dostępu.
2. Skrypty międzywitrynowe (XSS)
XSS to kolejny popularny sposób, w jaki hakerzy mogą manipulować Twoim produktem i wykorzystywać go w złośliwy sposób. Aby wyobrazić sobie, jak powszechne jest XSS, wystarczy wspomnieć, że raport Positive Technologies szacuje, że około 90% wszystkich dostępnych aplikacji internetowych jest podatnych na ten rodzaj ataku.
Na czym to polega? XSS przypomina nieco wstrzyknięcie SQL pod względem manipulowania przez hakerów systemem w celu wykonania kodu, który nie powinien zostać wykonany. W tym przypadku złośliwy kod nie jest jednak uruchamiany w backendzie ani bazach danych systemu, lecz we frontendzie.
Jednym z zabawnych i nieszkodliwych przykładów XSS jest samodzielnie podający dalej tweety Twittera (tak, nadal nazywam go Twitterem — spróbuj mnie przekonać, że jest inaczej) z emoji serca. To zabawne, ponieważ nikt nie spodziewał się, że Twitter popełni tak ogromny błąd, a nieszkodliwe, ponieważ jedyne, co się działo, to ponowne podawanie tego samego tweeta.
Atak ten był po prostu tweetem zawierającym poniższy tekst.
Jak wyraźnie widać na obrazie, nie jest to zwykły tekst, lecz fragment kodu (dokładniej JavaScript z jQuery) z emoji serca na końcu.
Zanim Twitter naprawił tę lukę w zabezpieczeniach, po otwarciu tego tweeta w przeglądarce jej silnik rozpoznawał jego zawartość jako prawidłowy kod, ukrywał ją przed użytkownikiem i uruchamiał. Zamiast dwóch wierszy kodu widziałeś więc tylko tweet z emoji serca.
Po uruchomieniu kod przeszukiwał kod HTML strony, automatycznie znajdował przycisk ponownego podania tweeta na ekranie i klikał go.
Oznaczało to, że każda osoba wyświetlająca ten tweet automatycznie podawała go dalej — w rezultacie ogromna część użytkowników Twittera została nim zainfekowana.
A teraz wyobraź sobie, że nie był to samoreplikujący się tweet, lecz coś bardziej szkodliwego, na przykład skrypt, który pobierałby poufne informacje z ekranu i wysyłał je hakerowi. Złośliwy kod w przeglądarce mógłby też przejąć kontrolę nad aplikacją bankowości internetowej i rozpocząć przelewanie środków z Twojego konta.
Rozumiesz, o co mi chodzi — XSS jest nadal niezwykle niebezpieczne, mimo że nie może uzyskać dostępu do serwerów i baz danych.
Co to jednak oznacza dla Ciebie jako menedżera produktu? Możesz na przykład poprosić inżynierów o dodanie ciekawych funkcji i integracji, takich jak umożliwienie witrynie wyświetlania zawartości innych kart w przeglądarce użytkownika i wykonywania z tymi informacjami czegoś interesującego.
Jeśli tak zrobisz, a Twój zespół odmówi zbudowania takiej funkcji, nie dziw się ani nie smuć, ponieważ w istocie prosisz o przeprowadzenie ataku XSS na innych stronach.
XSS to fascynujący obszar cyberbezpieczeństwa i mogę polecić wiele świetnych książek na ten temat. Moją ulubioną jest „Ataki XSS” Setha Fogiego.
3. Niezabezpieczone interfejsy API
Interfejsy programowania aplikacji (znane również jako API) są środkiem komunikacji między serwerem a przeglądarką użytkownika lub aplikacją na jego urządzeniu mobilnym albo komputerze.
Gdy zachodzi potrzeba uzyskania, przechowania lub przetworzenia danych na serwerze, przeglądarka lub aplikacja (znane również jako „klienci”) wysyła do serwera żądanie zawierające niezbędne informacje. Następnie serwer wykonuje zadanie i zwraca odpowiedź.
Na przykład podczas logowania klienci wysyłają nazwę użytkownika i hasło oraz proszą serwer o uwierzytelnienie. Gdy serwer zakończy obsługę żądania, odsyła komunikat „sukces” wraz z zawartością strony, którą użytkownik powinien zobaczyć po zakończeniu logowania.
Ponieważ API pracują z danymi użytkowników, są również podatne na luki w zabezpieczeniach, które mogą prowadzić do złośliwej manipulacji danymi (np. poproszenia serwera o wykonanie przelewu w imieniu użytkownika) lub naruszenia poufności danych (np. poproszenia serwera o ujawnienie dokumentacji medycznej użytkownika).
Najczęstsze rodzaje podatności API to:
Brak uwierzytelniania: W tym przypadku API nie wymaga od klienta potwierdzenia tożsamości, zanim udostępni poufne informacje. Aby zrozumieć, jak to działa, wyobraź sobie, że ktoś poszedł do banku i poprosił o wypłatę pieniędzy z konta Marka Zuckerberga, a kasjer po prostu odpowiedział: „Oczywiście, ile?”
Brak ograniczania liczby żądań: W tym przypadku interfejsy API nie przestaną przetwarzać żądań, nawet jeśli będzie ich zdecydowanie za dużo — znacznie więcej, niż powinno — co doprowadzi do przeciążenia i awarii serwera. Taki nadmierny napływ żądań ma miejsce, gdy ktoś próbuje przeprowadzić na Twoich serwerach atak DDoS.
Nadmierne ujawnianie danych: Ma to miejsce, gdy odpowiedzi interfejsu API zawierają informacje, do których dostęp nie powinien być możliwy. Załóżmy na przykład, że podczas wysyłania pieniędzy komuś za pośrednictwem bankowości internetowej powiadomienie interfejsu API o pomyślnym przeprowadzeniu transakcji zawiera również saldo rachunku odbiorcy — czyli coś, czego zdecydowanie nie powinieneś widzieć.
Rozwiązania tych trzech podatności są dość oczywiste. Należy wymagać uwierzytelniania podczas udostępniania poufnych danych, dodać ograniczanie liczby żądań i upewnić się, że nie udostępniasz danych, które nie powinny się tam znajdować.
Jeśli chcesz nieco dokładniej zgłębić temat bezpieczeństwa interfejsów API, możesz sięgnąć po książkę Neila Maddena na ten temat.
4. Brak szyfrowania
Mój szef ds. bezpieczeństwa uwielbia stale powtarzać, że dobrze zrealizowana strategia cyberbezpieczeństwa produktu przypomina cebulę — składa się z wielu warstw zabezpieczeń obejmujących różne części produktu.
Wszystko, o czym rozmawialiśmy do tej pory, dotyczyło zagrożeń bezpieczeństwa na warstwie powierzchniowej, gdy użytkownik nie może uzyskać dostępu do serwerów ani baz danych i próbuje zaatakować system „od zewnątrz”.
Jeśli jednak hakerowi uda się w jakiś sposób uzyskać pełny dostęp do serwerów (przeniknąć przez pierwszą warstwę), nadal powinieneś mieć wdrożone środki chroniące bazy danych przed jego nieautoryzowanym dostępem — tak aby zabezpieczyć również wewnętrzne warstwy.
Jednym z najlepszych sposobów ochrony danych w takim przypadku jest ich szyfrowanie. Oznacza to, że nawet jeśli ktoś uzyska dostęp do baz danych i pobierze te dane, będą one dla niego bezładnym ciągiem znaków, ponieważ są zaszyfrowane.
Tylko firma lub użytkownik — czyli dwie strony posiadające klucz szyfrujący — mogliby odszyfrować ten bezładny ciąg znaków i przekształcić go w użyteczne informacje. Niestety zapominanie o szyfrowaniu danych na serwerach jest niezwykle powszechne i doprowadziło do licznych ogromnych wycieków danych.
Osobiście widziałem zbyt wiele witryn i produktów, które zaryzykowały, przechowując hasła użytkowników w postaci zwykłego tekstu — coś takiego jest uznawane za grzech śmiertelny w oprogramowaniu. Najlepszą praktyką w takim przypadku jest przepuszczenie hasła przez algorytm funkcji skrótu, uzyskanie jego zaszyfrowanej wersji (zwanej skrótem) i przechowywanie właśnie jej.
Zaletą tego rozwiązania jest to, że zarówno użytkownik, jak i firma mają klucz pozwalający przekształcić skrót z powrotem w postać zwykłego tekstu i użyć tego hasła do uwierzytelniania. Jeśli jednak haker uzyska dostęp do bazy danych i pobierze skrót, przekształcenie go z powrotem w oryginalne hasło wymagałoby od niego milionów lat obliczeń bez klucza. (Nie żartuję, to prawdziwa liczba!)
Szyfrowanie to kolejny fascynujący obszar cyberbezpieczeństwa, z którym warto się zapoznać. W szczególności możesz zacząć od nauki tego, jak działa kryptografia klucza publicznego, ponieważ właśnie na niej opiera się obecnie cały internet.
Włączanie bezpieczeństwa aplikacji do cyklu życia produktu i tworzenia oprogramowania
Mając na uwadze wszystkie te podatności i najlepsze praktyki, skupmy się na oczywistym pytaniu, które możesz sobie zadawać — jak jako kierownik produktu mam zapewnić bezpieczeństwo swoich produktów?
Myślałem, że nigdy nie zapytasz! Oto dwie ważne najlepsze praktyki w zakresie bezpieczeństwa, które mogą Ci w tym pomóc:
Bezpieczne produkty z założenia
To podejście do procesu tworzenia oprogramowania zakłada, że wymagania dotyczące bezpieczeństwa należy uwzględniać od samego początku budowania produktów, aby środki bezpieczeństwa były natywnie zintegrowane z kodem i architekturą, zamiast być dodawane później w ramach cyklu życia tworzenia oprogramowania.
To drugie rozwiązanie jest zazwyczaj znacznie droższe i nie zapewnia takiego samego poziomu ochrony jak oprogramowanie „natywnie” bezpieczne.
Dlatego jako kierownik produktu masz obowiązek poprosić zespół programistów o stosowanie tego podejścia i powstrzymać się od obniżania priorytetu elementów, które pomagają wbudować bezpieczeństwo w produkt.
More Articles
Regularne audyty bezpieczeństwa
Większość produktów, którymi zarządzałem, przechodziła regularne testy bezpieczeństwa (zwykle raz na sześć miesięcy lub raz w roku). Testowaliśmy cały poziom bezpieczeństwa, a obejmowało to:
- Testy penetracyjne
- Modelowanie zagrożeń
- Przegląd mechanizmów kontroli bezpieczeństwa
- Przegląd strategii bezpieczeństwa i funkcji bezpieczeństwa
- Przegląd łańcucha dostaw i przepływów pracy związanych z automatyzacją
- Analiza kodu (w tym wykorzystanego przez nas kodu open source oraz kodu uzyskanego w ramach partnerstw z podmiotami zewnętrznymi)
- Tworzenie planu działań na rzecz bezpieczeństwa i wskaźników
- Ocena ryzyka
- ...i nie tylko!
Jest to ważne, ponieważ Twój produkt stale się rozwija, a podczas dodawania nowych elementów możesz przypadkowo naruszyć bezpieczeństwo swojego oprogramowania. Regularne audyty szybko zidentyfikują te problemy i pozwolą Ci je naprawić oraz zweryfikować — zanim jako pierwszy znajdzie je ktoś o złych zamiarach.
Jako menedżer produktu musisz przeznaczać czas na te audyty i ustalać ich priorytety, a także priorytety porządkowania kodu, które następuje po ich przeprowadzeniu.
Zaufaj swoim specjalistom ds. bezpieczeństwa
Niezależnie od tego, jaką funkcję planujesz zbudować i jaki plan działania masz na osiągnięcie celów związanych ze wzrostem, zawsze upewnij się, że omówiłeś swoje pomysły z zespołem ds. bezpieczeństwa.
I słuchaj — może Ci się wydawać, że specjaliści ds. bezpieczeństwa chcą nadmiernie zabezpieczyć Twój produkt. Jednak w większości przypadków, jeśli nie podoba im się Twój pomysł, powinieneś rozważyć wprowadzenie w nim zmian. W przeciwnym razie ryzyko po prostu nie jest tego warte.
A skoro mowa o rozważaniu różnych kwestii, rozważ także zapisanie się do naszego newslettera, aby otrzymywać bezpośrednio na swoją skrzynkę odbiorczą wiele poradników i artykułów dotyczących zarządzania produktem!
