https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:15:02 GMT https://archive.mroczna-zaloga.org/templates/bulletproof/img/s9y_banner_small.png https://archive.mroczna-zaloga.org/ 100 21 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#c4434 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1048 nospam@example.com (Paweł Goleń) I ponownie się z Tobą zgadzam. "Drzewka", o których mówię, prowadzą do celu. Czyli mechanizmy bezpieczeństwa mające uniemożliwić określone scenariusze ataków są relewantne. Wed, 19 Oct 2011 16:51:55 +0200 https://archive.mroczna-zaloga.org/archives/1048-guid.html#c4434 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#c4433 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1048 nospam@example.com (kravietz) Ale mechanizm bezpieczeństwa, żeby działał, musi być relewantny. Na przykład w raportach można bez końca tłuc, że serwer nie wystawia cookie i httpOnly, więc jest "non-compliant". A tymczasem jest to strona bez żadnego logowania, więc httpOnly jest psu na budę w tym przypadku. Oczywiście, z punktu best practice można się spytać po co w ogóle wystawia cookie w takim razie - ale to też jest trochę sztuka dla sztuki. A to co mnie rzeczywiście interesuje w przypadku takiej strony to cała gama ataków nie związanych z sesjami. A compliance to sobie mogę sprawdzić skanerem bo akurat do takiego bezmyślnego sprawdzania checklisty się nadaje. Wed, 19 Oct 2011 11:31:41 +0200 https://archive.mroczna-zaloga.org/archives/1048-guid.html#c4433 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#c4419 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1048 nospam@example.com (Paweł Goleń) Tak, bo pod pojęciem "audytu bezpieczeństwa" zrozumieć można bardzo wiele rzeczy. Konkretne określenie tego, o co właściwie chodzi, bardzo pomaga. W opisanym przez Ciebie przypadku podejście "znajdź realny scenariusz" ma szanse powodzenia. W pewnym stopniu jest to poskładanie klocków, które generuje na wyjściu skaner w coś, co można realnie użyć. To trochę tak, jakby z tych klocków próbować ułożyć całe drzewko. Ja wolę, mimo wszystko, podejście od strony weryfikacji istnienia mechanizmu bezpieczeństwa i jego poprawnego działania. Ale takie podejście świetnie jest uzupełniane przez to, które opisałeś. Być może przy oryginalnych "drzewkach" coś nie zostało uwzględnione lub zmieniła się sytuacja/stan wiedzy na tyle, że drzewko musi zostać przebudowane. Tue, 18 Oct 2011 13:56:49 +0200 https://archive.mroczna-zaloga.org/archives/1048-guid.html#c4419 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#c4418 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1048 nospam@example.com (kravietz) Odpowiem pokrętnie. Otóż różnica w cenie polega głównie na tym, że ja i tak płacę za test penetracyjny wykonany przez 3rd party. Problem polega na tym, że testy te w ciągu ostatnich 10 lat de facto zmieniły się w mniej lub bardziej zaawansowane skany podatności. Ale płaci się za nie nadal jak za testy penetracyjne. To strata pieniędzy. Stąd prosta operacja, którą zrobiłem u siebie polegała na przedefiniowaniu zakresu i celu testów. Test 3rd party jest płacony po staremu, od dnia, ale celem nie jest już "znalezienie podatności wg OWASP Top 10" (klasyka tego typu zamówień) tylko wskazanie realistycznych scenariuszy ataku. PoC jest mile widziany (zwłaszcza jeśli jest to jeden URL) ale nie kluczowy. Chodzi o to, żeby zespół nie skupiał się na wyszukiwaniu łatwych do znalezienia bzdur w stylu "brakująca flaga httpOnly" w celu zapchania raportu, tylko wskazał REALNE RYZYKA aplikacji. Dla ułatwienia PRZED testem podsyłam im raport z Burpa czy AppScana, żeby mieli świadomość czego NIE muszą wykazać w rapocie. Jeśli nie w raporcie napiszą nic - to super, tym lepiej! Przed tym eksperymentem przeprowadziłem rozmowę z naszym dostawcę w celu wyjaśnienia im o co mi chodzi. Co ciekawe, ich reakcja była dość entuzjastyczna i wcale nie wyglądali na zmartwionych tym, że w idealnym przypadku raport mógłby być teoretycznie pusty przez co ja mógłbym teoretycznie pomyśleć, że nic nie zrobili :) Do tej pory wyniki tego eksperymentu są dobre. Jeśli raport zawiera 1-2 realne dziury z PoC to developerom można to wytłumaczyć czarno na białym, bez budowania mało przekonujących scenariuszy rodem z The Incredible Machine ("brak httpOnly teoretycznie grozi tym, że gdybyście potencjalnie używali..."). A ja oczywiście mam też raport z AppScana czy Burpa i jeśli ma to sens to dodanie httpOnly też zalecam, albo w pewnych przypadkach wymagam. ASVS - jak najbardziej. Próbuję to też wprowadzić ale im bardziej próbuję tym bardziej zakresy ASVS rozjeżdżają mi się z rzeczywistością. Koncepcja różnych poziomów dokładności testowania jest bardzo dobra (podobnie zresztą jest w Common Criteria) ale poziomy ASVS wydają mi się zbudowane trochę sztucznie i na siłę. Po prostu, jeśli testuje się X to wiadomo, że przy okazji przetestuje się też Y - a w ASVS są one sztucznie rozdzielone na różne poziomy. Podział na testy ręczne i automatyczne też jest sztuczny - przecież nikt nie robi testów w 100% ręcznych, a test automatem ma sens tylko wtedy gdy ktoś te wyniki ręcznie zweryfikuje (zwłaszcza przy SCA). Mam pewien zbudowany ad hoc podział tych technik na różnych poziomach wg dokładności i kosztu ale muszę nad nim jeszcze popracować. Tue, 18 Oct 2011 12:44:17 +0200 https://archive.mroczna-zaloga.org/archives/1048-guid.html#c4418 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#c4417 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1048 nospam@example.com (Paweł Goleń) To ja się Ciebie podstępnie zapytam - ile jesteś w stanie zapłacić za drugi wariant? I czy dobrze się czujesz ze świadomością, że wykazana w PoC metoda wyprowadzenia danych z aplikacji może być jedną z wielu? Mnie bardziej podoba się podejście sugerowane przez ASVS. Moim zdaniem daje ono szerszą perspektywę, niż podejście, które z dużym prawdopodobieństwem sprowadzi się do znalezienia jednej/kilku najbardziej oczywistych podatności i eksploitowania ich do granic możliwości. W każdym razie temat jest istotny i wydaje mi się, że można taką dyskusję uskutecznić np. w ramach OWASP. Podobnie jak tematy, o których ostatnio pisałeś - jak NIE zamawiać testów :) Tue, 18 Oct 2011 11:20:27 +0200 https://archive.mroczna-zaloga.org/archives/1048-guid.html#c4417 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#c4416 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1048 nospam@example.com (kravietz) Poruszyłeś tutaj bardzo istotny problem - jaki KONKRETNIE jest cel testu (celowo nie piszę jakiego, żeby nie wpadać w pułapki semantyczne)? Ja po długich zmaganiach się z tematem mogę wyróżnić następujące przypadki: 1) Sprawdzenie na ile aplikacja jest zgodna z najlepszymi praktykami inżynierskimi. W takim przypadku nie mamy do czynienia z testem penetracyjnym tylko skanem podatności lub oceną bezpieczeństwa i 80% wyników dostarczy nam automat. Tu wpadają wszystkie brakujące httpOnly i podobne "podatności". PoC nie jest wymagany. Jestem zwolennikiem robienia takich testów na etapie rozwijania aplikacji choćby i co tydzień. A jeszcze lepiej przy pomocy SCA bo nie trzeba mieć do tego działającego prototypu. 2) Sprawdzenie czy ta KONKRETNA instancja aplikacji jest podatna na REALNE ataki - czyli czy można z niej ukraść dane albo wzbogacić XSSem czy malware. Jest to test penetracyjny w jego historycznym i dosłownym znaczeniu. Odpowiada na pytanie: czy tę aplikację można dopuścić do użytku? Oczekiwałbym tutaj konkretnego PoC. I zdecydowanie nie chciałbym tutaj widzieć odpowiedzi w stylu "istnieje potencjalna możliwość iż zostanie to pod pewnymi warunkami ewentualnie wykorzystane". Na liście podatności nie chciałbym widzieć "brak httpOnly", bo to niczego nowego nie wnosi, tylko czy da się ukraść sesję czy nie. Stosując terminologie inżynierską w obu przypadkach mamy do czynienia z pomiarami. W pierwszymi przypadku pomiarem zgodności z najlepszymi praktykami inżynierskimi. Wynik ten może być skorelowany z ryzykiem aplikacji ale luźno i w mglisty sposób. Z realnym pomiarem ryzyka aplikacji mamy w drugim przypadku. Tue, 18 Oct 2011 11:14:32 +0200 https://archive.mroczna-zaloga.org/archives/1048-guid.html#c4416 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#c4385 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1048 nospam@example.com (Paweł Goleń) Konkretnie to z FreePlane :) Thu, 06 Oct 2011 15:14:43 +0200 https://archive.mroczna-zaloga.org/archives/1048-guid.html#c4385 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#c4384 https://archive.mroczna-zaloga.org/archives/1048-0b10-0b01-exploit.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1048 nospam@example.com (Kos) Yay, grafiki z freeminda? :) Thu, 06 Oct 2011 14:36:19 +0200 https://archive.mroczna-zaloga.org/archives/1048-guid.html#c4384