Nie ma ogólnego rozwiązania dla SQLi, ponieważ nie ma rozwiązania dla ludzkiej głupoty. Istnieją ustalone techniki, które są łatwe w użyciu i które rozwiązują problemy (zwłaszcza wiązanie parametrów), ale nadal trzeba ich używać. Wielu programistów po prostu nie zdaje sobie sprawy z problemów z bezpieczeństwem. Najbardziej dba o to, aby aplikacja w ogóle działała i nie przejmowała się zbytnio bezpieczeństwem, zwłaszcza jeśli sprawia, że ​​(nawet nieznacznie) jest bardziej złożona i wiąże się z dodatkowymi kosztami, takimi jak testowanie.

Ten rodzaj problemu nie ogranicza się do SQLi, ale można go znaleźć w przypadku przepełnienia bufora, sprawdzania certyfikatów, XSS, CSRF .... Bezpieczne programowanie jest droższe z powodu dodatkowych testów i dodatkowej wiedzy potrzebnej (a więc droższemu) programistowi. Tak długo, jak rynek preferuje tanie i nie dba o bezpieczeństwo, dostajesz tanie i niepewne rozwiązania. I chociaż bezpieczeństwo zgodne z projektem bardzo pomaga w ulepszaniu go, programiści często omijają ten projekt, ponieważ go nie rozumieją i po prostu przeszkadza.

Ponieważ to nie jest problem.

• Kiedy ostatnio firma z luką w zabezpieczeniach SQL injection została postawiona przed sądem i ukarana dużą grzywną za lekkomyślność dane użytkownika, a dyrektorzy ostrzeżeni, ukarani grzywną lub skazani za zaniedbanie?

• Kiedy ostatnio firma straciła duży kontrakt, ponieważ strona logowania do witryny firmy nie sprawdzić poprawność haseł?

• Kiedy ostatni raz wykwalifikowany regulator / audytor z profesjonalnej organizacji musiał zatwierdzić i podpisać publiczny system komputerowy, zanim mógł zostać oddany do użytku ?

Można by pomyśleć, że „ludzie umrą” to wystarczający powód, aby budować budynki z materiałów ognioodpornych, alarmów i dobrych dróg ewakuacyjnych. To nie było. Wprowadziliśmy przepisy, które narzucają niepalne materiały budowlane, konstrukcje przeciwpożarowe z przerwami przeciwpożarowymi, alarmy przeciwpożarowe.

Możesz pomyśleć, że „ludzie umrą” to wystarczający powód, aby wszystkich dbają o projekt konstrukcyjny budynku. To nie jest. Po prostu nie jest. Musimy mieć regulacje, aby wykwalifikowani inżynierowie podpisywali projekty budynków, aby były projektowane i budowane do określonych zastosowań, a gdy coś zawodzi, społeczeństwo pozywa inżynierów do sądu.

Można by pomyśleć, że „ludzie umrą” to wystarczający powód, aby uczynić przetwarzanie żywności czystym i bezpiecznym, ale tak nie było.

SQL Injection jest mniej oczywisty, mniej widoczny publicznie, ma mniejszy wpływ i znajduje się w całkowicie nieuregulowanej branży.

Nawet firmom, którym na tym zależy, nie mogą pożytecznie reklamować „ Żadnych znanych luk w zabezpieczeniach SQL injection w naszym kodzie ” jako marketingowego punktu, na którym komukolwiek zależy. To nie jest pytanie, które klienci zadają sprzedawcom. To nie jest dla nich przewaga konkurencyjna, to koszt, narzut. Ochrona przed tym sprawia, że ​​są mniej konkurencyjni, wolniej się poruszają, wykonują więcej pracy przy tej samej funkcjonalności.

Wszystkie zachęty są dostosowane do tego, aby nadal istniał. Więc nadal istnieje.

Niech wstrzyknięcie SQL będzie problemem dla firm, a one znikną.

[Edytuj: Ale istnieje rozporządzenie UE, zgodnie z którym strony internetowe muszą Cię ostrzegać, jeśli używają plików cookie. I robią. Tak więc regulacja publicznych systemów komputerowych, aby były bardziej irytujące, może wejść w życie - nawet jeśli obecne przepisy są dość bezużyteczne.]

