SQL Injection – ochrona

Ochrona przed SQL Injection polega na stosowaniu zapytań parametryzowanych zamiast wklejania danych bezpośrednio do polecenia.

SQL Injection – ochrona i znaczenie podatności

SQL Injection, określane także jako wstrzyknięcie poleceń SQL, jest podatnością aplikacji, która pojawia się wtedy, gdy dane przekazane przez użytkownika zostają potraktowane jak część instrukcji kierowanej do bazy danych. Problem może dotyczyć formularza logowania, pola wyszukiwania, parametrów adresu strony, filtrów, formularzy kontaktowych, paneli administracyjnych oraz interfejsów udostępniających dane innym aplikacjom. Jeżeli aplikacja nie oddziela wartości otrzymanej od użytkownika od struktury zapytania, osoba atakująca może próbować zmienić sens wykonywanej operacji.

Skutki zależą od uprawnień używanego konta bazodanowego, rodzaju silnika bazy, sposobu obsługi błędów i zakresu zabezpieczeń aplikacji. Możliwe konsekwencje obejmują odczyt danych, zmianę rekordów, usunięcie zawartości tabel, obejście logowania, ujawnienie informacji technicznych oraz zakłócenie działania serwisu. Nie każda próba oznacza udany atak, ale sama obecność niekontrolowanego składania zapytań powinna być traktowana jako istotne ryzyko.

Ochrona nie polega na jednym filtrze tekstowym. Potrzebne jest połączenie bezpiecznego programowania, ograniczania uprawnień, kontroli danych wejściowych, poprawnej konfiguracji bazy, monitorowania zdarzeń i regularnych testów. Szczególną uwagę należy zwrócić na aplikacje, które powstały wiele lat temu albo były rozwijane przez różnych wykonawców, ponieważ w takich projektach często występują odmienne sposoby komunikacji z bazą danych.

SQL Injection – ochrona a sposób budowania zapytań

Podstawową metodą zabezpieczenia są zapytania parametryzowane, nazywane również przygotowanymi. W takim rozwiązaniu struktura polecenia jest przekazywana osobno, a wartości osobno. Sterownik bazy danych otrzymuje informację, że podany tekst jest wartością do porównania, wyszukania lub zapisania, a nie fragmentem instrukcji. Dzięki temu znaki mające szczególne znaczenie w języku SQL nie zmieniają logiki zapytania.

W praktyce należy korzystać z mechanizmów oferowanych przez używany język programowania, bibliotekę dostępu do danych albo sterownik bazy. Nie powinno się tworzyć zapytań przez łączenie stałego tekstu z parametrem pochodzącym bezpośrednio z formularza lub adresu URL. Dotyczy to również zapytań budowanych w kilku etapach, zapytań pomocniczych, sortowania, filtrowania i raportów. Parametryzacja powinna obejmować każdą wartość, która może pochodzić spoza zaufanego kodu.

Nie wszystkie elementy zapytania mogą być przekazane jako zwykły parametr. Nazwa kolumny, kierunek sortowania albo nazwa tabeli są częścią struktury polecenia. W takich przypadkach należy stosować zamkniętą listę dozwolonych wartości i mapowanie wyboru użytkownika na wcześniej zdefiniowany fragment kodu. Nie powinno się przyjmować dowolnej nazwy kolumny tylko dlatego, że pochodzi z interfejsu sortowania.

Ucieczka znaków może zmniejszyć ryzyko w określonych rozwiązaniach, lecz nie powinna być traktowana jako główna metoda ochrony. Różne silniki, tryby pracy i biblioteki mogą odmiennie interpretować znaki specjalne. Również procedury składowane nie zapewniają automatycznie bezpieczeństwa, jeżeli wewnątrz nadal powstają polecenia przez niebezpieczne składanie tekstu.

SQL Injection – ochrona na tle innych zagrożeń

Wstrzyknięcie SQL różni się od ataków wymierzonych bezpośrednio w przeglądarkę użytkownika. W przypadku Cross-Site Scripting głównym celem jest wykonanie niepożądanego kodu po stronie przeglądarki, natomiast SQL Injection dotyczy sposobu, w jaki aplikacja komunikuje się z bazą danych. Obie klasy problemów mogą jednak wystąpić w tym samym formularzu, dlatego oczyszczanie danych wyświetlanych na stronie nie zastępuje parametryzacji zapytań.

Nie należy też utożsamiać SQL Injection z próbą odgadnięcia hasła. Atak może wykorzystywać błędy w wyszukiwaniu, raportowaniu lub pobieraniu identyfikatora rekordu, nawet jeżeli logowanie zostało wykonane poprawnie. Z kolei silne hasła i dodatkowe uwierzytelnianie chronią konto, ale nie naprawiają podatnego kodu dostępu do bazy.

Istotne jest rozróżnienie między walidacją a parametryzacją. Walidacja określa, czy dane mają właściwy typ, długość, format albo zakres, na przykład czy identyfikator jest liczbą całkowitą. Parametryzacja zabezpiecza sposób przekazania wartości do bazy. Obie techniki pełnią różne funkcje i powinny być stosowane razem. Dobrze ograniczony format nie daje pełnej ochrony, jeżeli wartość nadal zostaje wklejona do tekstu zapytania.

Zapora aplikacyjna może rozpoznawać część typowych wzorców, ale nie zastępuje poprawy programu. Reguły filtrujące mogą zostać ominięte przez odmienne kodowanie, nietypowy zapis albo zmianę sposobu komunikacji z aplikacją. Najpewniejszym miejscem kontroli pozostaje kod, który przygotowuje zapytanie i przekazuje dane do sterownika.

