Udostępnij przez

Pisanie bezpiecznego dynamicznego kodu SQL w programie SQL Server

Pobieranie ADO.NET

Wstrzyknięcie kodu SQL to proces, za pomocą którego złośliwy użytkownik wprowadza instrukcje Transact-SQL zamiast prawidłowych danych wejściowych. Jeśli dane wejściowe są przekazywane bezpośrednio do serwera bez sprawdzania poprawności i jeśli aplikacja przypadkowo wykonuje wstrzyknięty kod, atak może uszkodzić lub zniszczyć dane.

Każda procedura konstruująca instrukcje SQL powinna być sprawdzona pod kątem luk w zabezpieczeniach przed atakami typu SQL Injection, ponieważ SQL Server wykona wszystkie zapytania, które są składniowo poprawne. Nawet sparametryzowane dane mogą być manipulowane przez wykwalifikowanych i określonych atakujących. Jeśli używasz dynamicznego języka SQL, pamiętaj, aby sparametryzować polecenia i nigdy nie dołączać wartości parametrów bezpośrednio do ciągu zapytania.

Anatomia ataku polegający na wstrzyknięciu kodu SQL

Proces iniekcji działa przez przedwczesne zakończenie ciągu tekstowego i dołączenie nowego polecenia. Ponieważ wstawione polecenie może zawierać dodatkowe ciągi dołączone do niego przed jego wykonaniem, malefactor kończy wprowadzony ciąg znakiem komentarza "--". Następujący tekst zostaje ignorowany w czasie wykonywania. Wiele poleceń można wstawić, używając średnika (;).

Tak długo, jak wstrzykiwany kod SQL jest poprawny składniowo, nie można wykryć manipulacji programowo. W związku z tym należy zweryfikować wszystkie dane wejściowe użytkownika i dokładnie przejrzeć kod, który wykonuje skonstruowane polecenia SQL na używanym serwerze. Nigdy nie należy łączyć danych wejściowych użytkownika, które nie są weryfikowane. Łączenie ciągów jest podstawowym punktem wejścia do iniekcji skryptu.

Oto kilka przydatnych wskazówek:

  • Nigdy nie twórz instrukcji Transact-SQL bezpośrednio z danych wejściowych użytkownika; użyj procedur składowanych, aby zweryfikować dane wejściowe użytkownika.

  • Zweryfikuj dane wejściowe użytkownika według typu testowania, długości, formatu i zakresu. Możesz użyć funkcji Transact-SQL QUOTENAME() do eskapowania nazw systemowych lub funkcji REPLACE() do eskapowania dowolnego znaku w ciągu.

  • Zaimplementuj wiele warstw weryfikacji w każdej warstwie aplikacji.

  • Przetestuj rozmiar i typ danych danych wejściowych i wymuś odpowiednie limity. Może to pomóc w zapobieganiu celowym przepełnieniu buforu.

  • Przetestuj zawartość zmiennych ciągu i zaakceptuj tylko oczekiwane wartości. Odrzuć wpisy zawierające dane binarne, sekwencje ucieczki i znaki komentarza.

  • Podczas pracy z dokumentami XML zweryfikuj wszystkie dane względem jego schematu podczas ich wprowadzania.

  • W środowiskach wielowarstwowych wszystkie dane powinny być weryfikowane przed wejściem do zaufanej strefy.

  • Nie akceptuj następujących ciągów w polach, z których można tworzyć nazwy plików: AUX, CLOCK$, COM1 do COM8, CON, CONFIG$, LPT1 do LPT8, NUL i PRN.

  • Użyj SqlParameter obiektów z procedurami składowanymi i poleceniami, aby zapewnić sprawdzanie typów i sprawdzanie długości.

  • Użyj Regex wyrażeń w kodzie klienta, aby filtrować nieprawidłowe znaki.

Dynamiczne strategie SQL

Wykonywanie dynamicznie utworzonych instrukcji SQL w kodzie proceduralnym powoduje przerwanie łańcucha własności, co powoduje, że program SQL Server sprawdza uprawnienia obiektu wywołującego względem obiektów, do których uzyskuje dostęp dynamiczny program SQL.

Program SQL Server ma metody udzielania użytkownikom dostępu do danych przy użyciu procedur składowanych i funkcji zdefiniowanych przez użytkownika, które wykonują dynamiczny program SQL.

  • Używanie impersonacji w klauzuli Transact-SQL EXECUTE AS.

  • Podpisywanie procedur składowanych przy użyciu certyfikatów.

WYKONAJ JAKO

Klauzula EXECUTE AS zastępuje uprawnienia dzwoniącego uprawnieniami użytkownika określonego w klauzuli EXECUTE AS. Zagnieżdżone procedury składowane lub wyzwalacze są wykonywane w kontekście zabezpieczeń użytkownika proxy. Może to uszkodzić aplikacje, które opierają się na zabezpieczeniach na poziomie wiersza lub wymagają inspekcji. Niektóre funkcje zwracające tożsamość użytkownika zwracają użytkownika określonego w klauzuli EXECUTE AS, a nie oryginalnego obiektu wywołującego. Kontekst wykonywania jest przywracany do oryginalnego wywołującego dopiero po wykonaniu procedury lub przy użyciu instrukcji REVERT.

Podpisywanie certyfikatu

Po wykonaniu procedury składowanej która została podpisana przy użyciu certyfikatu, uprawnienia przyznane użytkownikowi certyfikatu są scalane z tymi wywołującego. Kontekst wykonywania pozostaje taki sam; użytkownik certyfikatu nie podszywa się pod dzwoniącego. Podpisywanie procedur składowanych wymaga wykonania pewnych kroków. Za każdym razem, gdy procedura jest modyfikowana, musi zostać ponownie podpisana.

Dostęp między bazami danych

Łańcuch własności między bazami danych nie działa w przypadkach, w których są wykonywane dynamicznie tworzone instrukcje SQL. Można obejść ten problem w programie SQL Server, tworząc procedurę składowaną, która uzyskuje dostęp do danych w innej bazie danych, i podpisując procedurę przy użyciu certyfikatu, który istnieje w obu bazach danych. Zapewnia to użytkownikom dostęp do zasobów bazy danych używanych przez procedurę bez udzielania im dostępu do bazy danych lub uprawnień.

Zasoby zewnętrzne

Więcej informacji zawierają poniższe zasoby.

Resource Description
Procedury składowane i iniekcja SQL w książkach programu SQL Server Online Tematy opisują sposób tworzenia procedur składowanych i sposobu działania iniekcji SQL.

Dalsze kroki

  • Last updated on