Ten wpis jest nieco przewrotnym komentarzem do wpisu Przemka:Testowanie logiki biznesowej. Mam dość szukania SQLi i XSSów, bo jest to umiarkowanie efektywne podejście, dodatkowo często uwsteczniające intelektualnie, monotonne i nużące. Skupiając się na tego typu podatnościach można przeoczyć inne, ciekawsze, a przede wszystkim istotniejsze. Można nawet nie mieć czasu, by zabrać się za co ciekawsze kwestie związane z logiką biznesową. W dodatku i tak istnieje spora szansa, że jakiś XSS lub SQLi pozostanie niezauważony, co pokazałem(?) choćby w przykładzie z podatnościami, które stają się oczywiste zaraz po tym, jak się je już znajdzie...
Szukania SQLi i XSSów mam już dość
Zamiast zajmować się mozolnym testowaniem formatek parametr po parametrze, chętnie zająłbym się czymś innym, na przykład wspomnianym testowaniem logiki biznesowej, czy szukaniem podatności typu DoS (co również poruszył Przemek), oczywiście nie takich, do których potrzebny jest botnet, lecz takich, o których już kiedyś pisałem, wynikających z samej aplikacji. Przy okazji odnośnie jesiennych przemyśleń (sekcja: Jak zablokować komuś dostęp do konta w banku) - tak, krótka analiza takiego scenariusza ataku DoS jest robiona w trakcie testów. Kolejną działką, którą wolałbym od tych nieszczęsnych XSSów i SQLi jest, wspominany już przez Przemka, ogólnie pojęty hardening aplikacji, wskazywanie nowych(?) rozwiązań, które można wykorzystać w aplikacji po to, by szansa wystąpienia/wykorzystania podatności była mniejsza. Na końcu jeszcze warto wspomnieć o "nowych technikach ataków", czyli szeroko pojęty research...
Są inne, bardziej efektywne sposoby wyszukiwania XSSów i SQLi niż testy penetracyjne. Mechanizm i przyczyny wystąpienia tych podatności są doskonale znane, co więcej w ogólnym przypadku mają stosunkowo łatwą do wykrycia "sygnaturę". Sygnatura ta pozwala na łatwe wykrywanie ich przez narzędzia automatyczne działające na poziomie analizy kodu źródłowego aplikacji i powinna być przeprowadzana w trakcie tworzenia aplikacji. Efekt jest zdecydowanie lepszy. Nie będę po raz kolejny rozpisywał się już o znaczeniu i efektywności innego podstawowego kroku, czyli edukacji.
Wiele razy w trakcie testów znajdowałem dziesiątki (tak, dziesiątki) podatności wynikających dokładnie z tego samego błędu (w zasadzie to była jedna i ta sama podatność w dziesiątkach kopii). Usuwanie ich nie może polegać na łataniu przypadków wskazanych palcem, tylko na zidentyfikowaniu przyczyny występowania podatności i wyeliminowaniu jej. Tak się jednak zwykle nie dzieje, niestety. Zamiast tego prezentowane jest podejście polegające na przyklejaniu łatki we wskazanym miejscu. Powoli jednak pojawiają się pozytywne sygnały wskazujące na zmianę filozofii w niektórych firmach programistycznych. Chwała tym, którzy potrafią się wybić nad przeciętność i bylejakość.
Na koniec jedno wyjaśnienie. Nie twierdzę, że testy związane z wyszukiwaniem XSSów czy SQLi nie powinny być elementem testów bezpieczeństwa. Jestem natomiast zdania, że obecnie angażują one zbyt wiele zasobów, przez co "zagładzają" inne, bardziej interesujące, również dla intruza, obszary. Obszary, w których podatność może mieć miażdżące skutki.
... a gdy takie sprawdzenie by trwalo czas moznaby poswiecic na ciekawsze i istotniejsze rzeczy o ktorych mowisz.
BTW: Dzięki Paweł za tak intensywne linkowanie
BTW#2: Jeszcze w tym roku zostanie wybudzona pewna grupa... i będzie można na nowo rozpocząć uświadamianie społeczeństwa odnośnie bezpieczeństwa (nie tylko) aplikacji.
A jak to wygląda teraz? Modyfikuje się parametr(y) i sprawdza jaki ma to wpływ na aplikację. Teoretycznie część z tych rzeczy można zrobić automatem, przynajmniej wspomagać się nim. Tylko, że można trafić na formatkę, gdzie jest 50 parametrów, z czego, przykładowo, modyfikacja 15 (rozłożonych losowo) powoduje wylogowanie z aplikacji. Skanery automatyczne wciąż nie potrafią w zadowalający sposób odtworzyć szeroko pojętego stanu aplikacji w takim przypadku. Zwłaszcza, gdy aplikacja jest "nietypowa"...
Tyle, że narzędzi otwartych do tego nie ma (=są nędzne) a komercyjne kosztują fortunę (n*10E4 dolarów rocznie).
Istnieją też narzędzia, które to samo potrafią robić na binarce (bez źródeł) - np. Veracode - ale trzeba tam dodać jeszcze jedno zero do cen.
I mają w tym wysoką skuteczność - co zresztą można zaobserwować w testach narzędzi do testowania "black box" (Acunetix) i tych samych narzędzi z sensorem (Acunetix+AcuSensor) po stronie serwera (=z dostępem do kodu PHP/ASP).
Jedna z najciekawszych prezentacji jakie ostatnio widziałem na temat algorytmicznego zaprojektowania takich testów mówi o wykorzystaniu do tego celu języka PDDL:
http://www.frhack.org/slides/FRHACK2009_Sarraute.pdf
Sporo rzeczy można wychwycić również przez "zaawansowane techniki" typu grep/regexp. Oczywiście w tym przypadku raczej nie ma co liczyć na pełne prześledzenie ścieżki od wejścia do wyjścia, jednak w połączeniu z kilkoma zasadami, do których programiści powinni się stosować (np. nie sklejamy SQL dynamicznie, wypisujemy zawsze z encodingiem itp.) pozwala to na zidentyfikowanie miejsc, którym co najmniej trzeba się przyjrzeć.
Microsoft Source Code Analyzer for SQL Injection
XSS Detect
Przy czym ten XSS Detect jakoś ostatnio mi się zapodział. Zresztą akurat te narzędzia z przyczyn dość oczywistych akurat dla mnie są umiarkowanie przydatne (brak dostępu do kodu).