Почему защита от SQL-инъекций не является приоритетом?

39

Что касается переполнения стека, я вижу много PHP-кода в вопросах и ответах, в которых есть запросы MySQL, которые очень уязвимы для атак SQL-инъекций, несмотря на то, что основные обходные пути широко доступны уже более десяти лет.

Есть ли причина, по которой эти типы фрагментов кода все еще используются сегодня?

Гонки легкости с Моникой
источник
37
вините в этом плохо написанные онлайн-уроки. чаще всего люди просто копируют и вставляют любой код, который они находят в сети. JavaScript также является еще одной жертвой такой практики.
KJYe.Name
34
Виноваты блоги. Ох, и W3Schools ...
Брайан Дрисколл
13
Да, абсолютно W3Schools - см. W3fools.com
DisgruntledGoat
2
Я постоянно вижу людей, предупреждающих об инъекции sql - поэтому я даже не думаю, что предпосылка этого вопроса верна. Это является первоочередной задачей.
GrandmasterB
3
Что я вижу во многих ответах, так это то, что легче научить критически сломанному PHP, чем научить, ну, в общем, PHP, который не является критически сломанным. Вы не можете принять этот аргумент и все еще утверждать, что PHP не плохой язык
user16764

Ответы:

34

Я думаю, что это в основном из-за а) невежества б) лени. Новички обычно мало что знают о внедрении SQL, и даже когда они слышат об этом, они игнорируют это, потому что так проще и проще кодировать таким образом.

froadie
источник
8
Я пытался исправить такие вещи в другом месте, но мне сказали, что это не имеет отношения к рассматриваемой проблеме. Так как многие люди предпочитают простой взлом чуть более сложному хорошему решению, плохие примеры остаются одни.
10
6
Большинство людей на самом деле не заботятся о внедрении SQL до тех пор, пока их не ударит. И вдруг им стало интересно, куда делись их столы.
Джоэл Этертон
1
Другая причина заключается в том, что внедрение SQL не всегда рассматривается как актуальная проблема для внутренних приложений. (Не то чтобы они правы.)
Джон Фишер
1
Не забывайте, что Ответы там, чтобы ответить на вопрос. Зачастую именно псевдокод (или SQL) предназначен для ответа на вопрос, а не для обеспечения безопасного и надежного решения для копирования и вставки (несмотря на то, как ответ может быть использован в реальности).
Далин Сейврайт
1
@ l0b0 Я знаю человека, который заставлял людей серьезно относиться к исправлениям SQL-инъекций, фактически демонстрируя атаки SQL-инъекций на текущий производственный код.
user16764
26

PHP намеренно делает очень, очень легко для людей, которые очень мало знают, для создания полезных динамических веб-страниц. Это означает, что PHP привлечет много новичков, которые создают что-то полезное, учатся на других полезных примерах и поворачиваются, чтобы научить других, как делать эту классную, полезную вещь. В результате получается много плохого кода и множество программистов, которые не знают ничего лучшего.

Хуже всего то, что большая часть компетентных программистов не хочет иметь ничего общего с PHP. Это уменьшает базу опытных людей, которые готовы учить других лучше. Но почему они избегают PHP? Хорошо для комбинации факторов. Частично им не нравится иметь дело с языковыми бородавками. И отчасти это потому, что они предпочли бы работать с хорошим кодом, а хорошего PHP там не так много.

Это точное созвездие проблем, используемых для Perl. В качестве яркого примера рассмотрим случай с Мэттом Райтом, увлеченным подростком, который намеревался предоставить много полезных, хорошо документированных и простых в установке сценариев CGI еще в 1990-х годах. К сожалению, он ничего не понимал в безопасности, как и люди, которые хотели использовать его вещи. Результатом стал архив сценариев Мэтта Райта, который представлял собой бесконечный поток проблем безопасности для ранних сценариев CGI. Несмотря на такие усилия, как http://www.scriptarchive.com/nms.html , проблема не улучшилась для Perl, пока провайдеры виртуального хостинга не сделали PHP более удобным, чем что-либо еще. Это приводит к проблеме перехода с Perl на PHP.

