Dlaczego ochrona przed iniekcją SQL nie ma wysokiego priorytetu?

W przypadku przepełnienia stosu widzę dużo kodu PHP w pytaniach i odpowiedziach zawierających zapytania MySQL, które są bardzo podatne na ataki typu SQL injection, mimo że podstawowe obejścia są szeroko dostępne od ponad dekady.

Czy istnieje powód, dla którego tego typu fragmenty kodu są nadal używane?

Myślę, że to głównie z powodu a) ignorancji b) lenistwa. Początkujący zwykle nie wiedzą dużo o iniekcji sql, a nawet kiedy o niej słyszą, ignorują ją, ponieważ jest to o wiele prostsze i łatwiejsze do kodowania w ten sposób.

PHP celowo sprawia, że ​​naprawdę bardzo łatwo jest ludziom, którzy bardzo mało wiedzą, tworzyć przydatne dynamiczne strony internetowe. Oznacza to, że PHP przyciągnie wielu początkujących, którzy tworzą coś użytecznego, uczą się na podstawie innych przydatnych przykładów i odwracają się, aby uczyć innych, jak robić to fajne, przydatne rzeczy. Rezultatem jest dużo złego kodu i grupa programistów, którzy nie wiedzą nic lepszego.

To tylko pogarsza sytuację, że duża część kompetentnych programistów nie chce mieć nic wspólnego z PHP. Zmniejsza to bazę doświadczonych ludzi, którzy chcą lepiej uczyć innych. Ale dlaczego unikają PHP? Cóż za kombinację czynników. Po części nie lubią radzić sobie z brodawkami językowymi. Po części dzieje się tak dlatego, że wolą pracować z dobrym kodem, a nie ma zbyt wiele dobrego PHP.

Dokładna konstelacja problemów użytych do wywołania Perla. Jako świetny przykład rozważ przypadek Matta Wrighta, entuzjastycznego nastolatka, który w latach 90. postanowił dostarczyć wiele przydatnych, dobrze udokumentowanych i łatwych do zainstalowania skryptów CGI. Niestety nic nie rozumiał na temat bezpieczeństwa, podobnie jak ludzie, którzy chcieli z niego korzystać. W rezultacie powstały Archiwa Skryptów Matta Wrighta, które stanowiły niekończący się strumień problemów bezpieczeństwa dla wczesnych skryptów CGI. Pomimo wysiłków takich jak http://www.scriptarchive.com/nms.html problem nie poprawił się dla Perla, dopóki dostawcy hostingu dzielonego nie uczynili PHP wygodniejszym niż cokolwiek innego. Doprowadziło to do problemu przejścia z Perla na PHP.

Niestety, istnieje mnóstwo niezadowalających samouczków PHP, a niektóre starsze książki o PHP również dały się nakłonić do napisania odpowiedniego kodu (bez korzystania z register_globals itp.).

Dodatkowo, magic_quotes_gpcgdy w przeszłości włączano tę funkcję, ludzie nie dbali o ucieczkę, ponieważ „po prostu działała”.

Osobiście uważam, że PHP jest łatwy w użyciu, więc oczywiście łatwo go niewłaściwie używać.

Jako człowiek i programista bardzo łatwo popełniam błędy i pomijam pewne rzeczy, zwłaszcza gdy mam presję czasu.

Łatwo i być może zbyt kuszące jest obwinianie pewnego języka za to, że jest zbyt dostępny dla własnego dobra. Ale byłoby to glosowaniem nad większym problemem omylności człowieka, niezależnie od języka wybranego do programowania.

To prawda, że ​​przeszliśmy długą drogę od czasu asemblera i myślę, że byłbym znacznie bardziej produktywnym programowaniem w bardziej nowoczesnym języku, takim jak PHP, Python, Ruby lub Java.

PHP (i inne języki skryptowe) faktycznie obniżyły barierę wejścia. Może to oznaczać, że więcej nowych programistów wypróbuje najpierw PHP. Ale to z pewnością nie oznacza również, że wszyscy programiści PHP są w jakiś sposób mniej wykwalifikowani lub mniej zdolni do uczenia się na własnych błędach niż programiści innych języków.

