Co to jest lista Top 10 luk w zabezpieczeniach OWASP?
wydana po raz pierwszy w 2004 roku przez Open Web Application Security Project, słynna lista Top 10 luk w zabezpieczeniach OWASP (zamieszczona na dole artykułu) jest prawdopodobnie najbliższa społeczności programistów do zbioru przykazań dotyczących bezpieczeństwa swoich produktów.,
Ta lista przedstawia najistotniejsze zagrożenia dla bezpieczeństwa oprogramowania według OWASP, dla wielu, którzy zastanawiają się, jak SQL Injection jest nadal takim problemem po tylu latach. Oceniają typy luk w zabezpieczeniach na podstawie czterech kryteriów:
- łatwość wykorzystania
- rozpowszechnienie
- wykrywalność
- wpływ na biznes
Co ciekawe, OWASP stwierdza, że w rzeczywistości nie biorą pod uwagę prawdopodobieństwa, że atakujący spróbują wykorzystać określoną lukę.,
Kiedy się zaczęło, pisarze zdecydowali, że najlepszym sposobem na pokrycie jak największej powierzchni jest umieszczenie podobnych luk, które uważali za najbardziej niepokojące w grupach. Uznali, że bez odpowiednich statystyk zawsze może pojawić się pytanie, które luki w zabezpieczeniach są koniecznie najważniejszymi zmartwieniami, zwłaszcza że może to być subiektywne pytanie zgodnie z modelem zagrożeń każdej organizacji.
jednak po wielu dyskusjach zaproponowali swoją listę tego, co uważali za adresowane do najszerszego grona organizacji, choć nie w żadnej szczególnej kolejności.,
z czasem lista Top 10 Vulnerabilities OWASP została przyjęta jako standard najlepszych praktyk i wymagań przez wiele organizacji, ustanawiając standard w pewnym sensie dla rozwoju. Jednym ze znanych użytkowników tej listy są standardy przetwarzania płatności PCI-DSS.
Niestety, ponieważ lista 10 najlepszych luk w zabezpieczeniach OWASP dotarła do szerszego grona odbiorców, jej prawdziwe intencje jako przewodnika zostały źle zinterpretowane, raniąc deweloperów zamiast pomagać. Jak zatem rozumieć cel tej listy i faktycznie zachęcać programistów do bezpieczniejszego kodowania?,
zrozumienie aktualizacji listy z 2017 r.
w ostatnich latach firma odświeżyła i zmieniła kolejność wpisów, dodając nowe typy luk, gdy stają się istotne, nawet gdy inne zostały usunięte z listy. Nowe wersje zostały wydane w 2010, 2013 i 2017 roku. Nowa lista została zebrana po długim i żmudnym badaniu, w którym przeanalizowano ponad 50 000 aplikacji i przeanalizowano około 2,3 miliona luk w zabezpieczeniach.,
regularni obserwatorzy listy zauważą, że wraz ze zmianami w kolejności — pomimo faktu, że ataki iniekcyjne pozostają na szczycie — pojawiają się nowi użytkownicy zaktualizowanej wersji rodziny luk OWASP Top 10 z 2017 roku.
, Jego umieszczenie na liście w miejscu numer A10 jest prawdopodobnie wynikiem faktu, że deweloperzy są po prostu znacznie bardziej zależni od interfejsów API niż kiedyś, współdziałając z znacznie większą liczbą komponentów i produktów zewnętrznych niż wcześniej. Pojawianie się w miejscu A7 jest niewystarczającą ochroną przed atakami, co uderza deweloperów za to, że nie są wystarczająco wszechstronni w dodawaniu zabezpieczeń do wykrywania, rejestrowania i oczywiście reagowania na próby uszkodzenia ich produktów.,
inną ważną zmianą w wersji 2017 jest połączenie niezabezpieczonych bezpośrednich odniesień do obiektów A4 i kontroli dostępu na poziomie brakującej funkcji A7, tworząc zunifikowaną lukę w kontroli dostępu i podkreślając konieczność prawidłowego ustanowienia kontroli, kto może i nie może uzyskać dostępu do kont i danych.,
błędna interpretacja listy 10 najlepszych luk w zabezpieczeniach OWASP
Ta lista niestety stała się narzędziem do zawstydzania programistów, którzy nie przestrzegają jej nauk, używanym jako klub, aby krytykować ich za to, że nie są idealni, jeśli chodzi o bezpieczeństwo. Takie podejście przynosi efekty odwrotne do zamierzonego i nie spełnia misji OWASP, polegającej na zachęcaniu i wyposażaniu programistów w bezpieczniejsze kodowanie. Co więcej, nie rozpoznaje osiągnięć wielu programistów, którzy wypychają ogromne ilości nowego oprogramowania w niespotykanym dotąd tempie.,
W niedawnym wywiadzie Przewodniczący OWASP Martin Knobloch wyraził rozczarowanie, że lista jest używana jako rodzaj listy kontrolnej do ostatecznego przejrzenia przed wydaniem, służącej bardziej jako mechanizm walidacji niż przewodnik.
jako ktoś, kto mocno wierzy w lewicowe podejście do bezpieczeństwa, nie dziwi mnie przytłaczająca frustracja Knoblocha związana z tym, jak wielu z nich przyjęło listę OWASP Top 10 jako instrument FUD, a nie Zestaw przewodnich zasad, którymi miała być.,
wymagające podejścia branżowe do bezpieczeństwa
organizacyjne strategie bezpieczeństwa, które zależą od spodziewania się porażki ze strony ludzkich elementów w zabezpieczeniu oprogramowania na rzecz błyszczących narzędzi, są skazane na porażkę.
w ostatnich latach wiadomości od zbyt wielu dostawców, zwłaszcza po stronie sieci, było to, że „obwód jest martwy” i że firmy muszą szukać zabezpieczeń na głębokości, aby znaleźć złych facetów, którzy są już w ich sieci., Zbyt wiele nagłówków na konferencjach próbowało przekonać CISOs, że zespoły elitarnych hakerów polują na nich z rzadkimi 0-dniowymi wyczynami, które pozostawią ich bezbronnych, chyba że kupią ich produkt, który w jakiś sposób uczyni ich nie do zdobycia dla tych niepowstrzymanych ataków.
to spojrzenie na stan bezpieczeństwa jest niepotrzebnie fatalistyczne, kapiące marketingowym szumem i pomija niektóre z podstawowych koncepcji, jak specjaliści od bezpieczeństwa powinni myśleć o ryzyku.,
kompleksowe podejście do bezpieczeństwa nie powinno głosić usuwania ludzkich programistów z procesu, tylko po to, aby wprowadzić narzędzia bezpieczeństwa dostawcy do naprawy po zakończeniu pracy. Zakłada to, że deweloperom nie można ufać, jest to obraźliwe i nie czyni nic, aby wzmocnić zespół, jeśli chodzi o bezpieczeństwo i zarządzanie ryzykiem.
czym jest i nie jest lista Top 10 luk OWASP
kilka razy w roku pojawia się obowiązkowy wpis na blogu z pytaniem, Jak to możliwe, że w 2017 roku wciąż mówimy o atakach na poziomie script kiddie., Prawdopodobnie sam napisałem kilka z nich, za co przepraszam.
OWASP Top 10 nie jest skonfigurowany, aby rozwiązać każdy atak w książce, ale aby pomóc zespołom uniknąć typowych błędów, które są znacznie bardziej narażone na naruszenie ich aplikacji. Zdeterminowany napastnik może znaleźć wiele dróg do przebicia się do celu. Jednak doradztwo w zakresie inteligentnego zarządzania ryzykiem Nie koncentruje się na mniejszości przypadków, ale zamiast tego stara się rozwiązać problemy, z którymi boryka się najszersza grupa odbiorców.,
aby czerpać z koncepcji bezpieczeństwa fizycznego, Przeciętna menedżerka ryzyka powinna bardziej martwić się o wypadek na drodze, niż Ninja szkoleni przez SEAL Team 6, przechodzący przez okna, prowadzony przez AI (i blockchain).
Real security polega na szkoleniu ludzi, jak bezpiecznie pracować i przekazywaniu im technologii, wiedzy i procesów, aby ułatwić im pozostanie bezpiecznym., Chociaż zawsze ważne jest, aby przeprowadzić kontrolę jakości i ostateczną kontrolę bezpieczeństwa przed wydaniem, zabezpieczenia muszą rozpocząć się na najwcześniejszych etapach pracy zespołu, biegnących przez cały proces opracowywania produktu. Błędy będą się zdarzać, ale znacznie bardziej opłacalne i wręcz mądrzejsze jest unikanie jak największej liczby problemów.
dla wielu programistów głównym celem jest doprowadzenie Produktu do działania, skupiając się mniej na tym, czy jest on bezpieczny. To nie ich wina.,
w trakcie swojej edukacji dowiedzieli się, że jeśli wyprodukują produkt z minimalną ilością błędów, to dostaną szóstkę. Zamiast tego menedżerowie muszą skorzystać z okazji, aby pokazać im lepszy sposób pracy, który obejmuje rozważenie, w jaki sposób kodują i komponenty, z którymi pracują, wpływają na bezpieczeństwo ich produktu.,
GET 451 RESEARCH ' s REPORTON zabezpieczanie oprogramowania OPEN SOURCE pobierz za darmo
praktyczne kroki, aby umożliwić lepsze praktyki bezpieczeństwa
częstą pułapką, która wyszła z Dni Rozwoju waterfall było czekać do końca cyklu rozwoju na przeprowadzenie kontroli bezpieczeństwa, w którym deweloperzy otrzymaliby listę luk do naprawienia, opóźniając wydanie i zwiększając tarcie między nimi a zespołem ds. bezpieczeństwa.,
w nadziei, że uda nam się poprawić jakość narzędzi i nadążyć za szybkością DevOps, organizacje poszukują nowych sposobów na zabezpieczenie kodu od samego początku i utrzymanie harmonii między swoimi działami.
jedną z coraz bardziej popularnych metod wprowadzania bezpieczeństwa na wcześniejsze etapy rozwoju produktu jest zapylanie krzyżowe zespołów z mieszanką programistów i osób zajmujących się bezpieczeństwem, dzięki czemu każda ze Stron może wnieść wkład i uczyć się od siebie nawzajem., Może to być doskonała okazja dla ekspertów ds. bezpieczeństwa, aby poruszyć wiele problemów, które OWASP Top 10 próbuje rozwiązać w mniej konfrontacyjnym środowisku, na etapie, który może rzeczywiście mieć wpływ.
jeśli chodzi o narzędzia, które mogą pomóc w lepszym wdrażaniu zabezpieczeń, musimy myśleć nie tylko o tym, jak technologia może wychwycić nasze błędy lub naruszenia, ale także pomóc nam pracować mądrzej i bezpieczniej od najwcześniejszych etapów., Ta perspektywa jest nieodłączną częścią mentalności lewicowej, szukającej możliwości rozwiązania problemów, zanim staną się one kosztownymi problemami.
integracja technologii w celu zwiększenia możliwości programistów
jasny przykład tego, jak technologie przesuwania w lewo mogą pomóc programistom w wykorzystaniu TOP 10 OWASP zawiera wpis numer 9, który ostrzega przed używaniem komponentów ze znanymi lukami w zabezpieczeniach. Jednym z najczęstszych problemów, które pojawiają się w tej przestrzeni, jest uzyskanie wglądu w to, co znajduje się w komponentach open source, które dodali do swojego produktu.,
Programiści prawie zawsze zwracają się do komponentów open source, aby pomóc im szybciej i wydajniej budować swój produkt, dodając zaawansowane funkcje bez konieczności pisania nowego kodu samodzielnie.
w większości przypadków jest mało prawdopodobne, aby sprawdzić, czy komponent ma znane luki przed dodaniem go do swojego produktu. Nawet jeśli wykonają pobieżną kontrolę, aby sprawdzić, czy nie ma żadnych konkretnych problemów, jest mało prawdopodobne, aby byli świadomi jakichkolwiek problemów w zależnościach komponentu.,
jednak, jeśli używają narzędzia do analizy składu oprogramowania, mogą faktycznie otrzymać przydatne informacje o tym, czy komponent open source ma jakiekolwiek znane luki związane z nim w całym cyklu życia oprogramowania (SDLC), oszczędzając im czas, który w przeciwnym razie mógłby zostać poświęcony na rozdzieranie i wymianę komponentu po sprawdzeniu przez zespół ds. bezpieczeństwa później w dół linii przed wydaniem po zaangażowaniu go w ich kod.,
bądź aktywatorem bezpieczeństwa w swojej organizacji
na podstawie moich odczytów z OWASP Top 10 i komentarzy Knoblocha, lista powinna być traktowana jako narzędzie ułatwiające zespołom włączanie zabezpieczeń w proces myślenia o tym, jak kodują, konfigurują i wysyłają swoje produkty.
zespoły ds. bezpieczeństwa, które nie współpracują ze swoimi programistami, starając się zrozumieć, w jaki sposób mogą sprawić, że bezpieczeństwo będzie nieodłącznym elementem ich przepływu pracy, szybko znajdą się na uboczu.,
Jeśli chcesz być na bieżąco, zostań enablerem i użyj listy Top 10 OWASP jako sposobu na rozpoczęcie rozmów, a nie na groźby. W końcu może się okazać, że złapiesz więcej (O)OS z miodem niż octem.
oficjalna lista 10 najlepszych luk w zabezpieczeniach OWASP
A1. Injection-błędy Injection, takie jak SQL, NoSQL, OS i LDAP injection, występują, gdy niezaufane dane są wysyłane do interpretera jako część polecenia lub zapytania. Wrogie dane atakującego mogą skłonić interpretera do wykonania niezamierzonych poleceń lub uzyskania dostępu do danych bez odpowiedniej autoryzacji.
A2., Złamane uwierzytelnianie-funkcje aplikacji związane z uwierzytelnianiem i zarządzaniem sesjami są często implementowane nieprawidłowo, umożliwiając atakującym naruszanie haseł, kluczy lub tokenów sesji lub wykorzystywanie innych wad implementacji w celu tymczasowego lub trwałego przyjęcia tożsamości innych użytkowników.
A3. Narażenie na wrażliwe dane-wiele aplikacji internetowych i interfejsów API Nie chroni właściwie wrażliwych danych, takich jak dane finansowe, Opieka zdrowotna i PII. Atakujący mogą ukraść lub zmodyfikować tak słabo chronione dane w celu popełnienia oszustwa związanego z kartami kredytowymi, kradzieży tożsamości lub innych przestępstw., Poufne dane mogą zostać naruszone bez dodatkowej ochrony, takiej jak szyfrowanie w spoczynku lub podczas transportu, i wymaga specjalnych środków ostrożności podczas wymiany z przeglądarką.
A4. XML External Entities (XXE) – wiele starszych lub źle skonfigurowanych procesorów XML ocenia odniesienia do zewnętrznych encji w dokumentach XML. Podmioty zewnętrzne mogą być używane do ujawniania wewnętrznych plików za pomocą funkcji obsługi Uri plików, wewnętrznych udziałów plików, skanowania portów wewnętrznych, zdalnego wykonywania kodu i ataków typu denial of service.
A5.,Złamana Kontrola dostępu-ograniczenia dotyczące tego, co mogą robić uwierzytelnieni użytkownicy, często nie są odpowiednio egzekwowane. Atakujący mogą wykorzystać te wady, aby uzyskać dostęp do nieautoryzowanych funkcji i / lub danych, uzyskać dostęp do kont innych użytkowników, przeglądać poufne pliki, modyfikować dane innych użytkowników, zmieniać prawa dostępu itp.
A6. Błąd konfiguracji zabezpieczeń – błąd konfiguracji zabezpieczeń jest najczęściej spotykanym problemem., Często jest to wynikiem niezabezpieczonych konfiguracji domyślnych, niekompletnych lub ad hoc konfiguracji, otwartej pamięci masowej w chmurze, źle skonfigurowanych nagłówków HTTP i szczegółowych komunikatów o błędach zawierających poufne informacje. Wszystkie systemy operacyjne, frameworki, biblioteki i aplikacje muszą być nie tylko bezpiecznie skonfigurowane, ale także muszą być aktualizowane/aktualizowane w odpowiednim czasie.
A7.,Cross Site Scripting (XXS) – wady XSS występują, gdy aplikacja zawiera niezaufane dane na nowej stronie internetowej bez odpowiedniej walidacji lub ucieczki, lub aktualizuje istniejącą stronę internetową z danymi dostarczonymi przez Użytkownika za pomocą interfejsu API przeglądarki, który może tworzyć HTML lub JavaScript. XSS umożliwia atakującym wykonywanie skryptów w przeglądarce ofiary, które mogą przechwytywać sesje użytkownika, dezaktywować strony internetowe lub przekierowywać użytkownika do złośliwych stron.
A8. Niepewna Deserializacja-niepewna deserializacja często prowadzi do zdalnego wykonywania kodu., Nawet jeśli wady deserializacji nie skutkują zdalnym wykonywaniem kodu, mogą być używane do wykonywania ataków, w tym ataków replay, injection i privilege escalation.
A9. Używanie komponentów ze znanymi lukami-komponenty, takie jak biblioteki, frameworki i inne moduły oprogramowania, działają z tymi samymi uprawnieniami co aplikacja. Jeśli wrażliwy komponent zostanie wykorzystany, taki atak może ułatwić poważną utratę danych lub przejęcie serwera., Aplikacje i interfejsy API używanie komponentów ze znanymi lukami w zabezpieczeniach może osłabiać mechanizmy obronne aplikacji i umożliwiać różne ataki i oddziaływania.
A10. Niewystarczające rejestrowanie & monitorowanie-niewystarczające rejestrowanie i monitorowanie, w połączeniu z brakującą lub nieskuteczną integracją z reagowaniem na incydenty, pozwala atakującym na dalsze ataki na systemy, utrzymywanie trwałości, przełączanie do większej liczby systemów oraz manipulowanie, wydobywanie lub niszczenie danych., Większość badań nad naruszeniami wskazuje, że czas na wykrycie naruszenia wynosi ponad 200 dni, zazwyczaj wykrywany przez strony zewnętrzne, a nie wewnętrzne procesy lub monitorowanie.