Krótkie odniesienie do artykułu "Wprowadzenie do narzędzia Burp Suite" z Sekurak/Offline #1. W artykule znajduje się takie stwierdzenie:
Fiddler, działający
głównie na systemie Windows, jest „web proxy debuggerem” i w tej roli radzi sobie świetnie. Niestety trudno postawić go obok Burpa z tego względu, że Fiddler udostępnia funkcje skupione wyłącznie wokół debugowania ruchu HTTP i domyślnie nie ma zbyt dużo funkcji, które interesowałyby inżyniera bezpieczeństwa. Można by rzec, że gdy Burp stworzony jest dla pentesterów, to Fiddler dla programistów web aplikacji, którzy chcą mieć kontrolę nad zapytaniami HTTP. Jeżeli Fiddler jako proxy wyda nam się wygodniejszy, to zawsze można używać go w połączeniu z Burpem i w jednym programie analizować żądania, a w drugim atakować testowaną aplikację.
Tak, to prawda. Ale to wcale nie jest wada Fiddlera.
Jak już wspominałem, mam teraz okazję prowadzić rozmowy rekrutacyjne i bardzo często widzę, że człowiek, z którym rozmawiam, zna konkretne narzędzie i potrafi się nim posługiwać, ale nie rozumie co się dzieje pod spodem. Ja rozumiem, że sqlmap jest doskonałym narzędziem do exploitowania (a czasami nawet do wyszukiwania) SQLi, ale jednak oczekiwałbym, że kandydat jest w stanie opowiedzieć jak wykorzystać UNION SELECT do odczytania danych z innej tabeli w bazie. Oczekiwałbym również, że jest w stanie wymyślić bardziej użyteczny "warunek na blind" niż ten nieśmiertelny (i powolny) time based. Przykłady można mnożyć...
Moim zdaniem Burp (a także inne narzędzia, choćby ZAP Proxy czy IronWASP) są dobrymi narzędziami, ale nie zastąpią myślenia. Użycie Fiddlera do tego myślenia poniekąd zmusza, właśnie dzięki braku wbudowanych funkcji typu "fire and forget". Z tego powodu dobre jest podejście hybrydowe (dlatego podkreśliłem część cytatu). Często robiłem coś takiego:
- Manualne przejście przez funkcjonalność aplikacji (Fiddler + Burp);
- Spidering (Burp);
- Równolegle:
- Automatyczny skan całości aplikacji z użyciem Burpa (i ewentualnie innych narzędzi);
- Rozpisanie aplikacji i identyfikacja interesujących scenariuszy ataku (mózg, FreeMind, prawa i lewa ręka).
- Testy "manualne" poszczególnych scenariuszy (z użyciem narzędzi, czasami skryptów tworzonych pod konkretne zadanie);
- Przegląd znalezisk i "retrospekcja".
Ten ostatni krok daje czasami interesujące rezultaty. Być może w jednym miejscu uda się zidentyfikować podatność, która występuje również w innych miejscach aplikacji, ale nie jest tak oczywista (z różnych względów). Można wówczas wrócić do innych "podobnych" miejsc i sprawdzić jeszcze raz czy aby na pewno nie są one również podatne (często są).
W skrócie - pentester powinien wiedzieć czego szuka. Narzędzia, których używa są sprawą wtórną. Mają istotny wpływ na efektywność (wydajność), ale nie zastąpią myślenia.
Temat do przemyśleń - w jakim stopniu narzędzia wbudowane w Burpa usprawniają identyfikację błędów w logice biznesowej aplikacji?
Mimo to, że przy paru zmianach w jednym i drugim zrobimy to samo, to jednak Burp, ZAP czy nowy IronWASP to troszkę inne narzędzia niż Fiddler.
Tekst jest jednak dla początkujących. Świat nie jest czarno-biały, ale dla kogoś, kto wchodzi dopiero w temat nie warto zasypywać wątpliwościami, bo się go tylko zniechęci.
Oczywiście, że trzeba myśleć przy testach. Chwała Bogu, bo w przeciwnym razie zostalibyśmy zastąpieni przez automaty