Rasmus Lerdorf stworzył PHP w oryginalnej formie w 1994 roku, od tego czasu znacznie się rozwinął. W swoim najnowszym wcieleniu obsługuje programowanie obiektowe, a także znakomite frameworki, takie jak Symfony. PHP jako język uwolnił się od swoich pierwotnych ograniczeń i rozwinął się, oferując dużą elastyczność w sposobie korzystania z niego przez programistów. Możesz go użyć do stworzenia skryptu o długości 9 000 wierszy kodu spaghetti lub możesz go użyć w kontekście nowoczesnego frameworka MVC, takiego jak Symfony: to twój wybór!

Podejrzewam, że luki w zabezpieczeniach nie są ograniczone do jednego języka. Kuszące jest odpisanie wszystkich programistów PHP jako mniej zdolnych lub bardziej podatnych na pisanie niepewnego kodu. Ale zastanawiam się, ile z tego jest stronniczością językową, a ile faktem?

Myślę, że częścią problemu są ludzie, którzy po prostu kopiują kod, nie zadając sobie trudu, aby dowiedzieć się, co robią, ale naprawdę moim zdaniem sposób, w jaki uczymy porgamnming, jest zepsuty i jest to jeden z powodów, dla których jest tak dużo złego kodu. Uczymy składni poza kontekstem, więc początkujący nie wiedzą, kiedy czegoś użyć, a kiedy nie, i jakie problemy ma rozwiązać składnia i jakie problemy nie mają rozwiązać. Więc używają młotka, gdy klucz byłby lepszym narzędziem.

Na przykład zamiast uczyć tylko składni, organizujesz kurs w taki sposób (najwyraźniej byłoby więcej kroków, jest to tylko podstawowy przykład budowania od podstawowych do bardziej złożonych problemów, a nie tylko uczenie składni):

1. W ten sposób konfigurujesz podstawową stronę internetową
2. W ten sposób strona internetowa pobiera dane z bazy danych
3. W ten sposób wysyłasz dane ze strony internetowej do bazy danych
4. W ten sposób upewniasz się, że wysyłane są właściwe dane.
5. W ten sposób chronisz bazę danych przed złośliwym wprowadzaniem danych

Myślę, że znajdziesz podobną liczbę przykładów MS SQL + ASP / ASP.NET, które są równie wrażliwe.

Wydaje mi się, że problem częściowo wynika z faktu, że kiedy próbujesz czegoś nauczyć, powiedzmy filtrowanie danych za pomocą klauzuli WHERE, to tak naprawdę nie chcesz zaśmiecać swojego przykładu, odpowiednio usuwając ciąg zapytania lub używając sparametryzowanego polecenia.

Szkolę programistów od wielu lat i potrafię wczuć się w ludzi, którzy piszą okropny kod w tutorialach. Czasami jest to najłatwiejsze do zrozumienia. Na marginesie jednak zawsze zwracam uwagę na kod, który jest podatny na ataki i robię z niego interesujący wątek dodatkowy.

Oryginalny autor PHP, Rasmus Lerdorf , w swoim niesławnym wpisie na blogu opowiada się za opracowaniem „bez ram” . Chociaż do zapytań SQL używa PDO, więc nie ma ryzyka wstrzyknięcia SQL. Wciąż dość brzydkie i przestarzałe w porównaniu do współczesnych frameworków MVC z warstwami ORM.

Możesz obwiniać tę słabą praktykę samego PHP. Starsze wersje PHP (do około 2006 r.) Unikałyby wszystkich zmiennych wejściowych GET i POST, dzięki czemu nadawały się do interpolacji zapytań do bazy danych BY DOMYŚLNIE. Zobacz http://php.net/manual/en/security.magicquotes.php

Nie należy mylić celu samouczka, którym jest pokazanie czegoś po prostu, z tym, co należy zrobić w środowisku produkcyjnym. Na przykład większość kodu samouczka, który napisałem, ma niewielką lub żadną kontrolę błędów / wyjątków. Próbuję przypomnieć czytelnikowi, że kod pokazuje tylko, jak wykonać określone zadanie, a nie jak uwzględnić wszystkie możliwe wyniki.

Kiedy uczyłem się PHP, spojrzałem na niektóre książki PHP + MySQL i tak, czuję, że przyczynia się to do złej praktyki. Ale mam współczucie, ponieważ uczą języka , a nie dobre praktyki programowania. W przeciwnym razie, gdzie by to się skończyło?