Wstrzykiwanie SQL wciąż istnieje, ponieważ świat oprogramowania nadal nie rozumie, że programistyczne generowanie wartości w strukturze drzewa (takich jak zapytania lub znaczniki) powinno odbywać się poprzez konstruowanie drzew składni jako obiektów pierwszej klasy , a nie przez konkatenację łańcuchów, które reprezentują fragmenty języka.

W ostatnich latach nastąpił niewielki postęp wraz ze wzrostem dostępności narzędzi do tworzenia zapytań, takich jak LINQ to SQL lub SQLAlchemy, ale to po stronie języka programowania. Relacyjne bazy danych nadal nie oferują standardowego, atrakcyjnego alternatywnego interfejsu, który nie jest zasadniczo oparty na wysyłaniu zapytań w postaci ciągów.

Przygotowane instrukcje z parametrami zapytań nie są poprawą, ponieważ są łatwe w użyciu tylko wtedy, gdy struktura Twoich zapytań - które tabele są połączone, jakie warunki filtrowania, jakie kolumny mają zostać zaprojektowane - jest stała . Gdy masz aplikację, która musi konstruować tekst zapytania w czasie wykonywania, użycie przygotowanych parametrów zapytania jest dużym problemem.

Tak więc, gdyby można było skonstruować ustandaryzowany, nietekstowy protokół o strukturze drzewiastej do opisywania i przekazywania zapytań do bazy danych, i zostałby zaprojektowany tak, aby był łatwiejszy w użyciu niż zapytania tekstowe, wtedy to rozwiązałoby problem problem w dłuższej perspektywie. Ale problem nie zniknie, dopóki branża nie przyjmie czegoś, na czym ścieżka najmniejszego oporu jest bezpieczna. Tak długo, jak będziemy nalegać na niebezpieczne domyślnie systemy, w których pisanie bezpiecznego kodu wymaga niepotrzebnego wysiłku, będą z nami problemy. (Pomyśl o wszystkich przepełnieniach bufora, które w ogóle nie istnieją w językach zarządzanych pamięcią!)

Zwróć uwagę, że ten sam fundamentalny problem, co wstrzyknięcie SQL, nęka sieć, pod nazwą cross-site scripting - co w rzeczywistości jest po prostu wstawieniem JavaScript do dynamicznych stron HTML. Bardzo częstym wzorcem są programiści Javascript, którzy zamiast pracować z DOM traktując go jak drzewo obiektów, używają właściwości innerHTML , aby ustawić go na tekst HTML, który zbudowany przez naiwną konkatenację ciągów. Wiele luk w zabezpieczeniach XSS nigdy by nie istniało, gdyby właściwość innerHTML nigdy nie została umieszczona w implementacjach DOM przeglądarek.

Ponadto, dla osób, które nie widziały przemówienia Tony'ego Hoare'a na temat wskaźników zerowych, jest ono jednocześnie ortogonalne (wskaźniki zerowe, nie wstrzyknięcia SQL), ale jednocześnie niezwykle istotne:

• Tony Hoare, „Null References: The Billion Dollar Mistake”.

Podczas testowania bardzo łatwo jest sprawdzić, czego spodziewasz się , że się wydarzy. Na przykład, wypełniając pole „imię” w bazie danych, prawdopodobnie wybierzesz coś, co znasz, na przykład „Jan Kowalski”. To działa, a Twoja aplikacja wydaje się działać dobrze.

Pewnego dnia ktoś nadaje dziecku imię Robert '); DROP TABLE Studenci; - (małe tabelki Bobby'ego).

Oczywiście nie testujesz aplikacji pod kątem takich nazw , więc luka w zabezpieczeniach, którą ujawnia taka nazwa, wymyka się wszystkim testom.

Jest tutaj interesujący komentarz: Niesprawiedliwość roszczeń dotyczących zabezpieczeń

