PHP Lang
  1. PHP Lang
  3. Sql Защита от впрыска с помощью только str_replace
Intereting Posts
Предотвращение сценариев на стороне сервера, XSS Вызов функции контроллера в другом контроллере в CodeIgniter Скрыть текст «Корабль в другой адрес?» И флажок в Woocommerce checkout неожиданный «класс» (T_CLASS) только на удаленном (не на локальном) Многомерный массив из строки Широко распространенный сайт Zend_Form Каков «правильный» способ предоставления приложения Zend с помощью обработчика базы данных Пользовательское мобильное меню в Drupal 7 не может получить доступ к дочерним ссылкам Можно ли установить режим выборки PDO по умолчанию? strtotime result не имеет смысла, ошибка php? Symfony3: Fatal error: Class 'AppKernel' не найден. \ Bin \ console Солить мои хэши с PHP и MySQL Открытие файла CSV Inline в браузере, а не приглашение DL Получение внутреннего текста тегов HTML с использованием регулярных выражений Получение текущей даты, времени, дня в laravel

Sql Защита от впрыска с помощью только str_replace

Я изучаю SQL-инъекцию и пробовал в своем PHP-коде этот запрос: 

$condition = str_replace(["'","\\"],["\\'","\\\\"], @$_GET['q']); $query = "SELECT * FROM dummy_table WHERE dummy_column = '$condition'";

DB и таблица charset установлены в UTF8.

Я не могу ничего вводить, может кто-нибудь мне помочь?

EDIT: Как указывал GarethD, это сработало бы первым 'и чем \, разрешив инъекцию, как насчет этого str_replace? 

 $condition = str_replace(["\\","'"],["\\\\","\\'"], @$_GET['q']);

Этот изолированный пример неуязвим для инъекций.

Но вы должны понимать, что защита от SQL-инъекции – это не просто замена символа . И обстоятельства могут отличаться от тех, которые вы принимаете в данный момент как должное. Таким образом, ваш код станет уязвимым в долгосрочной перспективе из-за существенных недостатков этого метода :

  • замена символов – это только часть требуемого форматирования
  • эта конкретная замена может быть применена только к строкам, оставив другие части абсолютно незащищенными.
  • такая замена является внешней по отношению к выполнению запроса, означает, что она подвержена человеческой ошибке любого рода.
  • такая замена является по существу съемной мерой, означает, что ее можно перемещать слишком далеко от фактического выполнения запроса и в конечном итоге забыть.
  • этот вид ускорения склонен к кодированию атаки , что делает решение слишком ограниченным в использовании.

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

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

И SQL-инъекция – это не единственная проблема с этим подходом, это также ошибка использования, так как эта функция либо испортит ваши данные, если используется как воплощение поздних магических котировок , либо сделает ваш код раздутым, если использовать для форматирования каждого переменная справа в коде приложения.

Такие функции могут использоваться только для обработки заполнителя , но, конечно, не с помощью функции замены homebrewed, а в надлежащей функции, предоставляемой API базы данных.