OWASP ASVS 4.0 – czyli jak w uporządkowany sposób sprawdzić bezpieczeństwo aplikacji?

06 marca 2019, 16:10 | Aktualności | komentarze 2
: zin o bezpieczeństwie - pobierz w pdf/epub/mobi.

Najnowszy dokument dostępny jest tutaj. W największym skrócie jest to duża checklista podzielona na obszary (architektura, walidacja wejścia, uwierzytelnienie, obsługa błędów, …). W każdej z nich znajdziecie masę zaleceń służących zwiększeniu bezpieczeństwa aplikacji webowej.

Co zmieniło się w porównaniu do poprzednich wersji? Jak sami autorzy dość górnolotnie piszą:

New in 4.0 is a comprehensive mapping to the Common Weakness Enumeration (CWE), one of the most commonly desired feature requests we’ve had over the last decade.

Czyli mamy wskazane zalecenia powiązane z konkretnym numerem w bazie CWE (zawierającej opis znanych podatności aplikacyjnych), np.: sql injectionsession fixation, czy SSRF (jest ich setki). Przykład poniżej:

ASVS4

 

Dalej, mamy flagę ‚penetration testable’ – czyli informację, że dany obszar można zweryfikować za pomocą testów penetracyjnych (do tej pory część firm pisało: ‚zrobiliśmy pentesty, wasza aplikacja jest zgodna z ASVS’. Tyle, że była to nieprawda, bo niektórych punktów zwykłymi testami bezpieczeństwa nie dało się pokryć (np. rzeczy związane z architekturą czy monitorowaniem bezpieczeństwa).

Całym dokumentem będzie się też łatwiej posługiwać – sekcje zostały podzielone na podrozdziały. Czyli np. do tej pory pisany niemal litym tekstem rozdział  „V3: Session Management Verification Requirements” ma np. taką podsekcję: „V3.5 Token-based Session Management”. Nie używasz tokenów (np. JWT) do zapewnienia uwierzytelnienia i/lub autoryzacji. Nie ma problemu – wyrzucasz ze sprawdzania cały ten punkt.

ASVS4 stara się też iść w stronie maksymalnego uproszczenia zgodności – w części dotyczącej uwierzytelniania i obsługi sesji jest zgodny z nowoczesnym podejściem NIST-u: Digital Identity Guidelines (czyli bazuje na już wykonanej pracy, w stosownych punktach checklisty są wskazane konkretne podrozdziały w NIST-owej dokumentacji).

Całość ucieszy też tych, którzy muszą być zgodni ze standardem PCI:

ASVS 4.0 Level 1 is a comprehensive superset of PCI DSS 3.2.1 Sections 6.5, for application design, coding, testing, secure code reviews, and penetration tests.

Choć może być to jednocześnie problem – pojawiły się wymagania dotyczące podatności klasy buffer overflow, które w nowoczesnych aplikacjach od dawna praktycznie nie występują (kto ostatnio widział webowy sklep internetowy napisany w czystym C? ;) W poprzedniej wersji dokumentu mieliśmy mowę tylko o sprawdzeniu ‚runtime environment’ pod względem tego typu problemów.

Z drugiej strony ASVS został odchudzony z kilku mniej istotnych problemów (i w tą stronę ma iść dalszy rozwój dokumentu):

Lastly, we have de-duped and retired less impactful controls.

Miłego czytania i stosowania.

–ms

 

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. Audytor

    Hm, fajny dokument, ale w wielu instytucjach to będzie takie fonetycznie rzecz ujmując lastly de-…ed

    Odpowiedz
  2. hmm

    „2.1.2 Verify that passwords 64 characters or longer are permitted. (C6)” Czy przypadkiem zbyt długie hasła nie są problemem ze względu na proces szyfrowania? Wysłanie 4k znakow jako hasło potrafi wywołać spore lagi dla web apki która nie ma górnego limitu…

    Odpowiedz

Odpowiedz