“Jak ocalić swoje dane przed SQL injection?” - Krzysztof Kotowicz na KrakSpot Tech #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

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

Co to jest SQL injection? OWASP 3

Błędy typu injection Zmuś aplikację, żeby wykonywała Twój kod dzięki sprytnemu manipulowaniu danymi wejściowymi OWASP 4

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

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

Jak oni to robią? OWASP 7

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

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

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

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

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

Jak się bronić? OWASP 13

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

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

Jak się bronić? Prepared statements OWASP 16

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“Jak ocalić swoje dane przed SQL injection?” - Krzysztof Kotowicz na KrakSpot Tech #1

by krakspot on Jun 09, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 214

Statistics

“Jak ocalić swoje dane przed SQL injection?” - Krzysztof Kotowicz na KrakSpot Tech #1 — Presentation Transcript

http://krakspot.pl	211
http://www.slideshare.net	3