To łatwo udowodnić, że istnieje luka w zabezpieczeniach (wystarczy przetestować ją pod kątem nazwy takiej jak powyżej). Łatwo też udowodnić, że dana dziura została naprawiona. Trudno jest udowodnić, że nie ma innych luk w zabezpieczeniach.

Steffen ma dobre uwagi w swojej odpowiedzi, ale chciałbym to dodać. Myślę, że powód można podzielić na następujące tematy:

• Brak wiedzy lub wykształcenia programistów
• Odejście w środowisku programistycznym przedsiębiorstwa
• Presja, aby działać przed terminem
• Niewystarczający nacisk z góry na bezpieczeństwo

Rozważmy to.

Szkolenie programistów

W dzisiejszych czasach duży nacisk kładzie się na edukację użytkowników. Naucz użytkowników, jak utrzymywać silne hasła. Naucz użytkowników, jak rozpoznawać phishing. Naucz użytkowników, jak ... Masz pomysł. Niektórych przedsiębiorstw zapewne dużo, ale mogę mówić tylko o swoim doświadczeniu zawodowym i nie pracowałem w wielu przedsiębiorstwach;), mam programy szkoleniowe. Ale te programy szkoleniowe mogą być niekompletne lub nie obejmować wymaganej wiedzy. Nie chodzi o dyskredytację ciężkiej pracy włożonej w tworzenie tych programów. Ale powiedzieć, że tak jak w środowisku szkolnym, różni ludzie uczą się inaczej. A jeśli nie masz programu kształcenia ustawicznego dla programistów, trudno będzie się komunikować „używaj zapytań parametrycznych, a oto jak to zrobić w PHP, Java, Python, Ruby, Scala, NodeJS, ...”. Tworzenie, dostarczanie i utrzymywanie programów deweloperskich, które skutecznie docierają do odbiorców, to ciężka praca.

Odejście deweloperów

Powyżej jedną z rzeczy, o których wspomniałem, było skuteczne docieranie do odbiorców w celu uzyskania różnych rodzajów uczenia się. Jednym z powodów jest to, że wiele przedsiębiorstw ma wysoki wskaźnik rezygnacji z deweloperów, ponieważ deweloperzy są wykonawcami, którzy są przenoszeni z projektu do projektu w różnych firmach. A firmy nie zawsze mają taką samą dojrzałość bezpieczeństwa. Jedna firma może w ogóle nie mieć programu bezpieczeństwa, podczas gdy inna może mieć doskonały program bezpieczeństwa, a programista jest nagle bombardowany nowymi informacjami, które będą od nich wymagane przez całe sześć miesięcy, zanim przeniosą się do innej firmy. To smutne, ale się zdarza.

Realizacja projektu

Realizacja projektu zgodnie z harmonogramem lub nawet przed terminem. Najszybszą drogą do ukończenia projektu zwykle niestety nie jest zakończenie projektu kontrolą bezpieczeństwa. Robi to w najbardziej zepsuty sposób, który wciąż działa. Wiemy, że przyniesie to więcej pracy, czasu i pieniędzy później, gdy przyjdzie czas na utrzymanie projektu i naprawienie problemów, ale zarząd chce tylko, aby projekt został usunięty.

opracowywanie programów szkoleniowych w zakresie bezpieczeństwa dla niezliczonych języków programowania. Wiele przedsiębiorstw nie ma jednego lub dwóch ustawionych języków. Dlatego programiści lubią (lub są do tego zachęcani) wypróbowywanie nowej wersji. Obejmuje to języki i frameworki. Oznacza to, że programy bezpieczeństwa muszą stale ewoluować.

Zaangażowanie kierownictwa

