Dlaczego ochrona przed iniekcją SQL nie ma wysokiego priorytetu?

39

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?

Lekkość Wyścigi z Moniką
źródło
37
winić za źle napisane samouczki online. częściej ludzie kopiują i wklejają kod znaleziony w sieci. JavaScript jest także kolejną ofiarą takiej praktyki.
KJYe.Name
34
Obwiniaj blogi. Aha, i W3Schools ...
Brian Driscoll
13
Tak, absolutnie W3Schools - patrz w3fools.com
DisgruntledGoat
2
Ciągle widzę ludzi ostrzegających o zastrzyku sql - więc nawet nie sądzę, że przesłanie tego pytania jest prawidłowe. To ma wysoki priorytet.
GrandmasterB,
3
W wielu odpowiedziach widzę, że łatwiej jest uczyć krytycznie zepsutego PHP niż uczyć, cóż, PHP, który nie jest zepsuty krytycznie. Nie możesz zaakceptować tego argumentu i nadal twierdzić, że PHP nie jest złym językiem
user16764

Odpowiedzi:

34

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.

froadie
źródło
8
Próbowałem skorygować takie rzeczy gdzie indziej, ale powiedziano mi, że nie ma to związku z danym problemem. Ponieważ wiele osób woli prosty hack od nieco bardziej złożonego dobrego rozwiązania, złe przykłady pozostawia się w spokoju.
l0b0
6
Większość ludzi tak naprawdę nie dba o zastrzyk SQL, dopóki go nie trafi. Nagle zastanawiają się, dokąd poszły ich stoły.
Joel Etherton,
1
Innym powodem jest to, że wstrzyknięcie SQL nie zawsze jest postrzegane jako istotny problem dla wewnętrznych aplikacji. (Nie to, że mają rację.)
John Fisher,
1
Nie zapominaj, że są odpowiedzi, aby odpowiedzieć na pytanie. Często to pseudo-kod (lub SQL) ma na celu odpowiedzieć na pytanie, niekoniecznie zapewniając bezpieczne rozwiązanie do kopiowania i wklejania (pomimo tego, w jaki sposób można użyć odpowiedzi w rzeczywistości).
Dalin Seivewright,
1
@ l0b0 Znam kogoś, kto zmusił ludzi do poważnego potraktowania iniekcji SQL, demonstrując w rzeczywistości atak iniekcji SQL na bieżący kod produkcyjny.
user16764
26

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.

btilly
źródło
Jak już wspomniałeś, problemem nie jest Perl ani PHP, ale to, że te języki pozwalają początkującym robić wiele rzeczy, co jest dobre, ale nie zawsze zapewniają sposoby robienia ich dobrze, które są tak oczywiste.
Zachary K
2
@ZacharyK: Czy to nie jest wina języka?
Lekkość ściga się z Moniką
6
@ tomalak-geretkal: Używasz słowa „wina”, tak jakby umożliwić załatwienie rzeczy jest złą rzeczą. Te same cechy, które prowadzą do wielu złych kodów, prowadzą również do rozwiązania wielu prawdziwych problemów. Nie jest jasne, czy ogólnie jest to zła rzecz.
btilly,
Re „wina”: gdyby HTML (a raczej interpretujące go przeglądarki) byłby tak odporny na uszkodzenia jak XSL, nigdy nie byłoby sieci WWW ...
Benjol,
8

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”.

ThiefMaster
źródło
4

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

davidhaskins
źródło
2

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?

Jay Sheth
źródło
Nie powiedziałem nic o „wszystkich programistach PHP”.
Wyścigi lekkości z Monicą,
2

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
HLGEM
źródło
mniej więcej tak nauczono mnie php +1
Remi
1

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.

Grzyb
źródło
6
To nie powinno być na bok. To powinno być częścią podstawowej lekcji. Być może z dużym, grubym ostrzeżeniem o złym sposobie robienia rzeczy. Ludzie mają tendencję do wycinania i wklejania tego, co widzą po raz pierwszy, i naprawdę chcesz, aby był to właściwy sposób robienia rzeczy.
btilly,
Z pewnością w świecie .NET parametryzacja jest w tej chwili dość prosta i rzeczywiście powinna być „pierwszą stroną”.
Alan B
1

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.

vartec
źródło
5
Z pewnością możliwe jest nadinstruowanie witryn za pomocą złożonych platform, których po prostu nie potrzebujesz. Powiedziałbym, że sugestie Rasmusa są bliskie niebezpieczeństwu kryminalnemu, ale zdecydowanie jest rozsądny środek.
Lekkość ściga się z Moniką
obecnie używanie ORM nie jest nadmierną inżynierią; to standard. Podobnie jest ze wzorem MVC.
vartec,
3
@vartec: To prawie „standard” tylko dlatego, że wszystkie owce używając go (i za to, co warte, nawet wszystkie owce go używać). Dla małych skryptów może łatwo być ponad-engineering.
Wyścigi lekkości z Monicą
1
@Tomalak: to standard, ponieważ jest to sposób na wdrażanie czystych i zrównoważonych projektów. „małe skrypty” z czasem rosną i stają się niemożliwymi do utrzymania potworami.
vartec
2
@vartec: Myślę, że źle zrozumiałeś znaczenie słowa „standard”.
Wyścigi lekkości z Moniką
1

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

Ben XO
źródło
2
Był czas, żeby uciekał WSZYSTKIM zmiennym tak, jakby wchodzili konkretnie do MySQL, bez względu na to , czy kiedykolwiek byli, czy nie . Uwaga dla projektantów języków: kiedy musisz wdrożyć stripslashes(), już zrobiłeś to źle.
Dan Ray
0

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.

SnoopDougieDoug
źródło
3
Przepraszamy, ale absolutnie żaden przykładowy kod nigdy nie powinien mieszać zapytań mySQL z PHP. To po prostu robi to źle.
Raynos
1
I nieodpowiedzialnie.
Wyścigi lekkości z Moniką
-1 dla most tutorial code I have written has little or no error/exception checking..
yannis
Widzę punkt widzenia PO. Nieodpowiedzialne jest, gdy pracodawca zatrudnia faceta, który nie ma wiedzy na temat wstrzykiwania SQL i tym podobnych.
Raffael,
Myślę, że to podejście jest uzasadnione, jeśli w kodzie umieścisz komentarze mówiące „Nie używaj tego w produkcji!”. W ten sposób kopie / pastery nie mają wymówki.
Benjol,
-1

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?

Steve Rathbone
źródło
2
Ale kiedy uczysz języka, nadal powinieneś używać preferowanych interfejsów API w swoich przykładach. Jak zawsze używaj parametrycznej formy zapytań SQL, prawdopodobnie z przypisem „Nigdy nie myśl o użyciu interpolacji do budowania SQL. Wydaje się to trochę łatwiejsze, ale jest bardzo podatne na luki w zabezpieczeniach”.
Jan Hudec
Tak, dobre punkty. Przypisy byłyby dobrym przypomnieniem, dotyczy to również samouczków online. Z całą powagą byłoby wspaniale, gdyby autorzy książek we wszystkich językach mogli włączyć porady OWASP do tekstów dla początkujących. Nawet tylko jako odniesienie. Fundacja OWASP wykonuje dobrą robotę.
Steve Rathbone
@ indifferentDrum: Możesz nauczyć ludzi jeździć nogami - to nie znaczy, że to dobry pomysł.
Wyścigi lekkości z Moniką