James Jenkins
2017-02-28 22:18:55 UTC
Czytałem o wstrzyknięciu SQL i zobaczyłem to, co skłoniło mnie do myślenia:
pola wejściowe tak małe, jak to możliwe, aby zmniejszyć prawdopodobieństwo, że haker będzie w stanie wcisnąć kod SQL w pole bez obcięcia (co zwykle prowadzi do błędu składni T-SQL).
Źródło: Microsoft SQL Server 2008 R2 Unleashed
Jaki jest najmniejszy rozmiar pola, w którym wstrzyknięcie SQL może spowodować szkody?
Szkodą jest modyfikacja bazy danych lub zwracanie wyników niezgodnych z przeznaczeniem. Umieszczenie znacznika komentarza końcowego ( - ) w dwuznakowym polu nie spowodowałoby szkody, a jedynie spowodowałoby błąd zapytania. Potencjalny haker może się dowiedzieć, że pole jest podatne na zastrzyk, ale nie jest w stanie go wykorzystać.
Jeśli podany błąd jest szczegółowy, może to wystarczyć do uzyskania przydatnych informacji, zwłaszcza gdy programista potraktował nazwy tabel jako „tajne” ...
SQL Injection nie zawsze jest wykonywana w polu wejściowym - możesz kierować na klauzule orderby w adresach URL, na przykład, w których możesz wykonać złośliwy sql.Ograniczony rozmiar pola tego nie powstrzyma.
@iain: Słuszna uwaga.Ponadto ograniczenie długości pól dla (zakładam) otrzymanych danych formularza HTML nie wydaje mi się dobrym sposobem na uniknięcie wstrzyknięcia sql.Unikanie iniekcji SQL jest w zasadzie rozwiązanym problemem;po prostu pozwól bibliotece połączeń bazy danych obsłużyć to, używając przygotowanych instrukcji z symbolami zastępczymi, zamiast wklejać razem zapytania za pomocą funkcji tekstowych języka programowania i robić to źle, ponieważ zapomniałeś zabezpieczyć się przed luką numer 59654.
@Pascal "* Unikanie iniekcji SQL jest w zasadzie rozwiązanym problemem; *" dotyczy tylko nowego kodu, w którym zastosowano odpowiednie uwagi.Istnieje wiele kodów, w których problem nie został rozwiązany.Przypuszczalnie istnieje długość znaków, poniżej której rozwiązywanie istniejących problemów jest mniej palące niż te z dłuższymi.
Czy tylko ja uważam, że ta książka powinna zostać publicznie spalona?Sparametryzowane zapytania istnieją od tak dawna, że autor prowadzi mnie do wniosku, że nie mają nawet połowy pojęcia, o czym mówią.Wygląda na to, że skopiowali i wkleili śmieci ze zbioru blogów i wydali książkę.Równie dobrze mogą ci powiedzieć, że powinieneś ćwiczyć strzelanie mniejszymi pociskami, abyś mógł zbudować odporność na większe pociski.
@MonkeyZeus
A co powiesz na 0 znaków?I tylko wtedy, gdy jest sprawdzane na serwerze.
@Xander To stwierdzenie bardzo mnie niepokoi.Z pewnością nie jestem też ekspertem od bezpieczeństwa, ale mój jeden akapit prawdopodobnie dziesiątkuje wszystko, co ma do zaoferowania ta książka.Wydaje mi się, że [Argument z ignorancji] (https://en.wikipedia.org/wiki/Argument_from_ignorance) nadal cieszy się niesłabnącą popularnością.Jedynym możliwym małym ułatwieniem oszczędzania dla tej książki byłoby, gdyby parametryzacja nie była obsługiwana w tej wersji SQL Server.Ponadto, jeśli jest to bardziej reguła niż wyjątek, będziemy mieli potężny ogień.
@MonkeyZeus Zgadzam się, że jest to niepokojące, ale mam trochę hobby, przeglądając porady dotyczące bezpieczeństwa w książkach technicznych, aw szczególności książkach o programowaniu.Pokrycie jest na ogół fatalne lub całkowicie nieobecne.Na przykład, mam książkę o budowaniu systemów handlu elektronicznego od podstaw, w której pokrótce omówiono użycie HTTPS, a następnie oświadczam, że dalsze dyskusje na temat bezpieczeństwa były „poza zakresem” książki.
@Xander Powiedziałbym, że „szukaj gdzie indziej” jest szlachetniejsze niż bezczelne twierdzenie czegoś w stylu „zaciemnij dane formularza za pomocą JavaScript i losowego klucza wygenerowanego przez serwer przed wysłaniem danych na serwer”.Przynajmniej w tej książce o handlu elektronicznym jest napisane „Hej, nie chcemy, aby Twój serwer został sfałszowany fallusem z papieru ściernego, więc jeśli zależy Ci na bezpieczeństwie, zdobądź dobrą książkę o tym. Nasza książka po prostu uczy, jak zbudować e-komercyjnej, a nie jak ją zabezpieczyć ”.
Z zasady jestem przeciwny paleniu książek - ale zagłosowałbym za przywróceniem zapasów dla autorów - „co zwykle prowadzi do błędu składniowego T-SQL” - celem SQL Injection jest sprawienie, aby przesłane dane wchodziły w interakcję zgranicami zamierzonego celu.
Podobnie jak w przypadku innych odpowiedzi, krótkie pola nie zapobiegną problemom.Niedawno pracowałem nad starszą aplikacją z 8-znakowym polem nazwy użytkownika (i 8 znaków zostało wpisanych w kodzie), ale nadal była otwarta na wstrzyknięcie SQL.Sytuacja pogorszyła się, gdy pole hasła zostało również użyte we wstrzyknięciu.
Chociaż zgadzam się w 100% co do tego, jak słabo rozwiązuje się te problemy z bezpieczeństwem i jak złe są rady zawarte w tej książce, myślę, że ta rada jest zła, głównie dlatego, że jest bardzo prawdopodobne, że pozwoli ludziom oszukać siebie„uchronili się przed wstrzyknięciem SQL i jest to również złe, ponieważ zachęca to do dążenia do redukcji ryzyka w przypadku, gdy wyeliminowanie ryzyka byłoby możliwe (i łatwe).Nie można zaprzeczyć, że ten cytat nie zapobiega iniekcji SQL;po prostu twierdzi, że „zmniejsza prawdopodobieństwo” (co jest głupie i mylące).
@MonkeyZeus Wiele interfejsów API bazy danych * nadal * nie obsługuje parametrów o wartościach tablicowych, takich jak te dla prawej strony operatora `IN`.Aby obejść ten problem, musisz uwzględnić zmienną liczbę parametrów w zapytaniu, w którym to momencie kończysz „wklejanie razem” listy symboli zastępczych i utrzymywanie kolejności pozycyjnych symboli zastępczych („?”) Zsynchronizowanych między instrukcjąa tablica wartości jest tak trudna, jak ucieczka.