A oto zarządzanie. Za każdym razem wydaje się, że w przypadku naruszenia bezpieczeństwa publicznego istniały kontrole, które można było wdrożyć, które nie są takie trudne, ale zostały pominięte. Naciska na dostarczanie produktów jako pierwsze, a martwienie się zawsze na drugim miejscu, pomimo lekcji po lekcji, wraca do firm zajmujących się produktami. Kierownictwo musi naciskać od góry, aby na początku poświęcić trochę czasu na zbudowanie bezpieczeństwa. Muszą zrozumieć, że więcej pracy, więcej czasu i więcej pieniędzy zostanie przeznaczonych na naprawę problemów, konserwację produktu i zapłacenie kar. Jednak analizy kosztów i korzyści wskazują, że problemem jest dostawa produktu, a nie grzywny lub wymagane prace konserwacyjne. Te równania muszą się zmienić, a to częściowo sprowadza się do edukacji (wooo, pełne koło) na poziomie MBA. Menedżerów biznesowych trzeba nauczyć, że aby odnieść sukces w środowisku stale rosnących naruszeń, bezpieczeństwo musi być najważniejsze.

Podsumowanie

Dlaczego, mimo że SQLi ma prawie 20 lat , ma kilka powodów. Jako praktycy bezpieczeństwa możemy zrobić tylko tyle, aby edukować i podnosić świadomość tego, co się dzieje, gdy bezpieczeństwo nie jest uważane za integralną część SDLC.

Zgadzam się z wieloma odpowiedziami, ale nie jest powiedziane o jednej bardzo ważnej kwestii: kod nie naprawia się w magiczny sposób, a jest dużo kodu, który ma 17 lat. Widziałem wiele firm, które pisały czysty i bezpieczny nowy kod, podczas gdy aplikacja nadal mogłaby zostać zaatakowana w niektórych jej starszych sekcjach. A co najgorsze: naprawianie starego kodu jest kosztowne, ponieważ wymaga od programistów zagłębienia się w kod, który został napisany w innej erze z różnymi stylami kodowania i różnymi technologiami. Czasami naprawienie starego kodu tak, aby nie powodował wstrzyknięć SQL, wymagało odtworzenia całych bibliotek, które zostały odkupione w ciągu dnia (musiałem to zrobić kilka lat temu).

Nie mówiąc o tym cały nowy kod jest wolny od zastrzyków SQL, ale osobiście nie widziałem żadnego profesjonalnie napisanego nowego kodu w ciągu ostatnich 4 lub 5 lat, który je zawierał. (Jedynym wyjątkiem jest sytuacja, w której programiści muszą wykonać szybką i brudną naprawę w starym kodzie i użyć tego samego stylu / technologii, w której napisana jest reszta kodu).

Uważam, że dzieje się tak, ponieważ wielu programistów uczy się wystarczająco dużo, aby wykonać swoją pracę, dla pewnej wartości „skończonej”. Uczą się, jak budować kod SQL, często z przestarzałych samouczków online, a kiedy kod „działa” do tego stopnia, że ​​mogą powiedzieć „Mogę umieścić rzeczy w bazie danych i mogę wygenerować stronę wyników” Jestem zadowolony.

Weź pod uwagę tego gościa na drabinie:

Dlaczego on to robi? Dlaczego nie ma odpowiedniego rusztowania? Ponieważ wykonuje swoją pracę. Umieść drabinę przy ścianie nad schodami i działa dobrze. Aż tak się nie stanie.

To samo z INSERT INTO users VALUES ($ _ POST ['user']) . Działa dobrze. Dopóki tak się nie stanie.

Inną rzeczą jest to, że nie są świadomi zagrożeń. Z facetem na niestabilnej drabinie rozumiemy grawitację i upadek. Budując instrukcje SQL na podstawie niepotwierdzonych danych zewnętrznych, nie wiedzą, co można zrobić.

W zeszłym miesiącu rozmawiałem z grupą użytkowników programistów internetowych, a z 15 programistów obecnych na widowni dwóch słyszało iniekcji SQL.

Myślę, że głównym powodem jest to, że szkolenie programistów nie zaczyna się od sprawdzonych metod, ale zaczyna się od zrozumienia języka. Dlatego nowi programiści, wierząc, że zostali przeszkoleni z narzędziami do tworzenia czegoś, kontynuują tworzenie zapytań w sposób, w jaki ich nauczono. Następnym i najniebezpieczniejszym krokiem jest umożliwienie komuś opracowania czegokolwiek bez przeglądu, a tym samym ciągła okazja do dokonywania mniej złych wyborów, nie wiedząc, że coś jest z nimi nie tak, i tworzenia dalszych nawyków, które ignorują ogólnie przyjęte w branży najlepsze praktyki. Podsumowując - słabo wyszkoleni programiści działający w środowisku, które nie ceni nic poza produktem końcowym.

