Co to jest SQL injection i jak wyglądają współczesne ataki na serwisy? Dlaczego SQL injection jest takie groźne? Jak w praktyce obronić się przed tą luką w bezpieczeństwie i ocalić swoje dane?

1. Jak ocalić swoje dane przed
SQL injection?
Krzysztof Kotowicz
Web developer
http://web.eskot.pl
OWASP Medycyna Praktyczna
krzysztof@kotowicz.net
czerwiec 2010
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org

2. Plan
Co to jest SQL injection?
Jak przebiegają ataki?
Jak możemy się bronić?
OWASP 2

3. Co to jest SQL injection?
OWASP 3

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

7. Jak oni to robią?
OWASP 7

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

9. A teraz…
http://www.site.com/auktion/auktion.php?id_auk=
1+and+1=1+and+ascii(substring((SELECT
password FROM fh_user+WHERE+iduser=1 LIMIT
0,1),1,1))>1
http://127.0.0.1/[path]/?do=featured&action=sho
wmaincatlanding&maincatid=-99999/**/union/**/
all/**/select/**/group_concat(admin_name,char(5
8),admin_password)v3n0m/**/from/**/admin_tab
le--
OWASP 9

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

13. Jak się bronić?
OWASP 13

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

16. Jak się bronić?
Prepared statements
OWASP 16

17. Prepared statements – przykład
// przygotuj zapytanie
$stmt = $pdo->prepare(
"INSERT INTO registry (name, value)
VALUES (:n, :v)");
$stmt->bindValue(':n', $_GET['n']);
$stmt->bindValue(':v', $_GET['v']);
// wykonaj zapytanie
$stmt->execute();
OWASP 17

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

19. Jak się bronić?
Escape'owanie danych
OWASP 19

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

24. Jak się bronić?
Procedury składowane
OWASP 24

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

29. Jak się bronić?
Metody uzupełniające
OWASP 29

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

34. Linki
 O SQL injection
 www.owasp.org/index.php/SQL_Injection
 unixwiz.net/techtips/sql-injection.html
 delicious.com/koto/sql+injection
 slideshare.net/kkotowicz/owasp-sql-injection
 Hack me
 threats.pl/bezpieczenstwo-aplikacji-internetowych
 tinyurl.com/webgoat
 mavensecurity.com/dojo.php
 Bezpieczeństwo
 owasp.org
 niebezpiecznik.pl
 krzysztof@kotowicz.net http://blog.kotowicz.net
OWASP 34