https://archive.mroczna-zaloga.org/ Paweł Goleń, blog - Zrzędzenie starego zgreda pl Serendipity - http://www.s9y.org/ Sat, 15 Mar 2025 22:14:29 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/1290-czy-aby-na-pewno-jestes-w-stanie-to-wykorzystac.html#c30374 https://archive.mroczna-zaloga.org/archives/1290-czy-aby-na-pewno-jestes-w-stanie-to-wykorzystac.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1290 nospam@example.com (skomak) Oczywiście można o takich rzeczach dywagować długo, jak bardzo obniżyć rating błędu, czy w ogóle go zgłaszać jako błąd, a może zgłaszać tylko jako słabość, skoro nie mamy pełnego scenariusza. Z praktyki wiemy jednak, że jeśli brakujący element do pełnego scenariusza ataku się pojawi to mamy poważny problem, pamiętajmy, że uzupełnienie scenariusza zazwyczaj powstaje bez naszej wiedzy przy aktualizacjach kodu. Z praktyki też wiemy, że jeśli obniżymy za bardzo rating błędu albo oznaczymy go jedynie jako słabość czy w ogóle go nie zgłosimy bo przykładowo polityka firmy bo trzymamy się tylko ekploitowalnych błędów to w pewnym momencie zdamy sobie sprawę, że dbamy bardziej o "zgodność" względem firmowych standardów niż o bezpieczeństwo samej aplikacji i danych, albo jeszcze gorzej - zatracimy się w oparach rozmyślań i rozważań o tym jak zgłosić błąd i jak rozlegle go opisać, żeby ludzie nietechniczni mogli zrozumieć dlaczego to takie zawiłe i na tej podstawie ustalić, że nie będzie załatany. Pytanie czy ma to sens. Osobiście uważam, że czas poświęcony na rozwój wydarzeń w prozie opisu podatności biorąc pod uwagę łatwość załatania błędu można by poświęcić najzwyczajniej na jego załatanie. Pamiętajmy, że testy penetracyjne nie trwają wiecznie, a rozważania na krawędzi psychologii i reżimu działania firmy odwodzą od prawdziwych problemów - bezpieczeństwa. Reasumując, jestem zdania, że większość błędów bezpieczeństwa łatwych do załatania jak ustalenie flagi na ciastku czy zrobienie walidacji przeciw XSSom czy iniekcjom SQL to tak prozaiczna i zarazem wtórna rzecz, że ich rating nie powinien być zaniżany albo w ogóle albo znacznie. Wed, 21 Oct 2015 13:11:52 +0200 https://archive.mroczna-zaloga.org/archives/1290-guid.html#c30374 https://archive.mroczna-zaloga.org/archives/1290-czy-aby-na-pewno-jestes-w-stanie-to-wykorzystac.html#c30370 https://archive.mroczna-zaloga.org/archives/1290-czy-aby-na-pewno-jestes-w-stanie-to-wykorzystac.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1290 nospam@example.com (Paweł Goleń) Dokładnie. Można dodać do tego więcej ciekawostek, na przykład znalezisko odnośnie niebezpiecznych metod PUT i DELETE w aplikacji korzystającej z RESTful. Albo inny kwiatek - XSS nie działa, bo jest content-type ustawiony na application/json, ale jeśli nasz atakujący miałby MitM (w HTTPS), to przecież mógłby to zmienić i wtedy by ten XSS był(!). Pamiętacie jak kilka lat temu jakiś dzieciak pokazywał jak zmienić oceny w dzienniku, tylko mu się wszystko psuło przy odświeżaniu strony? :) Sat, 17 Oct 2015 12:22:21 +0200 https://archive.mroczna-zaloga.org/archives/1290-guid.html#c30370 https://archive.mroczna-zaloga.org/archives/1290-czy-aby-na-pewno-jestes-w-stanie-to-wykorzystac.html#c30369 https://archive.mroczna-zaloga.org/archives/1290-czy-aby-na-pewno-jestes-w-stanie-to-wykorzystac.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1290 nospam@example.com (kravietz) Błąd jak najbardziej ale poza samym zgłoszeniem ważne jest także to jak się go zgłasza. To o czym pisze Paweł to klasyczna w całej branży pentestowej choroba polegająca na nagminnym zawyżaniu wagi znalezisk wskutek niedostatecznego zbadania kontekstu całej aplikacji. Rok temu na Reddicie pewną dyskusję na ten temat wywołał mój artykuł pt Writing meaningful and professional penetration testing reports (z ipsec.pl) i tradycyjnie komentarze podzieliły się na dwie grupy: jedni uważali, że każda brakująca flaga httpOnly ma być raportowana z severity=STRASZLIWY, inni wykazywali się nieco większym pragmatyzmem. Co jest o tyle uzasadnione, że np. raportowanie "application allows simultaneous logins" w aplikacji, w której jest to absolutnie pożądane z biznesowego punktu widzenia ale pentester się nie spytał "na owaspie było napisane że to zło" jest zwyczajnie nieprofesjonalne. Stąd zresztą, nawiasem mówiąc, ziny takie jak PoC||GTFO. Ja też tak czasem odpowiadam na różne fantastyczne zgłoszenia :) Fri, 16 Oct 2015 15:24:14 +0200 https://archive.mroczna-zaloga.org/archives/1290-guid.html#c30369 https://archive.mroczna-zaloga.org/archives/1290-czy-aby-na-pewno-jestes-w-stanie-to-wykorzystac.html#c30368 https://archive.mroczna-zaloga.org/archives/1290-czy-aby-na-pewno-jestes-w-stanie-to-wykorzystac.html#comments https://archive.mroczna-zaloga.org/wfwcomment.php?cid=1290 nospam@example.com (r) Hm, to ja pójdę dalej i czy błąd (np. XSS), którego nie da się w danej chwili wyexploitować to dalej błąd bezpieczeństwa? :-) Fri, 16 Oct 2015 08:57:19 +0200 https://archive.mroczna-zaloga.org/archives/1290-guid.html#c30368