Nie ma to nic wspólnego z inteligencją czy „ludzką głupotą”. Istnieje systematyczne podejście, które zostało dobrze zdefiniowane przez lata, a każdy, kto tworzy oprogramowanie, jest zaniedbaniem, aby zignorować ten proces w imię szybszej lub tańszej implementacji. Być może któregoś dnia konsekwencje prawne tego zachowania umożliwią nam wprowadzenie większej liczby kontroli, takich jak w branży medycznej lub budowlanej, gdzie nieprzestrzeganie tych zasad i przyjętych praktyk spowoduje utratę licencji lub inną karę.

Dlaczego luki w zabezpieczeniach typu SQL injection jeszcze nie wygasły? Mówiąc metaforycznie, z tego samego powodu, dla którego zdarzają się wypadki samochodowe od czasu pierwszego samochodu w 1895, a nawet najbardziej innowacyjnych i nowoczesnych samochodów samojezdnych, Tesla model S (na autopilocie) lub auto samojezdne Google od czasu do czasu ulega awarii.

Samochody są tworzone (i kontrolowane) przez ludzi, ludzie popełniają błędy.

Witryny i aplikacje (internetowe) są tworzone przez ludzi-programistów. Zwykle popełniają słabe błędy w projektowaniu zabezpieczeń lub mają tendencję do niszczenia rzeczy za pomocą „szybkich poprawek”, gdy coś jest bezpieczne, ale w rzeczywistości wprowadza nową lukę, na przykład dlatego, że czas / budżet na opracowanie poprawki był ograniczony, lub programista miał wielkiego kaca, kiedy pisał poprawkę .

Czy zawsze jest to spowodowane przez programistów? Zasadniczo tak, ale nie zawsze przez programistę pierwszej linii . Na przykład lokalny supermarket poprosił firmę zajmującą się tworzeniem stron internetowych o stworzenie dla nich strony internetowej. Deweloperzy wynajmują część współdzielonej przestrzeni hostingowej od firmy hostingowej do hostowania witryny i instalują WordPress oraz kilka przydatnych wtyczek.

Teraz programiści firmy zajmującej się tworzeniem stron internetowych niekoniecznie muszą popełniać błąd, wprowadzając lukę w zabezpieczeniach typu SQL injection, aby być podatnym na ataki. Co mogło się tutaj nie udać? Kilka przykładów:

1. Firma hostingowa nie zaktualizowała PHP do najnowszej wersji, a używane wersje PHP okazały się ogólnie podatne na SQLi.
2. Hosting firma skonfigurowała dodatkowe publiczne oprogramowanie, takie jak phpMyAdmin i nie zaktualizowała tego.
3. Okazuje się, że używana wersja WordPress jest podatna na SQLi, ale aktualizacja została pominięta lub nie jest jeszcze dostępna łatka.
4. Używana wtyczka WordPress jest podatna na SQLi.

Teraz pytanie, które się pojawia , kto jest za to odpowiedzialny? Supermarket, firma zajmująca się tworzeniem stron internetowych, firma hostingowa, społeczność WordPress, twórcy wtyczek WordPress lub osoba atakująca, która nadużyła luki, mówiąc retorycznie? - To nie jest stwierdzenie, jest przesadzone i tylko kilka pytań, które mogą być zadawane w przypadku, gdy coś pójdzie nie tak.

Często powyższa dyskusja (pytania dotyczące odpowiedzialności, choć nieco przesadzone) jest również czynnikiem ryzyka, ponieważ niektórzy programiści mają tendencję do „to nie moja kod „-attitude . Możesz sobie wyobrazić, jak skomplikowana jest to czasami sytuacja.

