2010-03-04 10 views
8

Powiel możliwe:
Can I protect against SQL Injection by escaping single-quote and surrounding user input with single-quotes?Jak ten kod zapytania SQL może zostać złamany/wykorzystany przez dane wejściowe użytkownika?

Mamy aplikację starszych, które nie robi zapytań z wykorzystaniem parametrów pozycyjnych, a tam wszędzie SQL. Zdecydowano (zanim zacząłem tutaj), że ponieważ dane wprowadzane przez użytkownika mogą zawierać apostrofy, każdy ciąg wejściowy powinien być ręcznie unikany dla tych apostrofów.

Oto zasadniczy oryginalny kod (nie napisane przez mnie), w języku C# dla łatwiejszego spożycia:

private string _Escape(string input) 
{ 
    return input.Replace("'", "''"); 
} 

private bool _IsValidLogin(string userName, string password) 
{ 
    string sql = 
     string.Format 
     (
      @"SELECT COUNT(*) FROM UserAccounts 
       WHERE UserName = '{0}' AND Password = '{1}'", 
      _Escape(userName), 
      _Escape(password) 
     ); 
    // ... 
}

To naprawdę wydaje się, że to może być uszkodzony w jakiś sposób, ale jestem ze stratą co do sposobu, w jaki może być wykorzystany przez dane wejściowe użytkownika. Załóżmy, że dane wejściowe użytkownika są niefiltrowane, dopóki nie trafią na _IsValidLogin i zapominają, że hasła wydają się być zapisane w postaci zwykłego tekstu.

Rozwiązanie tego problemu na dobre jest oczywiste - użyj parametrów pozycyjnych - ale potrzebuję trochę amunicji, aby zademonstrować kierownictwu, dlaczego/jak ten kod jest niepewny, dzięki czemu czas/$ może zostać przydzielony, aby uzyskać poprawkę.

Uwaga: Jestem przy założeniu, że może to zostać zerwane, ale może tak nie być. Nie jestem gwiazdą SQL.

Uwaga 2: Przedstawiłem to pytanie jako agnostykę bazy danych, ale jeśli można wykorzystać ten kod do określonego silnika, z zadowoleniem przyjmuję twój wkład.

+1

Warto przeczytać tutaj, jeśli jeszcze tego nie zrobiłeś: http://stackoverflow.com/questions/139199/can-i-protect-against-sql-injection-by-escaping-single-quote-and- użytkownik otaczający –

+0

@Nick: Dzięki, nie widziałem tego. Zamknę to pytanie jako duplikat. –

+0

Zamknięte na prośbę autora. –

Odpowiedz

3

Może być wyeksportowany przez ukośniki odwrotne.

password = foo\' OR 1=1 -- 

staje:

password = foo\'' OR 1=1 -- 

zapytanie:

"SELECT COUNT(*) FROM UserAccounts 
       WHERE UserName = '{0}' AND Password = 'foo\'' OR 1=1 --'" 

-- jest znak komentarz w tym przykładzie.

Rozwiązanie zakłada program tylko filtruje (duplikuje) apostrofy.

+0

Nie mogę powiedzieć o innych bazach danych, ale ukośnik odwrotny nie wydaje się być znakiem escape w MSSQL i byłby po prostu użyty dosłownie. Twój przykład będzie po prostu wyszukiwać hasła "'foo \' OR 1 = 1 -" –

0

Cóż, nie widzę sposobu, w jaki jest on wrażliwy. Tak więc, spróbujmy argumentować innym powodem, dla którego należy go zmienić - jest raczej nieefektywny. W MSSQL (i, jak sądzę, większości innych wysokiej klasy serwerach SQL), przetwarzane są zapytania, opracowywany jest plan wykonania, a następnie przechowywane jest zapytanie i plan. Jeśli ponownie zażądana zostanie kopia zapytania w wersji exact, zostanie użyty zapisany plan wykonania. Parametr nie ma na to wpływu, więc jeśli użyjesz parametrów, ponownie użyje planów; jeśli umieścisz tekst, nigdy go nie będzie.

+0

Jest podatny na ataki. W przykładzie nie jest używane żadne powiązanie parametrów. – erenon

Powiązane problemy