<?xml version="1.0" encoding="utf-8" ?>

<rss version="2.0" 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:admin="http://webns.net/mvcb/"
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
   xmlns:wfw="http://wellformedweb.org/CommentAPI/"
   xmlns:content="http://purl.org/rss/1.0/modules/content/"
   >
<channel>
    
    <title>Paweł Goleń, blog - Formularz komentarzy &quot;Pentester: doomed to fail?&quot;</title>
    <link>https://archive.mroczna-zaloga.org/</link>
    <description>Paweł Goleń, blog - Zrzędzenie starego zgreda</description>
    <dc:language>pl</dc:language>
    <generator>Serendipity  - http://www.s9y.org/</generator>
    <pubDate>Sat, 15 Mar 2025 22:15:06 GMT</pubDate>

    <image>
        <url>https://archive.mroczna-zaloga.org/templates/bulletproof/img/s9y_banner_small.png</url>
        <title>RSS: Paweł Goleń, blog - Formularz komentarzy &quot;Pentester: doomed to fail?&quot; - Paweł Goleń, blog - Zrzędzenie starego zgreda</title>
        <link>https://archive.mroczna-zaloga.org/</link>
        <width>100</width>
        <height>21</height>
    </image>

<item>
    <title>Paweł Goleń: Pentester: doomed to fail?</title>
    <link>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#c1623</link>
            <category></category>
    
    <comments>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#comments</comments>
    <wfw:comment>https://archive.mroczna-zaloga.org/wfwcomment.php?cid=725</wfw:comment>

    

    <author>nospam@example.com (Paweł Goleń)</author>
    <content:encoded>
    Chyba piszemy o dwóch trochę różnych sytuacjach. Gdy podatność została znaleziona, można określić jej &quot;praktyczność&quot;. Można też z góry wykluczyć pewne grupy podatności jako nieistotne w przypadku danej aplikacji. Przykładowo: &quot;podatność&quot; wyszukiwarki Google na CSRF. Z drugiej strony widząc, że aplikacja ma problemy z walidacją/encodingiem w pewnej chwili wyszukiwanie wszystkich przypadków XSS nie tyle przestaje mieć sens, co staje się niebezpieczne. Ale o tym więcej w kolejnych wpisach :)  
    </content:encoded>

    <pubDate>Fri, 02 Oct 2009 21:35:09 +0200</pubDate>
    <guid isPermaLink="false">https://archive.mroczna-zaloga.org/archives/725-guid.html#c1623</guid>
    
</item>
<item>
    <title>Paweł Krawczyk: Pentester: doomed to fail?</title>
    <link>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#c1622</link>
            <category></category>
    
    <comments>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#comments</comments>
    <wfw:comment>https://archive.mroczna-zaloga.org/wfwcomment.php?cid=725</wfw:comment>

    

    <author>nospam@example.com (Paweł Krawczyk)</author>
    <content:encoded>
    Wydaje mi się, że zwykle kwestia praktyczności nie nastręcza specjalnych problemów. 

Jeśli np. w czasie testu uzyskuję błąd od ODBC i jestem w stanie zbudować na bazie tego SQL injection, to raportuję to jako SQL injection. Jeśli nie - bo np. operują na prepared statements, to raportuję jako niewystarczającą walidację danych wejściowych i zbytnią gadatliwość serwera. 

Ponieważ jednak równocześnie często jestem osobą odbierającą raporty firm zewnętrznych, to mogę powiedzieć, że absolutnie nie mam do wykonawcy wyrzutów jeśli nie będzie w stanie zademonstrować PoC. Nie widzę pożytku z płacenia wykonawcy za spędzenie kilkunastu dodatkowych godzin na prowadzoną w ciemno próbę zbudowania działającego SQL injection - przecież to można w 5 minut stwierdzić biorąc developera i kod źródłowy.

Oczywiście, mogłeś mieć odmienne doświadczenia co wynika z faktu, że są różni zamawiający :) Wydaje mi się, że właśnie dla uniknięcia podobnych pretensji powstał ASVS.

Wykonawcy też są różni - w czerwcu musiałem spędzić dwa dni na dyskusjach z klientem, bo renomowana amerykańska firma pentesterska bezmyślnie skojarzyła ataki na RC4 i MD5 z ich implementacją w SSL.  
    </content:encoded>

    <pubDate>Fri, 02 Oct 2009 19:33:51 +0200</pubDate>
    <guid isPermaLink="false">https://archive.mroczna-zaloga.org/archives/725-guid.html#c1622</guid>
    
</item>
<item>
    <title>Paweł Goleń: Pentester: doomed to fail?</title>
    <link>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#c1619</link>
            <category></category>
    
    <comments>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#comments</comments>
    <wfw:comment>https://archive.mroczna-zaloga.org/wfwcomment.php?cid=725</wfw:comment>

    

    <author>nospam@example.com (Paweł Goleń)</author>
    <content:encoded>
    Całkowicie się z Tobą zgadzam. Problemem jest natomiast określenie, które z podatności są &quot;praktyczne&quot;. XSS, który jest w takim miejscu, że praktycznego zastosowania właściwie nie ma, może mieć skutek wizerunkowy. W skrajnym przypadku &quot;wina&quot; zostanie zrzucona na testujących, bo przecież testowali, a nie znaleźli. Na tym etapie nie dostrzega się, że na testy bezpieczeństwa był przeznaczony określony czas, w którym zidentyfikowana została spora liczba praktycznych (mających &quot;praktyczny&quot; wymiar/skutek) podatności.