Po pierwsze, nikt nie pisze poprawnie bezpiecznych wymagań, mówią coś w stylu „Produkt powinien być bezpieczny”, czego w żaden sposób nie da się przetestować.

Po drugie, deweloperzy zajmujący się zawodami nie są głupi, a mówienie tego jest raczej nieszczere, wszyscy prawdopodobnie mają wyższe wykształcenie i rozwiązują problemy, na które nawet nie zaczęliśmy zwracać uwagi ... Problem polega na tym, że nigdy nie uczono ich, co to jest bezpieczne tworzenie oprogramowania. Zaczyna się w szkołach, potem na uniwersytecie, a potem niezależnie od wykonywanej pracy, gdzie każde szkolenie odbywa się „w miejscu pracy”, ponieważ firmy programistyczne zbyt boją się szkolić programistów na wypadek ich odejścia.

Programiści też są pod rosnącą presją, aby wykonać więcej pracy w krótszym czasie, są zajęci naprawianiem jednego problemu i przejściem do następnego, jest mało czasu na zastanowienie się, gdy pojawi się następny problem.

Programiści nie są zachęcani do testowania poza tym, co opracowują, jeśli napotkają problem, prawdopodobnie będą programistą, który go naprawi. Mantra dewelopera brzmi: „Nie testuj tego, co nie jesteś przygotowany do naprawiania”.

Po trzecie, testerzy są również nie jest przeszkolony w znajdowaniu luk w zabezpieczeniach, z tego samego powodu co twórcy oprogramowania. W rzeczywistości wiele testów (moim zdaniem) to po prostu powtórzenie testów przeprowadzonych przez zespół programistów.

rynek to ogromny czynnik. Jeśli jesteś na rynku, najpierw zarabiasz, bezpieczny rozwój jest postrzegany jako mający duży wpływ na szybkość rozwoju - mam na myśli naprawdę, kto ma czas na model zagrożenia! ;)

Wreszcie nie chodzi tylko o zastrzyki SQL, przepełnienia buforów są znane od lat 60-tych i nadal można się o nie potykać z niepokojącą regularnością.

Tak, antropologicznie ludzie są głupi.

Tak, z politycznego punktu widzenia, struktura motywacyjna niewystarczająco penalizuje wrażliwe aplikacje

Tak, proces jest wadliwy - kod jest napisane w pośpiechu; zły / stary kod jest nie zawsze wyrzucany.

I tak, technicznie rzecz biorąc, traktowanie i mieszanie danych jako kodu jest trudniejsze do zrobienia domyślnie.

Ale jest bardziej pozytywny pogląd (zignorujmy 99% luk w SQLi, które wyjaśniają powyższe odpowiedzi). SQLi nadal istnieje na bardzo dobrze zaprojektowanych i starannie opracowanych witrynach internetowych, ponieważ jesteśmy niesamowici . Zasada hakerów. Wystarczy spojrzeć na setki wektorów ataku i tysiące ładunków SQLi, które zostały opracowane w ciągu ostatnich siedemnastu lat, aby odzyskać wiarę w rasę ludzką. Z każdym rokiem prezentowane są nowe techniki DEFCON / BlackHat / RSA / IEEESSP. Programy nagród za błędy dla Facebooka, Google i tym podobnych musiały co najmniej raz wypatrywać krytycznego SQLi.

Częściowo wynika to ze złożoności i liczby warstw w naszym systemie, z których każda mutuje dane w nowszy i bardziej interesujący sposób. Coraz więcej potrzebujemy zrobić więcej, szybciej, przy użyciu mniejszych zasobów. Dopóki nie będziemy w stanie przetestować wszystkich ścieżek do systemu, nikt nie będzie certyfikował rozwiązania problemów z wtryskiem.

Ponieważ takie kwestie bezpieczeństwa nie są uwzględniane podczas większości 3-letnich cykli edukacyjnych i równoważnych studiów, a wielu programistów podążało tą ścieżką (w tym ja). Biorąc pod uwagę, jak szeroka jest ta dziedzina, w rzeczywistości 3 lata nie wystarczą nawet, aby poradzić sobie z rzeczywistym programem studiów. Więc rzeczy takie jak bezpieczeństwo zostały odrzucone.

