PHP Lang
  1. PHP Lang
  3. Будет ли этот код работать с SQL-инъекцией?
Intereting Posts
Расширенный поиск Magento не возвращает результатов Почему ввод php: // может быть прочитан более одного раза, несмотря на то, что документация говорит иначе? HTTP-заголовки для jpg-файлов после mod_rewrite File_get_contents ($ url): не удалось открыть поток Получить URL-адрес вызывающей веб-страницы в PHP Google OAuth 2.0 возвращает 400 «Bad Request» даже с игровой площадки как создать Json в Php Символы UTF-8 в формате fwrite Кнопка входа в Facebook работает только при втором щелчке Сохранить значения флажка в Yii gridview pagination Установка PEAR на wampserver Обзор совокупного Google Rich Snippet – ошибка с просмотром счета Оптимизация запроса SELECT … UNION … с ORDER и LIMIT в таблице с 5M + строками PHPMailer «Не удалось получить доступ к файлу:» Включение файла javascript вне корня doc с использованием zend framework

Будет ли этот код работать с SQL-инъекцией?

Возможный дубликат:
PHP: полная чистая / безопасная функция

Я нашел этот фрагмент кода здесь: http://snipplr.com/view/12853/clean-variables-from-sql-injections/

Автор утверждает:

Эта небольшая функция помогает бороться с общей проблемой безопасности с SQL-инъекциями, она может дезинфицировать любую глобальную переменную, такую ​​как $ POST, $ GET, $ _SERVER и т. Д. И избегать опасных символов.

введите описание изображения здесь Безопасен ли этот код? 

function _clean($str){ return is_array($str) ? array_map('_clean', $str) : str_replace("\\", "\\\\" , htmlspecialchars((get_magic_quotes_gpc() ? stripslashes($str) : $str) , ENT_QUOTES)); } //usage call it somewhere in beginning of your script _clean($_POST); _clean($_GET); _clean($_REQUEST);// and so on..

Пожалуйста, просветите меня, безопасно ли это, потому что оно выглядит для меня присяжным.

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

Дубликат: PHP: конечная чистая / безопасная функция

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

Это отломило попытки глупо заменить и может быть довольно безопасным, но может также испортить ваши данные. Зачем изобретать колесо?

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

Это небезопасно (нет mysql_real_escape_string или mysql_real_escape_string ), что также не является оптимальным в производительности ( get_magic_quotes_gpc для каждой переменной).