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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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