To niefortunne, ale niektórzy nowi programiści wygrali Nigdy nie próbowali samodzielnie uczyć się nowych rzeczy, ci ludzie zawsze będą pisać kod podatny na SQLi, dopóki bardziej wykształcony kolega nie wskaże problemu (lub dopóki nie nastąpi faktyczny SQLi).

Podczas moich studiów (wiele lat temu) nasi nauczyciele zawsze mówili nam, abyśmy używali PreparedStatements przy tworzeniu ręcznych zapytań SQL, ponieważ jest to „najlepsza praktyka”, ale nie powiedzieli dlaczego. To lepsze niż nic, ale wciąż dość smutne. Nie jestem pewien, czy ci nauczyciele w ogóle znali siebie.

Dowiedzieliśmy się, jak wyświetlać rzeczy na jsp, ale nie czym jest Cross-Site-Scripting.

Mam szczęście, że jestem pasjonatem i mam trochę czasu na ręce, więc nauczyłem się tego wszystkiego samemu dawno temu, ale jestem pewien, że wielu programistów po prostu robi swoje 8 godzin dziennie (przy okazji z uzasadnionych powodów) i tak długo, jak nikt im tego nie pokazuje jest źle, to się nie zmieni.

Jeśli używasz poprawnie przygotowanych instrukcji, wstrzyknięcie SQL nie jest możliwe.

„Jeśli oryginalny szablon instrukcji nie pochodzi z danych wejściowych zewnętrznych, wstrzyknięcie SQL nie może wystąpić.”

https://en.m.wikipedia.org/wiki/ Prepared_statement

Niestety, ludzie zazwyczaj nie używają przygotowanych instrukcji poprawnie, jeśli w ogóle.

Wstrzyknięcie SQL byłoby przeszłością, gdyby tak było.

I tak, php / MySQL ma przygotowaną implementację instrukcji przez bardzo długi czas, ponad 10 lat, jeśli pamięć służy ...

Inne odpowiedzi wskazywały na prawie wszystkie przyczyny. Ale jest jeszcze coś, co moim zdaniem jest najbardziej niebezpieczne ze wszystkich. Programiści próbują dodawać coraz więcej funkcji do technologii i czasami odbiegają od rzeczywistego celu technologii. Trochę tak, jak język skryptowy po stronie klienta został użyty do kodowania po stronie serwera lub uzyskał dostęp do zdalnych zasobów, a także lokalnej pamięci po stronie klienta. Patrząc na niektóre zaawansowane zastrzyki SQL, możemy zobaczyć, jak odegrały one rolę w stałym akcentie ataków SQLi.

Jednak w przypadku SQL, wydaje mi się, że największym błędem było połączenie poleceń i parametrów. To trochę jak wywołanie run (value, printf) zamiast printf(value).

No i ostatnia rzecz, chociaż jest to dość łatwe konwertować między różnymi typami baz danych, zmiany wymagane w kodzie po stronie serwera są gigantyczne.

Ktoś powinien abstrahować między różnymi typami baz danych i ułatwiać przełączanie się między różnymi bazami danych. Powiedz wtyczkę php, która przyjmuje jako dane wejściowe polecenia QL i typ bazy danych i może być filtrem z białej listy, aby oczyścić dane wejściowe.

Osobiście uważam, że jest to szczególny przypadek bardziej ogólnego problemu w programowaniu, w którym IDE i języki są zbyt liberalne. Dajemy naszym programistom ogromną moc w imię elastyczności i wydajności. Rezultatem jest „to, co może się stać, stanie się”, a luki w zabezpieczeniach są nieuniknione.

PDO (lub inne „bezpieczne” metody) nie jest bezpieczniejsze niż mysql_ (lub inne „niebezpieczne” metody). Ułatwia to pisanie bezpiecznego kodu, ale jeszcze prostsze jest po prostu konkatenację ciągów znaków dostarczonych przez użytkownika bez zmiany znaczenia w zapytaniu i nie przejmowanie się parametrami.