O tym jak bardzo należy uważać i dlaczego przed ostatecznym wypuszczeniem produktu do klienta trzeba wszystko sprawdzić 10 razy, przekonał się niecały miesiąc temu brytyjski oddział Microsoft.
Ich strona nie dość, że wyświetlała bardzo szczegółowe błędy serwera, łącznie z błędną składnią SQL, to w dodatku nie miała żadnej filtracji na parametrach przekazywanych w URL.
Na efekt nie trzeba było długo czekać. Haker o pseudonimie “rEmOtEr” zamienił stronę eventów brytyjskiego Microsoftu na taką, jaką uważał za stosowną. Prawdopodobnie nowa strona nie przypadła do gustu właścicielom serwisu, bo nie wisiała długo.
Szczegółowa lektura dostępna jest pod tym adresem.
Błędy, błędy i jeszcze raz błędy zaniechania, niedoszacowania i niedocenienia użytkowników Internetu powodują takie a nie inne efekty. SQL injection jest jedną z najpopularniejszych metod podmian stron (tzw. deface) i kradzieży danych. Jeśli w swoim procesie analizy zagrożeń serwisu www, który właśnie produkujesz, nie masz badania podatności na SQL injection, odwlecz premierę o tydzień albo dwa i przejrzyj dokładnie kod. Jeśli nie masz w ogóle podobnej analizy, zastanów się jeszcze raz nad sensem istnienia czegoś, co zostanie szybko zniszczone.
W procesie testowania serwisu ITCore.pl przypadło mi napisać scenariusz testowania dla wyszukiwarki jaka będzie zainstalowana na serwisie. Dość duży nacisk położyłem na wykorzystanie różnych potencjalnie niebezpiecznych z punktu widzenia serwisu akcji użytkownika, które mogłyby spowodować ciąg zdarzeń podobnych do tych, jakich doświadczył Microsoft UK.
Przykładowy scenariusz zakłada sprawdzenie wyników wyświetlania takiego zapytania:
‘ UNION SELECT name, type, id FROM sysobjects;–
Testy mam nadzieję zaczną się niedługo, będę miał okazję przekonać się samemu.
Mała niespodzianka: osoba, która jako pierwsza napisze w komentarzu do tego posta, jakiego wyniku nie chcielibyśmy zobaczyć po wykonaniu powyższego wyszukiwania na serwisie ITCore.pl oraz poda prosty kawałek kodu (VB, C#, SQL) pozwalający ustrzec się przed podobnymi sztuczkami użytkowników otrzyma ode mnie w prezencie nieużywaną, nieodpakowaną, świeżą i pachnącą grę na XBOX 360 pt. Forza Motorsport 2. Chętni?
Oczywiście liczą się tylko poprawne odpowiedzi.
Disclaimer: Konkurs organizowany jest przeze mnie, prywatną osobę i nie ma związku z Microsoft Polska sp. z o.o., Microsoft Ireland, Microsoft UK, XBOX czy serwisem ITCore.pl.
Z SQL injection spotkałem się nie raz w swojej pracy i zwykle wynikało ono z:
1. Braku walidacji danych wejściowych,
2. Braku kodowania znaków o specjalnym znaczeniu dla SQL (w tym przypadku znaku ‘ )
3. Dynamicznym tworzeniem zapytań SQL
W związku z tym Twoje pytanie wydaje mi się nieco tendencyjne. Prosty kawałek skryptu może na przykład zamieniać ‘ na ”, ale nie tędy droga (moim zdaniem). Zamiast tego, należy (trochę utopia):
1. Dla każdego parametru określić typ, zakres i format danych akceptowanych,
2. Stworzyć stosowne walidatory (a tu ASP.NET jest na prawdę dobrze przygotowane),
3. Kodować dane przed przekazaniem do interpretatora (w tym przypadku do SQL),
4. Nie używać dynamicznego SQL, lecz zamiast tego korzystać ze “stored procedures” i “bind variables”,
…mniej więcej tyle
A, nie biorę udziału w konkursie 
@wampir: moje pytanie tendencyjne? No co Ty
Disclaimer mi się najbardziej podoba ;D Ty z racji pracy w MS musisz tak za każdym razem pisac?
No wiesz, widziałem ludzi, którzy “zabezpieczali się” przed XSS wycinając słówko “script”. Ale, choćby, przez onmouseover już śliczne XSS dało się zrobić. Aplikacje, które ochronę przed XSS na validateRequest (ASP.NET) opierały, też już “odwiedzałem”. Dlatego jakoś nie wierzę w “proste kawałki kodu”
Proste kawalki kodu sa tutaj:
http://msdn2.microsoft.com/en-us/library/ms161953.aspx
http://msdn2.microsoft.com/en-us/library/ms998271.aspx
Co do samego sprawdzenia znakow i kodowania to jest mala biblioteka do uzycia w ASP .NET z Microsoft, ale dosyc prosta wiec raczej polecalbym stworzenie wlasnego rozwiazania.
@Wampir
Ja widzialem takich ktorzy wycinali w lancuchu wejsciowym slowo SELECT.
@Crash: to latwiej niz pozniejsze tlumaczenia
Uzywajac .NETa wystaczy uzywac paramtryzowanych zapytan. Proste jak budowa cepa, no ale przeciez zawsze mozna uzywac “Select” cos tam. Tym sie rozni zabawa od profesjonalizmu.
Jej, niby wszyscy trąbią o SQL Injection a jednak cały czas jest ktoś kto o tym nie słyszał. Drugą rzeczą która mnie dziwi to ilu ludzi z it siada do rozwiązywania problemów, bez znajomości narzędzi których używają.
@Michal S. : To raczej nie chodzi o narzedzia, a o wiedze. Narzedzia cie nie uchronia, jak jestes buc
@Pawel P.: Wszystko jest ze sobą powiazane, jak znasz narzędzie to wiesz do czego służą poszczególne składniki i gdzie je zastosować aby ustrzec się problemów.
Ale jasne nawet najlepsze narzędzie nie uchroni nikogo przed błędami jeśli niebardzo wie co robi.