Tłumaczenie: Ludwika Sobczak, Sosnowiec
W kwietniu Bojan Zdrnja opublikował post z dosyć szczegółową analizą jednego z takich narzędzi na blogu SANS Handler's Diary. Następnie w maju SecureWorks przyznało, że wykryto narzędzie typu „SQL injection” wykorzystujące luki w oprogramowaniu, które miało pogłębione działanie. Narzędzie to zostało wykryte, gdy wkradało się do dużego botneta i oczywiście umożliwiało wszystkim botom uruchomienie ataków typu „SQL injection”. Więcej na ten temat: www.secureworks.com/research/threats/danmecasprox.
Prawdopodobnie bezpiecznym stwierdzeniem będzie powiedzenie, że prawie wszystkie z zakończonych sukcesem ataków były bezpośrednio spowodowane słabym kodowaniem aplikacji sieciowych, jak również brakiem adekwatnej, bezawaryjnej ochrony bezpieczeństwa. Błędy we właściwym zabezpieczeniu danych wprowadzanych przez użytkownika muszą doprowadzić do naruszenia ochrony. Jednak wykorzystanie silnego wewnętrznego systemu zabezpieczeń aplikacji sieciowej może pomóc w zatrzymaniu złośliwego kodu, który toruje sobie drogę w jakimkolwiek kodzie zabezpieczającym, wbudowanym w aplikacje sieciowe.
Aby pomóc w odpowiednim kodowaniu, Microsoft zaoferował kilka porad. Firma wypuściła poradnik „Rise in SQL Injection Attacks Exploiting Unverified User Data Input” (www.microsoft.com/technet/security/advisory/954462.mspx), który opisuje trzy narzędzia pomocne w odnajdywaniu i naprawianiu problemów dotyczących kodowania.
Jedno z tych narzędzi – Scrawl – jest stosunkowo nowe i dostarczone przez HP. Narzędzie osnuje witrynę w poszukiwaniu wektorów ataku typu „SQL injection”. W poradniku Microsoft przypomina także administratorom o swoim długoletnim narzędziu UrlScan, które jest teraz dostępne w wersji 3.0 beta. Oba z tych narzędzi skanują widoczną część witryny. Aby wejść głębiej, można sprawdzić rzeczywisty kod źródłowy pod kątem luk w zabezpieczeniach za pomocą narzędzia Microsoftu „Source Code Analyzer for SQL Injection”. Jednak trzeba być świadomym faktu, że narzędzie to może sprawdzić tylko kod ASP napisany przy użyciu VBScript i nie analizuje ono wszystkich typów konstrukcji ASP. Innymi słowy, narzędzie to ma swoje ograniczenia.
Inne narzędzia skanujące, które warto rozważyć do użycia dla ochrony witryny WWW to: Acunetix Web Vulnerability Scanner, Cenzic Hailstorm, N-Stalker Web Application Security Scanner, NT OBJECTives NTOSpider, WhiteHat Sentinel, IBM Rational AppScan, HP WebInspect, Next Generation Security Software NGSSQuirreL oraz IPLocks Armour.
Zaleca się również użycie rozwiązania „Web application firewall” do ochrony swojej witryny. Dzisiaj istnieje szeroki wybór. Oto niektóre z rozwiązań, o których mi wiadomo: AppliCure dotDefender, ArmorLogic Profense, Barracuda Web Site Firewall, Breach Security WebDefend i ModSecurity, eEye Digital Security SecureIIS, F5 BIG-IP Application Security Manager, Imperva SecureSphere, Privacyware ThreatSentry, Protegrity Defiance Threat Management System, Radware AppXcel z Web Application Firewall oraz webScurity webApp.secure. Wszystkie te produkty można łatwo znaleźć, posługując się ulubioną wyszukiwarką.
Należy pamiętać, że zapory typu „Web application” powinny stanowić jedynie część ogólnej strategii zabezpieczeń – nawet z takim rozwiązaniem pod ręką, nadal trzeba dokładać wszelkich starań, aby zapewnić jak najlepsze bezpieczeństwo swoich kodów i serwerów bazy danych.
Tłumaczenie: Ludwika Sobczak, Sosnowiec
