https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:14:51 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/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#c4252 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1050 nospam@example.com (Paweł Goleń) Ciekawe spostrzeżenie. Masz rację, że nie mam zbyt wielkich doświadczeń z tego typu klientami. Rzeczywiście, część klientów najbardziej zainteresowana jest stwierdzeniem, że wszystko jest w porządku i najprawdopodobniej będzie wybierać takiego usługodawcę, który taką opinię wyda bez zbędnych korowodów (i za jak najmniejsze pieniądze). To trochę tak, jak z "ekspertyzami" różnego rodzaju produktów, które można usłyszeć w reklamach - nadają się głównie do robienia wody z mózgu klientom. Stanowczo nie moja bajka :) Fri, 26 Aug 2011 07:24:53 +0200 https://archive.mroczna-zaloga.org/archives/1050-guid.html#c4252 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#c4251 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1050 nospam@example.com (Pawel Rutkowski) Pewnie część Klientów (choć może nie Twoich) to tacy którzy zrobili aplikacje i robią audyt bo im zleceniodawca kazał. Boją się iść w "białasa" :) bo wtedy wyjdzie że są niekompetentni i im się oberwie że tak napisali aplikacje. Jak jest blackbox to jest większa szansa (zwłaszcza jak jest krótki deadline:) że pentester nie zauważy błędów. Fri, 26 Aug 2011 00:08:15 +0200 https://archive.mroczna-zaloga.org/archives/1050-guid.html#c4251 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#c4242 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1050 nospam@example.com (Paweł Goleń) Popatrz na to z nieco innej perspektywy. Wszystkie scenariusze ataku, które wykorzystują podatność SQLi są skutecznie likwidowane poprzez załatanie tej podatności. No chyba, że ktoś przy łataniu dziury wzniesie się na wyżyny kunsztu programistycznego i załata "blind SQLi", ale już innych wersji nie :) Mon, 22 Aug 2011 08:27:51 +0200 https://archive.mroczna-zaloga.org/archives/1050-guid.html#c4242 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#c4240 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1050 nospam@example.com (h1) Nie mam doświadczenia w temacie, ale tak na chłopski rozum podejście typu white box wydaje się zdecydowanie bardziej efektywne. Do głowy przychodzi mi jednak jedno, raczej teoretyczne, odstępstwo od tej reguły. Mogę sobie wyobrazić sytauację, w której znajomość szczegółów działania badanego obiektu powoduje, że sprawdzający przyjmuje założenia, które uniemożliwiają mu wykrycie słabości, czy też udowodnienie podatności. Przykład: http://archive.mroczna-zaloga.org/archives/787-theres-more-than-one-way-to-skin-a-cat.html. Ręka do góry kto wiedział, że SQLite zachowuje się w ten sposób (sortowanie przy UNION)?! Innymi słowy, znajomość kodu źródłowego w połączeniu z niewiedzą na temat działania SQLite, z dużym prawdopodobieństwem doprowadziły by do przeoczenia opisanego wektora ataku. Sat, 20 Aug 2011 16:15:15 +0200 https://archive.mroczna-zaloga.org/archives/1050-guid.html#c4240 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#c4230 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1050 nospam@example.com (Paweł Goleń) To mi się właśnie z audytem kojarzy. Jeśli w papierach jest napisane, że coś jest robione, to test zaliczamy, mimo tego, że w rzeczywistości nikt do papierów się nie stosuje, a procedura powstała w godzinę po tym, jak audytor o nią poprosił :) Obiektywność - no nie wiem, wydaje mi się, że kod raczej nie kłamie, poza tym chodzi o porównanie tego, co widzisz na podstawie testu empirycznego z tym, co widzisz w kodzie. Ewentualnie o sprawdzenie dlaczego aplikacja zachowuje się w tak podejrzany sposób. W przypadku dokumentacji poziom zaufania już oczywiście powinien być niższy, bo często rozjeżdża się ona z rzeczywistością. Ale takie sprawdzenie zgodności teorii z praktyką też jest wartością dodaną. Fri, 19 Aug 2011 08:45:30 +0200 https://archive.mroczna-zaloga.org/archives/1050-guid.html#c4230 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#c4229 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1050 nospam@example.com (Paweł Goleń) Ciekawe sprawy poruszyłeś. 1. Tak, rzeczywiście zdarzają się sytuacje, w których klient jest ograniczony umowami z dostawcą. Wówczas rzeczywiście podejście black box może być jedynym możliwym. Nawet w takim przypadku można jednak temat nieco rozjaśnić poprzez monitorowanie aplikacji (np. wychodzące zapytania do bazy SQL) czy dostarczenie dodatkowych informacji (np. listing plików/ścieżek wykorzystywanych przez aplikację). Jeśli poruszasz już ten temat, to zwrócę uwagę, że w licencjach w zasadzie standardowo jest zawarty zakaz dekompilacji kodu, a przy aplikacjach mobilnych klient mimo wszystko czegoś takiego oczekuje :) W sumie trudno mu się dziwić, ktoś, kto będzie chciał go zaatakować raczej zapisami licencyjnymi przejmować się nie będzie. 2. Dlatego uważam, że ważna jest edukacja. Niestety, nie zawsze udaje się klienta przekonać do zmiany podejścia. Wydaje mi się, że tu pomocne może być tutaj uzasadnienie ekonomiczne: ROI. 3. Tutaj Krzysiek już odpowiedział. Mając X dni roboczych jesteś więcej w stanie osiągnąć, gdy skupiasz się na pracy właściwej, a nie na walce z pierdołami, mało twórczej, ale czasochłonnej. Możliwość sprawdzenia czegoś w kodzie != analiza kodu źródłowego. Może to wyglądać w ten sposób, że znajdowana jest osoba za kod odpowiedzialna i odpowiada ona na pytania odnośnie tego, jak dana rzecz jest realizowana. Oczywiście nie zawsze jest to możliwe, sprawdza się to, jeśli system jest tworzony we własnym zakresie, lub jest współpraca ze strony dostawcy. Analiza kodu we własnym zakresie jest rzeczywiście bardzo pracochłonna. Ogarnięcie całości aplikacji tworzonej przez N lat przez zespół kilkunastu/kilkudziesięciu programistów to spore wyzwanie. Z doświadczenia wiem, że nawet programiści, którzy przy tej aplikacji pracują, często nie wiedzą co dzieje się w jakimś module napisanym kilka lat temu przez programistę, który teraz już pracuje w innej firmie. Po prostu z niego korzystają (ach, te wzorce projektowe). Inaczej sytuacja wygląda, gdy już masz pewne podejrzenie/wątpliwość (testy "empiryczne") i chcesz to zweryfikować w kodzie. Znalezienie odpowiedniego fragmentu kodu jest już bardziej "osiągalne", może to szybciej potwierdzić/obalić przypuszczenie i pozwoli testować kolejną rzecz, czyli mamy oszczędność czasu. Fri, 19 Aug 2011 08:39:53 +0200 https://archive.mroczna-zaloga.org/archives/1050-guid.html#c4229 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#c4227 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1050 nospam@example.com (BP) Może mając dostęp do źródeł/dokumentacji możesz się czymś zasugerować, a tak to może będziesz bardziej obiektywny (przy black-box). Uważaj, żeby cię filtry antyrasistowskie nie wyłączyły :) - "białe pudełko jest lepsze niż czarne" - "strzelanie w ciemno" Fri, 19 Aug 2011 07:41:54 +0200 https://archive.mroczna-zaloga.org/archives/1050-guid.html#c4227 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#c4223 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1050 nospam@example.com (sumar) Zgadzam się z tym, co napisałeś. Bez dokumentacji i kont o różnych poziomach uprawnień niewiele można sprawdzić. Pamiętam, że jeden projekt (były to testy infrastruktury DMZ) realizowany był w następujący sposób: 1. Testy blackbox zdalne (tj. za pośrednictwem Internet) + raport cząstkowy 2. Analiza dokumentacji i architektury + raport cząstkowy 3. Testy whitebox z poszczególnych DMZ + analiza konfiguracji urządzeń/serwerów i raport końcowy. Thu, 18 Aug 2011 23:38:31 +0200 https://archive.mroczna-zaloga.org/archives/1050-guid.html#c4223 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#c4222 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1050 nospam@example.com (Krzysztof Kotowicz) ad 3. To akurat można zdefiniować w umowie. White box to nie jest moim zdaniem (i chyba o to Pawłowi chodziło) pełne code review, tylko test z dostępem do źródeł, mający na celu znaczące zwiększenie skuteczności testu, trwającego przecież zawsze X założonych dni. Thu, 18 Aug 2011 23:21:32 +0200 https://archive.mroczna-zaloga.org/archives/1050-guid.html#c4222 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#c4221 https://archive.mroczna-zaloga.org/archives/1050-skonczmy-z-fetyszem-czarnego-pudelka.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1050 nospam@example.com (pk) Mam 3 przemyślenia w temacie white'ów: 1. Często klienci reagują alergicznie na propozycję white'a nie ze względu na swoje widzimisię, ale ze względu na nałożone na nich ograniczenia prawne, wynikające z tego, że kiedyś ktoś dał ciała i kiepsko wynegocjował warunki umowy z podwykonawcą webaplikacji. Na mocy umowy kod źródłowy jest objęty bardzo restrykcyjną licencją i zlecający test nie moga go dobrowolnie udostępnić osobom trzecim, w tym pentesterowi (i tu też pojawia się WTF, bo jednak liczą się z tym, że jeśli pentester znajdzie podatność, to w niektórych przypadkach uzyska również "nieautoryzowany" dostęp do kodu źródłowego) 2. Klienci z reguły nie wiedzą tego, co napisałeś powyżej. Oni chcą sprawdzić, czy da się ich "zhackować" (cokolwiek to znaczy), a wg nich uosobieniem złego hackera jest ktoś, kto nic o aplikacji nie wie i zaczyna przy niej gmerać, dlatego przez analogie klienci chcą, żebyś ty odegrał taką rolę. Nie wiem jak u Was, ale z reguły po krótkiej rozmowie klienci dają się przekonać do tego, że white/gray jest lepszym podejściem. Oraz trzecie przemyślenie. White z analizą kodu źródłowego czasem na rachunku może wyjść drożej niż black ograniczony do X dni (gdzie X definiuje klient, a raczej deadline, który ma klient). Thu, 18 Aug 2011 22:48:53 +0200 https://archive.mroczna-zaloga.org/archives/1050-guid.html#c4221