btilly
источник
Как вы сказали, проблема не в Perl или PHP, а в том, что эти языки позволяют новичкам делать много вещей, и это хорошо, но не всегда предоставляют способы сделать их хорошо, что так же очевидно.
Захари К
2
@ZacharyK: Разве это не ошибка языка по умолчанию?
Легкость гонок с Моникой
6
@ tomalak-geretkal: Вы используете слово «вина», как будто плохая вещь - это возможность сделать что-либо. Те же характеристики, которые приводят к большому количеству плохого кода, также приводят к решению многих реальных проблем. Не понятно, что это в целом плохо.
Btilly
«Ошибка»: если бы HTML (или, скорее, браузеры, его интерпретирующие) был бы таким же отказоустойчивым, как XSL, не было бы всемирной паутины ...
Бенджол
8

К сожалению, существуют тонны более чем плохих учебников по PHP, и некоторые старые книги по PHP также потрясены тем, что говорят людям писать правильный код (без использования register_globals и т. Д.).

Кроме того, с magic_quotes_gpcвозможностью включения в прошлом, люди не заботились о побеге, потому что «это просто работало».

ThiefMaster
источник
4

Лично я считаю, что PHP прост в использовании, поэтому его легко использовать неправильно.

davidhaskins
источник
2

Будучи человеком и программистом, я нахожу удивительно легким делать ошибки и упускать из виду определенные вещи, особенно когда время ограничено.

Легко и, возможно, слишком заманчиво обвинить определенный язык в том, что он слишком доступен для его же блага. Но это могло бы затушевывать большую проблему человеческих ошибок, независимо от языка, выбранного для программирования.

Конечно, мы прошли долгий путь с языка ассемблера, и я думаю, что я буду гораздо более продуктивным программированием на более современном языке, таком как PHP, Python, Ruby или Java.

PHP (и другие скриптовые языки) фактически снизили барьер для входа. Это может означать, что все больше новичков в программировании сначала пробуют PHP. Но это, конечно, также не означает, что все программисты на PHP как-то менее квалифицированы или менее способны учиться на своих ошибках, чем программисты на других языках.

Расмус Лердорф создал PHP в его первоначальном виде еще в 1994 году, с тех пор он значительно развился. В своем самом современном воплощении он поддерживает объектно-ориентированное программирование, а также превосходные фреймворки, такие как Symfony. PHP как язык освободился от своих первоначальных ограничений и стал более гибким в плане того, как программисты могут использовать его. Вы можете использовать его для создания сценария спагетти из 9 000 строк или использовать его в контексте современной среды MVC, такой как Symfony: это ваш выбор!

Я сильно подозреваю, что уязвимости безопасности не ограничиваются одним языком. Соблазнительно списывать всех программистов PHP как-то менее способных или более склонных к написанию небезопасного кода. Но мне интересно, сколько из этого является языковой уклон, и сколько это факт?

Джей Шет
источник
Я ничего не говорил о "всех программистах PHP".
Легкость гонок с Моникой
2

Я думаю, что частью проблемы являются люди, которые просто копируют код, не удосужившись узнать, что они делают, но на самом деле, на мой взгляд, способ обучения porgamnming нарушен, и это одна из причин, почему существует так много плохого кода. Мы учим синтаксис вне контекста, и поэтому новички не знают, когда что-то использовать, а когда нет или какие проблемы синтаксис предназначен для решения и какие проблемы он не предназначен для решения. Поэтому они используют молоток, когда гаечный ключ был бы лучшим инструментом.

Так, например, вместо того, чтобы учить только синтаксису, вы организуете курс следующим образом (очевидно, что было бы больше шагов, это просто базовый пример перехода от базовых к более сложным задачам, а не просто обучения синтаксису):

  1. Вот как вы настраиваете основную веб-страницу
  2. Вот как вы заставляете веб-страницу извлекать данные из базы данных.
  3. Так вы отправляете данные с веб-страницы в базу данных
  4. Это как вы убедитесь, что правильные данные отправляются.
  5. Вот как вы защищаете свою базу данных от злонамеренного ввода данных
HLGEM
источник
это более или менее так, как меня учили php +1
Rémi
1

Я думаю, вы найдете такое же количество примеров MS SQL + ASP / ASP.NET, которые столь же уязвимы.

Я чувствую, что проблема частично связана с тем фактом, что когда вы пытаетесь чему-то научить, скажем, фильтровать данные с помощью предложения WHERE, вы действительно не хотите загромождать свой пример, правильно экранируя строку запроса или используя параметризованную команду.

Я обучаю разработчиков много лет, и я могу сочувствовать людям, которые пишут ужасный код в учебниках. Иногда это наиболее легко понять. Тем не менее, в стороне я всегда указываю на уязвимый код и превращаю его в интересную дополнительную тему.

