Testuję sobie aplikację i co widzę? Po wpisaniu w formularz wyszukiwania znaku ' pojawia się błąd 500. No to myślę sobie - SQL Injection jak nic. Szybki test XYZ%' AND 1=1 AND 'A' LIKE ' oraz XYZ%' AND 1=0 AND 'A' LIKE ' (XYZ%' by widzieć, że zapytanie działa, fragment 'A' LIKE ' dlatego, że zostawało z początku zapytania %' z "oryginalnego" LIKE, a jakoś komentarz nie chciał działać) potwierdza hipotezę. Pozostaje więc zamiast tego 0 i 1 wstawić subselecta i jest piękny Blind SQL Injection. No i tu zaczęły się schody...
...a tak ładnie się zapowiadało, a to nieSQL injection
W zasadzie powinienem wyczuć, że coś jest nie tak już w chwili, gdy nie mogłem wykomentować pozostałej części zapytania. W końcu idąc tropem zwracanych komunikatów błędów doszedłem do tego, gdzie jest "problem". Cóż, ASP.NET znów uratowało świat przed zagładą. Po prostu to, na czym operowałem, to był DataView, a injection (bo rzeczywiście był tam injection) dotyczył DataView.RowFilter. Po prostu DataView daje pewną dodatkową warstwę abstrakcji nad źródłem danych (w tym przypadku nad bazą danych). I rzeczywiście, w tej warstwie nie operuje się bezpośrednio na danych przy pomocy języka SQL, tylko na ich "widoku" przy pomocy czegoś podobnego do SQL (i tu). Jak widać można w tym również zrobić interpreter injection (ciekawe jak to nazwać, rowfilter injection?), ale skutki takiego błędu w tym przypadku są zdecydowanie mniejsze, niż w przypadku bezpośredniego operowania na danych za pomocą SQL (czytaj - możliwości wykonania dowolnego zapytania w bazie).
Ale nic to, w trakcie etapu radosnego bughuntingu (o testach penetracyjnych) zauważyłem kilka miejsc, w których bezpośrednio pojawia się wyjątek z Oracle. Dla przypomnienia - ów radosny bughunting to etap zapoznawania się z aplikacją i prób jej "intuicyjnego" psucia. Teraz tylko muszę do nich dotrzeć w tym metodycznym etapie testów.
