Czekam na zakończenie The new month of Burp pr0n i możliwość przetestowania (w praktyce) opisywanych zmian. W tym samym czasie chciałbym porównać jego możliwości z OWASP ZAP.
Co do zasady nie mam złudzeń, Burp jest bardziej kompletnym, dopracowanym narzędziem, ale jest kilka obszarów, w których ZAP ma ciekawe pomysły. Choćby spider/crawler, który w Burp również ma zostać znacząco ulepszony (patrz: Burp's new crawler).
Jedna rzecz się nie zmieni, Burp nie stanie się narzędziem fire and forget. To, że nie jest on w stanie zaadresować błędów logiki biznesowej jest oczywistością, wyzwaniem mogą być również skanowanie prostych technicznych usterek jeśli skaner nie jest w stanie odtworzyć prawidłowej ścieżki wywołania danej funkcji. Tu też należy spodziewać się ulepszeń (patrz: Automatically maintaining session during scans), ale nie wierzę, że rozwiązanie będzie kompletne. Niemniej jednak z chęcią sprawdzę jak Burp będzie sobie radził choćby z ochroną przez CSRF, obecne rozwiązania, Using Burp's Session Handling Rules with anti-CSRF Tokens, do najwygodniejszych nie należy.
Jest jeszcze jedna rzecz, której brakuje mi i w Burp, i w ZAP - dokładnego logowania wszystkiego co jest wysyłane do serwera w celu późniejszej analizy. Tak, są rozszerzenia (Logger++), można zapisywać logi do pliku tekstowego, ale nie są to rozwiązania wygodne. Ciągle chyba najlepszym rozwiązaniem jakie widzę, to puszczenie całego ruchu przez kolejne proxy (np. Fiddler) i zachowanie również tych logów na wypadek, gdyby w przyszłości zaszła potrzeba przeanalizowania co (nie)zostało zrobione.
Generalnie najbardziej bym się ucieszył, gdyby w stanie proxy pojawiał się każdy request/response z każdego narzędzia wraz ze wskazaniem skąd taki request pochodzi. Pozwalałoby to przeglądać takie requesty w sposób spójny.
OK, zgadzam się, powinna to być opcja konfiguracyjna, ale zdecydowanie byłaby przydatna.