Jak stwierdził Tomek, temat SQL Injection jest tematem dyżurnym na moim blogu. To nie do końca tak, temat ten nie zajmowałby tyle miejsca, gdyby nie był dyżurnym błędem wielu developerów, których produkty następnie przychodzi mi testować. W każdym razie dla porządku jeszcze ja wymienię te narzędzia:
Temat dyżurny: SQL Injection - narzędzia
W zasadzie miałem skończyć temat na wymienieniu tych narzędzi, ale jednak dopiszę kilka słów więcej.
Pierwsze narzędzie (Microsoft Source Code Analyzer) przeznaczone jest dla ASP, a nie dla ASP.NET. To taka drobna, ale bardzo istotna różnica. Tym bardziej istotna, że spójrzmy prawdzie w oczy - w okresie dominacji ASP kwestie związane z bezpieczeństwem były traktowane z umiarkowaną uwagą. Możliwość sprawdzenia kodu starych aplikacji w celu wykrycia w nich błędów (lub potencjalnych błędów) SQL Injection jest istotna. Jeśli chodzi o ASP.NET, to warto wspomnieć o FxCop.
URLScan jest ubogim krewnym mod_security. Mimo to pozwala na istotne zwiększenie bezpieczeństwa serwera, w szczególności, gdy uruchomione na nim aplikacje (internetowe oczywiście) są wątpliwej jakości. Ogólnie URLScan można zaliczyć do WAF. W przypadku wielu testowanych przeze mnie aplikacji wykorzystanie jakiegoś WAF skutecznie uniemożliwiłoby wykorzystanie znacznej części znalezionych podatności. Zamiast tego (choćby mod_security z podstawowym zestawem reguł) często instalowany jest system IPS, przy czym chyba działa magia pudełka, bo:
- system IPS często jest instalowany PRZED bramką SSL, co skutecznie uniemożliwia mu śledzenie aktywności użytkowników w aplikacji,
- system IPS pracuje w standardowej konfiguracji, czyli rejestruje ataki, a blokuje jedynie kilka najbardziej oczywistych (głównie sygnatury typu Nimda),
W rezultacie zamontowany w szafie (i to często w konfiguracji HA) IPS jest praktycznie bezużyteczny.
Scrawlr jest automatycznym skanerem, który ma wykrywać podatności typu SQL Injection. Akurat jestem co do tego dość sceptyczny. To znaczy on oczywiście wykryje pewne podatności, zwykle te najbardziej oczywiste, przy okazji prawdopodobnie generując całkiem sporą liczbę fałszywych alarmów. Jeśli ktoś chce, to można w sieci znaleźć przykładowe raporty z narzędzia Acunetix, w których jako krytyczne podatności SQL Injection zaznaczane były przypadki, gdy aplikacja wywracała się błędem 500 z powodu braku możliwości konwersji otrzymanej wartości (testowanej przez skaner) do Int32 (i inne podobne). Z drugiej strony automatyczne narzędzia z dużym prawdopodobieństwem nie znajdą podatności bardziej złożonych, kiedy na przykład trzeba w odpowiedni sposób ustawić kilka parametrów w formatce, zresztą nie tylko takich. Oczywiście trzeba pamiętać, że autorzy złośliwego oprogramowania wale nie są w znajdowaniu podatności lepsi niż inne skanery automatyczne, tak więc w walce przeciwko automatycznym narzędziom automatyczne skanery mogą być całkiem skuteczne.
Najbardziej cieszy mnie to, że wokół SQL Injection staje się coraz głośniej i może dzięki temu W KOŃCU niektóre firmy tworzące oprogramowanie zastosują skuteczne metody przeciwdziałające SQL Injection już na etapie produkcji.
