Wpływ iniekcji SQL
Wstrzyknięcie SQL (SQLi) umożliwia atakującemu ingerencję w zapytania wysyłane przez aplikację do jej bazy danych [S1]. Główny wpływ obejmuje nieautoryzowany dostęp do wrażliwych danych, takich jak hasła użytkowników, dane karty kredytowej i dane osobowe. [S1].
Oprócz kradzieży danych osoby atakujące mogą często modyfikować lub usuwać rekordy bazy danych, co prowadzi do trwałych zmian w zachowaniu aplikacji lub utraty danych. [S1]. W przypadkach o dużej istotności SQLi może zostać eskalowany w celu naruszenia infrastruktury zaplecza, umożliwienia ataków typu „odmowa usługi” lub zapewnienia trwałego backdoora do systemów organizacji. [S1][S2].
Główna przyczyna: niebezpieczna obsługa danych wejściowych
Główną przyczyną wstrzyknięcia SQL jest niewłaściwa neutralizacja specjalnych elementów używanych w poleceniu SQL [S2]. Dzieje się tak, gdy aplikacja konstruuje zapytania SQL poprzez łączenie danych wejściowych wpływających z zewnątrz bezpośrednio w ciąg zapytania [S1][S2].
Ponieważ dane wejściowe nie są odpowiednio odizolowane od struktury zapytania, interpreter bazy danych może wykonać część danych wejściowych użytkownika jako kod SQL, zamiast traktować je jako dane dosłowne [S2]. Luka ta może objawiać się w różnych częściach zapytania, w tym w instrukcjach SELECT, wartościach INSERT lub instrukcjach UPDATE [S1].
Konkretne poprawki i środki łagodzące
Użyj zapytań parametrycznych
Najskuteczniejszym sposobem zapobiegania wstrzykiwaniu SQL jest użycie sparametryzowanych zapytań, znanych również jako przygotowane instrukcje [S1]. Zamiast łączyć ciągi znaków, programiści powinni używać ustrukturyzowanych mechanizmów, które wymuszają separację danych i kodu [S2].
Zasada najmniejszego przywileju
Aplikacje powinny łączyć się z bazą danych przy użyciu najniższych uprawnień wymaganych do ich zadań [S2]. Konto aplikacji internetowej nie powinno mieć uprawnień administracyjnych i powinno być ograniczone do określonych tabel lub operacji niezbędnych do jego funkcji [S2].
Walidacja danych wejściowych i kodowanie
Chociaż nie zastępuje parametryzacji, sprawdzanie poprawności danych wejściowych zapewnia dogłębną ochronę [S2]. Aplikacje powinny używać strategii akceptacji-znanego-dobrego, sprawdzając, czy dane wejściowe odpowiadają oczekiwanym typom, długościom i formatom [S2].
Jak FixVibe to testuje
FixVibe obsługuje już wstrzykiwanie SQL przez bramkowany moduł skanera active.sqli. Aktywne skanowania są uruchamiane tylko po weryfikacji i poświadczeniu własności domeny. Kontrola przeszukuje punkty końcowe GET tego samego pochodzenia za pomocą parametrów zapytania, ustala odpowiedź bazową, szuka anomalii logicznych specyficznych dla języka SQL i zgłasza wyniki dopiero po potwierdzeniu taktowania dla wielu długości opóźnienia. Skanowanie repozytorium pomaga również wcześniej wykryć przyczynę źródłową za pomocą code.web-app-risk-checklist-backfill, który oznacza surowe wywołania SQL zbudowane z interpolacją szablonów.