4. Błędy typu injection
Zmuś aplikację, żeby
wykonywała Twój kod
dzięki sprytnemu
manipulowaniu danymi
wejściowymi
OWASP 4
5. SQL injection w aplikacjach webowych
Kod to polecenia SQL
Dane wejściowe to wszystko, co trafia
do bazy:
Parametry z URL
Dane formularzy
Nagłówki HTTP
Cookies (np. ID sesji)
Logi
...
OWASP 5
6. Czym to grozi?
Nieuprawniony dostęp do aplikacji
Dostęp do całej zawartości bazy /
baz na serwerze
Denial of service
Możliwość modyfikacji danych w
bazie
Przejęcie serwera baz danych
OWASP 6
8. Dawno, dawno temu...
Wyglądało to tak:
String query = ”SELECT * FROM accounts WHERE
custID = ” + request.getParameter(”id”)
http://example.com/accountView?id=1 or 1=1
SELECT * FROM accounts WHERE custID = 1 or 1=1
Prosty cel dla atakujących
Łatwo wykryć, łatwo się zabezpieczyć
OWASP 8
10. A teraz...
Zaawansowane techniki ataku
Blind SQLi, 2nd order SQLi,
zaciemniany SQLi,...
Narzędzia ułatwiające włamania
Automatyzacja
Nowe luki odkrywane codziennie
OWASP 10
11. Przykłady z życia
Maj 2010 - Transport publiczny w Holandii –
wyciek danych 168 000 klientów
2009/2010 – TinKode włamuje się na strony
NASA, IBM, US Army, Kaspersky, Yahoo,
Apple
2009 – wyciek 32 mln loginów i haseł z
RockYou.com
W efekcie…
OWASP 11
12. Wygrywamy!
Błędy injection na pierwszym
miejscu OWASP Top 10 2010
[owasp.org]
Drugie miejsce w CWE/Sans Top
25 Most Dangerous Programming
Errors 2010 [cwe.mitre.org]
40–60% przypadków wycieku
danych i 19% przypadków
naruszenia bezpieczeństwa
[7safe.com] [blogs.zdnet.com]
[computerworld.com]
OWASP 12
14. Jak tego nie robić, czyli blacklisting…
fragm. FAQ banku Sacramento Credit Union
Takie „zabezpieczenie” nic nie da!
Obejście:
DR/**/OP
I wiele innych...
OWASP 14
15. Jak się bronić przed SQL injection?
Skąd ten błąd? Łączysz kod z danymi
SELECT * FROM users WHERE login = 'login'
Metody obrony
Oddziel kod od danych
prepared statements
procedury składowane
Escape’uj dane
Stosuj metody uzupełniające
OWASP 15
18. Prepared statements - podsumowanie
Oferują całkowite zabezpieczenie
Wystarczą niewielkie zmiany w kodzie
Mają dobre wsparcie we wszystkich
środowiskach
ALE
Nie wszystkie typy poleceń można
parametryzować
Nie w każdym miejscu polecenia można
wstawić parametr
OWASP 18
20. Escape'owanie – zasada działania
Dane i polecenia wciąż trzymaj w jednej
zmiennej
Zabezpiecz dane przed „przecieknięciem” do
kodu
Liczby rzutuj na (int) / (float)
Teksty otocz apostrofami, apostrof wewnątrz
tekstu poprzedź odpowiednim znakiem
specjalnym, np. ""
OWASP 20
21. Escape’owanie – przykład
// escape'uj dane
$n = $pdo->quote($_GET['n'], PDO::PARAM_STR);
$v = $pdo->quote($_GET['v'], PDO::PARAM_STR);
// wstaw je do tresci zapytania
$pdo->exec("INSERT INTO registry
(name, value)
VALUES ($n, $v)");
OWASP 21
22. Problem z escape’owaniem
Escape’owanie zależy od kontekstu!
Używany RDBMS
Konfiguracja bazy
Zestaw znaków
Typ danych
Nie ma uniwersalnego sposobu!
OWASP 22
23. Escape'owanie danych - podsumowanie
Jest proste, ale musisz znać kontekst
Łatwiej zapomnieć o pojedynczej zmiennej
Jeśli ją pominiesz – aplikacja wciąż działa!
Skłania do stosowania niebezpiecznych konstrukcji
sklejanie poleceń
ignorowanie zmiennych numerycznych
Stosuj tylko, jeśli
Programujesz pod konkretną bazę
Nie ma innej możliwości
OWASP 23
25. Procedury składowane
Polecenie SQL (lub seria poleceń) przenieś na
serwer i zapisz jako procedurę
Po stronie klienta wywołaj ją z określonymi
parametrami
Dane są formalnie oddzielone od kodu
To NIE wystarcza
OWASP 25
26. Procedury składowane - przykład
CREATE PROCEDURE
SP_ProductSearch(Prodname IN VARCHAR2) AS
sql VARCHAR;
code VARCHAR;
BEGIN
sql := 'SELECT ProductID, ProductName,
Category, Price WHERE' +
' ProductName=''' || Prodname ||
'''';
EXECUTE IMMEDIATE sql INTO code;
END;
OWASP 26
27. Procedury składowane – problem
Dynamic SQL
Dane znów „przemieszane” z kodem w
jednej zmiennej
Jak się obronić?
Oddziel kod od danych
Escape'uj
Nie stosuj Dynamic SQL
OWASP 27
28. Procedury składowane - podsumowanie
Czasochłonne przenoszenie logiki SQL z
aplikacji na serwer
Nie są łatwo przenośne pomiędzy RDBMS
Źle zaimplementowane mogą zwiększyć
podatność
Zarówno wywołanie procedury, jak i jej
kod jest podatny
Procedura może mieć większe
uprawnienia niż kod ją wywołujący
OWASP 28
30. Walidacja i filtrowanie danych
Kontrola poprawności danych zewnętrznych
Odbywa się przed przetwarzaniem tych danych
Nie myl z escape'owaniem!
Filter INPUT - escape OUTPUT
Osobne reguły walidacji dla każdego
parametru - sprawdzaj m.in.
Typ zmiennej
Skalar / tablica
Wartości min / max
Długość danych tekstowych! [1]
OWASP 30
31. Uzupełniające metody obrony
Komplementarne do poprzednich!
Zasada najmniejszych uprawnień
Regularne aktualizacje
Dobra konfiguracja środowiska (np. w PHP)
magic_quotes_* = false
display_errors = false
Dobrze zaprojektowana baza danych
Web Application Firewall / Intrusion Detection
System / Intrusion Prevention System
OWASP 31
32. Podsumowanie
SQL injection to jeden z największych błędów
bezpieczeństwa
Pojedyncza luka może spowodować duże szkody
Łatwo się przed nim zabezpieczyć:
Stosuj prepared statements wszędzie, gdzie
możesz
W pozostałych wypadkach - escape'uj
Uważaj na Dynamic SQL w procedurach
składowanych
Filtruj dane przychodzące
OWASP 32
33. Open Web Application Security Project
Ogólnoświatowa, otwarta społeczność skupiona na
podnoszeniu poziomu bezpieczeństwa aplikacji
130 lokalnych oddziałów (polski od maja 2007 r.)
Można zupełnie za darmo dołączyć
Organizujemy cykliczne spotkania
Tworzymy narzędzia (wykrywanie zagrożeń, edukacja,
bezpieczne tworzenie aplikacji)
Wydajemy dokumenty dot. bezpieczeństwa aplikacji
www.owasp.org
www.owasp.org/index.php/Poland
OWASP 33