SQL Injection – ochrona przed typowymi problemami

Jednym z częstych błędów jest zabezpieczenie tylko formularza logowania, przy jednoczesnym pominięciu wyszukiwarki, panelu raportowego lub funkcji eksportu. Każdy punkt, który przyjmuje dane i następnie wykorzystuje je w zapytaniu, powinien zostać przeanalizowany. Dotyczy to także danych zapisanych wcześniej w bazie, ponieważ złośliwa wartość może zostać wprowadzona inną drogą, a wykorzystana dopiero przy kolejnym odczycie.

Drugim problemem jest nadmiarowe konto używane przez aplikację. Jeżeli aplikacja potrzebuje jedynie odczytu określonych tabel, konto nie powinno mieć możliwości usuwania danych, zmiany struktury bazy ani dostępu do niezwiązanych obszarów. Ograniczenie uprawnień nie usuwa błędu w kodzie, ale zmniejsza możliwy zakres szkód po jego wykorzystaniu.

Warto unikać wyświetlania użytkownikowi pełnych komunikatów błędów bazy. Szczegóły mogą ujawniać nazwy tabel, kolumn, typ silnika, fragmenty zapytań lub ścieżkę wykonania programu. W środowisku używanym przez odbiorców powinien pojawiać się ogólny komunikat, natomiast szczegóły należy kierować do zabezpieczonego dziennika zdarzeń. Dzienniki powinny być chronione przed modyfikacją, a ich zawartość analizowana pod kątem powtarzających się nietypowych żądań.

Testy bezpieczeństwa powinny obejmować przypadki puste, bardzo długie, zawierające znaki specjalne, nieoczekiwany typ danych oraz wartości zmieniające strukturę zapytania. Badanie należy prowadzić na kopii danych lub w kontrolowanym środowisku, aby nie naruszyć działania używanej aplikacji. Po poprawce należy wykonać test regresyjny, ponieważ zmiana warstwy dostępu do bazy może wpłynąć na wyszukiwanie, sortowanie, paginację lub import.

SQL Injection – ochrona w codziennej praktyce

Przy ocenie aplikacji warto rozpocząć od sporządzenia listy wszystkich miejsc, w których dane z zewnątrz trafiają do zapytań. Należy uwzględnić formularze, parametry adresu, nagłówki żądań, pliki importowane, dane przesyłane przez inne systemy oraz wartości zapisane w sesji. Następnie powinno się ustalić, czy każda wartość jest przekazywana przez mechanizm parametrów, czy też zostaje połączona z tekstem zapytania.

Pomocne jest stosowanie jednej, sprawdzonej warstwy dostępu do danych oraz jednolitych zasad przeglądu kodu. W nowych funkcjach należy wymagać parametryzacji, walidacji typu, jawnej obsługi błędów i testów negatywnych. W starszych modułach dobrze jest ustalić kolejność napraw według ekspozycji funkcji, rodzaju danych i poziomu uprawnień konta używanego przez aplikację.

Bezpieczeństwo obejmuje także kopie zapasowe, aktualizacje bibliotek, ochronę danych uwierzytelniających do bazy i kontrolę dostępu do środowisk testowych. Kopia zapasowa powinna być odseparowana od aplikacji, aby błąd w aplikacji nie umożliwił jednoczesnego usunięcia danych produkcyjnych i kopii. Hasła oraz klucze dostępowe nie powinny znajdować się w publicznym kodzie ani w plikach wysyłanych do przeglądarki.

W przypadku podejrzenia podatności nie powinno się ograniczać do usunięcia pojedynczego fragmentu kodu. Należy zabezpieczyć dostęp, zachować istotne informacje z dzienników, sprawdzić zakres możliwego odczytu lub modyfikacji danych, przejrzeć podobne funkcje i zmienić ujawnione dane dostępowe. Dalsze działania powinny uwzględniać wymagania dotyczące ochrony informacji oraz dokumentowanie wykonanych poprawek.

SQL Injection – ochrona i moment zgłoszenia do serwisu

Do konsultacji warto zgłosić się wtedy, gdy aplikacja zwraca błędy bazy danych, nieoczekiwanie zmienia wyniki wyszukiwania, umożliwia dostęp do rekordów bez właściwego uprawnienia albo wykazuje nietypowe obciążenie po wysłaniu określonych formularzy. Pomocna jest również analiza w sytuacji, gdy nie ma pewności, czy używana biblioteka faktycznie korzysta z parametrów, albo gdy w starszym kodzie występują zapytania tworzone przez łączenie tekstów.

Przed przekazaniem sprawy należy przygotować opis objawu, moment jego wystąpienia, adres funkcji, rodzaj używanej technologii oraz informację, czy problem można odtworzyć na kopii testowej. Nie powinno się przesyłać prawdziwych haseł, kluczy, danych klientów ani pełnych kopii bazy. Wystarczające mogą być zanonimizowane przykłady, fragment komunikatu błędu i bezpieczny dostęp do środowiska testowego.

Warszawskie Pogotowie Komputerowe 24/7 może zostać wskazane jako miejsce pierwszej konsultacji przy ocenie komputera, aplikacji lub konfiguracji związanej z podejrzeniem problemu. Zakres prac powinien zostać ustalony przed rozpoczęciem, z rozdzieleniem diagnostyki urządzenia, analizy programu i działań dotyczących bazy danych. Najważniejsze pozostaje zachowanie kopii zapasowej, ograniczenie dostępu do wrażliwych informacji oraz usunięcie przyczyny, a nie wyłącznie ukrycie objawu.