Fung
источник
6
Это не должно быть в стороне. Это должно быть частью основного урока. Возможно, с большим, толстым, предупреждением о неправильном способе делать вещи. Люди склонны вырезать и вставлять то, что они впервые видят, и вы действительно хотите, чтобы это был правильный способ сделать что-то.
btilly
Конечно, в мире .NET параметризация довольно проста в наши дни и действительно должна быть «первой страницей».
Алан Б
1

Первоначальный автор PHP, Расмус Лердорф , в своей печально известной записи в блоге выступает за разработку «без фреймворка» . Хотя для SQL-запросов он использует PDO, поэтому нет риска внедрения SQL-кода. Все еще довольно некрасиво и устарело по сравнению с современными средами MVC со слоями ORM.

Vartec
источник
5
Безусловно, возможно чрезмерное проектирование сайтов со сложными фреймворками, которые вам просто не нужны. Я бы сказал, что предложения Расмуса граничат с преступной опасностью, но определенно есть здравый смысл.
Легкость гонок с Моникой
в настоящее время использование ORM не слишком сложное; это стандартно. Таким образом, используется шаблон MVC.
vartec
3
@vartec: Это вряд ли «стандарт» только потому , что все овцы используют его (и, для чего это стоит, даже не все овцы являются его использованием). Для небольших скриптов он может легко быть более-инжиниринг.
Легкость гонки с Моникой
1
@ Томалак: это стандарт, потому что это способ реализации чистых и устойчивых проектов. «маленькие сценарии» имеют тенденцию расти со временем и превращаться в неосуществимые чудовища.
vartec
2
@vartec: Я думаю, вы неправильно поняли значение «стандарт».
Гонки на легкость с Моникой
1

Вы можете обвинить эту плохую практику на самом PHP. Устаревшие версии PHP (вплоть до 2006 года) избегали всех входных переменных GET и POST, чтобы они были пригодны для интерполяции запросов к базе данных BY DEFAULT. Смотрите http://php.net/manual/en/security.magicquotes.php

Бен Хо
источник
2
Было время, когда он избегал ВСЕХ переменных, как если бы они входили в MySQL специально, независимо от того, были ли они когда-либо или нет . Примечание для языковых дизайнеров: когда вы сталкиваетесь с необходимостью реализации stripslashes(), вы уже сделали это неправильно.
Дэн Рэй
0

Не путайте цель учебника, который заключается в простой демонстрации того, что должно быть сделано в производственной среде. Например, в большинстве написанного мною учебного кода практически отсутствует проверка ошибок / исключений. Я пытаюсь напомнить читателю, что код только демонстрирует, как выполнить конкретную задачу, а не как охватить все возможные результаты.

SnoopDougieDoug
источник
3
Извините, но ни один пример кода не должен смешивать запросы MySQL с PHP. Это просто делает это неправильно.
Райнос
1
И безответственно.
Легкость гонки с Моникой
-1 за most tutorial code I have written has little or no error/exception checking..
Яннис
Я вижу точку зрения ОП. Безответственно, когда работодатель нанимает парня, которому не хватает знаний об SQL-инъекциях и тому подобном.
Рафаэль
Я думаю, что этот подход оправдан, если вы включите комментарии прямо в коде, говоря: «Не используйте это в производстве!». Таким образом, копии / пастеры не имеют оправдания.
Бенджол
-1

Когда я изучал PHP, я посмотрел некоторые из этих книг по PHP + MySQL, и да, я чувствую, что это способствует этой плохой практике. Но я сочувствую, потому что они преподают язык , а не хорошие практики программирования. Иначе чем это кончится?

Стив Рэтбоун
источник
2
Но когда вы учите язык, вы все равно должны использовать предпочтительные API в своих примерах. Как и всегда, используйте параметрическую форму SQL-запросов, возможно, со сноской типа «Никогда не думайте об использовании интерполяции вместо построения SQL. Это кажется немного проще, но оно чрезвычайно подвержено уязвимостям безопасности».
Ян Худек
Да, хорошие моменты. Сноски были бы хорошим напоминанием, и это касается и онлайн-уроков. На самом деле, было бы здорово, если бы авторы книг на всех языках могли включить рекомендации OWASP в тексты для начинающих. Даже просто для справки. Фонд OWASP делает хорошую работу.
Стив Рэтбоун
@indifferentDrum: Вы также можете научить людей водить ногами - это не значит, что это хорошая идея.
Легкость гонок с Моникой