Szczególnie niewdzięcznym tematem jest sql injection, które może wystąpić praktycznie w każdym parametrze. Jego skutki są takie same, niezależnie czy występuje w funkcji używanej przez 99% użytkowników, czy na jakiejś zapomnianej formatce, którą odwiedzi 0,01% użytkowników...  
    </content:encoded>

    <pubDate>Fri, 02 Oct 2009 13:26:53 +0200</pubDate>
    <guid isPermaLink="false">https://archive.mroczna-zaloga.org/archives/725-guid.html#c1619</guid>
    
</item>
<item>
    <title>Paweł Krawczyk: Pentester: doomed to fail?</title>
    <link>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#c1618</link>
            <category></category>
    
    <comments>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#comments</comments>
    <wfw:comment>https://archive.mroczna-zaloga.org/wfwcomment.php?cid=725</wfw:comment>

    

    <author>nospam@example.com (Paweł Krawczyk)</author>
    <content:encoded>
    &quot;warunek sukcesu testów uznamy zidentyfikowanie wszystkich podatności&quot;

Ależ testy penetracyjne nie służą do identyfikowania wszystkich podatności tylko do wskazania podatności praktycznych, oczywistych, rażących czy dostępnych w danym scenariuszu użycia.

Jeśli chcemy zlokalizować WSZYSTKIE podatności to prowadzimy analizę formalną w stylu Common Criteria, ale kosztuje to i trwa sto razy więcej niż test penetracyjny. Dlatego też nikt tego nie robi dopóki nie jest to naprawdę niezbędne ze względu na straszliwą wartość chronionego dobra :)  
    </content:encoded>

    <pubDate>Fri, 02 Oct 2009 12:55:47 +0200</pubDate>
    <guid isPermaLink="false">https://archive.mroczna-zaloga.org/archives/725-guid.html#c1618</guid>
    
</item>
<item>
    <title>Paweł Goleń: Pentester: doomed to fail?</title>
    <link>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#c1609</link>
            <category></category>
    
    <comments>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#comments</comments>
    <wfw:comment>https://archive.mroczna-zaloga.org/wfwcomment.php?cid=725</wfw:comment>

    

    <author>nospam@example.com (Paweł Goleń)</author>
    <content:encoded>
    1. Twoje prawo,
2. Chodzi o znalezienie braku/nieskuteczności &quot;security controls&quot;, które może powodować podatność,
3. Klasyczne podejście &quot;zrobić test i zapomnieć&quot;, na szczęście coraz większej ilości klientów zależy na zwiększeniu bezpieczeństwa/zmniejszeniu ryzyka niż posiadaniu dupokrytki dla audytu,
4. Patrz punkt 2. Usuwając lub prawidłowo implementując &quot;security controls&quot; masz sporą szansę na usunięcie podatności, która nie została wykryta i znacznie zmniejszasz szanse wprowadzenia takich podatności w przyszłości,  
    </content:encoded>

    <pubDate>Wed, 30 Sep 2009 17:06:17 +0200</pubDate>
    <guid isPermaLink="false">https://archive.mroczna-zaloga.org/archives/725-guid.html#c1609</guid>
    
</item>
<item>
    <title>piXi: Pentester: doomed to fail?</title>
    <link>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#c1608</link>
            <category></category>
    
    <comments>https://archive.mroczna-zaloga.org/archives/725-pentester-doomed-to-fail.html#comments</comments>
    <wfw:comment>https://archive.mroczna-zaloga.org/wfwcomment.php?cid=725</wfw:comment>

    

    <author>nospam@example.com (piXi)</author>
    <content:encoded>
    nie zgadzam sie z tym &quot;Bo to nie chodzi o to, by znaleźć podatność, tylko o to, by później ona została usunięta i nie pojawiła się ponownie przy najbliższej okazji..&quot; .. bo
1. nie po to wynajmuje pentestera zeby filozofowal
2. jak mi pentester powie ze nie znajdzie podatnosci ale upewni sie ze zostanie zalatana to raczej nie bede zainteresowany jego uslugami
3. nie jest problemem pentestera czy klient zalata podatnosc czy nie, czy ma procedury czy nie ma... pentester ma znalezc &quot;dziure w calym&quot; 
4. zdanie nielogiczne... trudno zalatac cos (nawet majac najlepsze procedury) jezeli sie tego &quot;nie odnajdzie&quot; najpierw...  
    </content:encoded>

    <pubDate>Wed, 30 Sep 2009 11:22:24 +0200</pubDate>
    <guid isPermaLink="false">https://archive.mroczna-zaloga.org/archives/725-guid.html#c1608</guid>
    
</item>

</channel>
</rss>