Как предотвратить атаки внедрения кода в PHP?

Я немного сбит с толку, в PHP так много функций, и некоторые используют это, некоторые используют это. Некоторые люди используют: htmlspecialchars(), htmlentities(), strip_tags() так далее

Какой из них правильный и что вы, ребята, обычно используете?

Это правильно (посоветуйте мне лучше, если таковые имеются):

$var = mysql_real_escape_string(htmlentities($_POST['username']));

Эта строка может предотвратить инъекцию MySQL и атаку XSS??

Кстати, есть ли еще что-то, на что мне нужно обратить внимание, кроме XSS-атаки и MySQL-инъекции?

РЕДАКТИРОВАТЬ

Заключить:

Если я хочу вставить строку в базу данных, мне не нужно использовать htmlentitiesПросто используйте mysql_real_escape_string, При отображении данных используйте htmlentities()Это то, что вы все имеете в виду??

Суммировать:

  • mysql_real_escape_string используется при вставке в базу данных
  • htmlentities() используется при выводе данных на веб-страницу
  • htmlspecialchars() использовал когда?
  • strip_tags() использовал когда?
  • addslashes() использовал когда?

Может кто-нибудь заполнить вопросительный знак?

Источник

8 ответов

Решение
  • mysql_real_escape_string используется при вставке в базу данных
  • htmlentities() используется при выводе данных на веб-страницу
  • htmlspecialchars() использовал когда?
  • strip_tags() использовал когда?
  • addslashes() использовал когда?

htmlspecialchars () используется когда?

htmlspecialchars примерно так же, как htmlentities, Разница: кодировка символов.

Оба кодируют управляющие символы, такие как <, >, & и т. д. используется для открытия тегов и т. д. htmlentities также кодировать символы из других языков, таких как умлауты, евро-символы и тому подобное. Если ваши сайты UTF, используйте htmlspecialchars()иначе используйте htmlentities(),

strip_tags() используется когда?

htmlspecialchars / entities закодируйте специальные символы, чтобы они отображались, но не интерпретировались. strip_tags УДАЛЯЕТ их.

На практике это зависит от того, что вам нужно сделать.

Пример: вы запрограммировали форум и дали пользователям текстовое поле, чтобы они могли публиковать материалы. Злонамеренные просто попробуйте:

pictures of <a href="javascript:void(window.setInterval(function () {window.open('http://evil.com');}, 1000));">kittens</a> here

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

Если вы выводите htmlentity/htmlspecialchar, текст будет там как есть. Если вы его удалите, он просто удалит теги и отобразит его:

pictures of kittens here

Иногда вам может понадобиться смесь, оставьте там несколько тегов, например <b> (strip_tags можете оставить там определенные теги). Это тоже небезопасно, поэтому лучше использовать какую-то полноценную библиотеку против XSS.

addslashes

Процитируем старую версию руководства по PHP:

Возвращает строку с обратной косой чертой перед символами, которые должны быть заключены в кавычки в запросах к базе данных и т. Д. Это символы одинарных кавычек ('), двойных кавычек ("), обратного слеша () и NUL (байт NULL).

Пример использования addlashes() - это когда вы вводите данные в базу данных. Например, чтобы вставить имя O′reilly в базу данных, вам нужно его избежать. Настоятельно рекомендуется использовать специальную функцию escape СУБД (например, mysqli_real_escape_string() для MySQL или pg_escape_string() для PostgreSQL), но если используемая вами СУБД не имеет функции escape и СУБД использует \ для экранирования специальных символов, вы можете использовать эту функцию.

Текущая версия сформулирована иначе.

Источник

Я думал об этом быстром контрольном списке:

  • Всегда используйте HTTPS, без HTTPS ваш сайт полностью незашифрован. И нет, шифрование и отправка на стороне клиента не будет работать, подумайте об этом. Неверные сертификаты HTTPS также делают вас уязвимыми для атаки MITM. Просто используйте Let's Encrypt, если вы не можете позволить себе сертификат.
  • Всегда используйте htmlspecialchars() на любой вывод из вашего кода PHP, то есть, или содержит ввод пользователя. Большинство шаблонных движков помогут вам сделать это легко.
  • Используйте флаг HTTP только в вашем php.ini чтобы скрипты не могли получить доступ к вашим куки
  • Предотвращение проблем, связанных с сеансом
    • Никогда не подвергайте пользователя PHPSESSID (идентификатор сеанса) вне файла cookie, если кто-либо узнает идентификатор сеанса другого пользователя, он может просто использовать его для входа в свою учетную запись
    • Будьте очень осторожны с Remember me функция, может показывать небольшое предупреждение
    • Обновить идентификатор сеанса, когда пользователь входит в систему (или любой другой подходящий)
    • Тайм-аут неактивных сеансов
  • Никогда не доверяйте куки, он может быть изменен, удален, изменен и создан скриптом / пользователем в любой момент
  • Предотвращение проблем, связанных с SQL
    • Всегда используйте готовые заявления. Подготовленные операторы приводят к тому, что пользовательский ввод передается отдельно, и предотвращает внедрение SQL
    • Сделайте так, чтобы ваш код выдавал исключение, когда он не работает. Иногда ваш SQL-сервер может по какой-то причине не работать PDO по умолчанию игнорируйте эту ошибку и внесите предупреждение в журналы. Это приводит к тому, что переменные, которые вы получаете из БД, будут нулевыми, в зависимости от вашего кода, это может вызвать проблему безопасности.
    • Некоторые библиотеки, такие как PDO подражать готовым заявлениям. Выключи это.
    • использование UTF-8 кодирование в ваших базах данных, оно позволяет хранить практически любой символ и избежать атак, связанных с кодированием
    • Никогда ничего не объединяйте по вашему запросу. Вещи как $myquery = "INSERT INTO mydb.mytable (title) VALUES(" . $user_input . ")" в значительной степени означает, что у вас огромный риск безопасности при внедрении SQL-кода.
  • Сохраняйте загруженные файлы в случайных файлах без расширений. Если пользователь загружает файл с .php расширение файла, тогда всякий раз, когда ваш код загружает этот файл, он выполняет его и позволяет пользователю выполнить некоторый внутренний код
  • Убедитесь, что вы не уязвимы для атаки CSRF.
  • Всегда обновляйте свою копию PHP, чтобы обеспечить последние обновления для системы безопасности и улучшения производительности
Источник

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

Для SQL-инъекций - используйте связанные переменные, как описано в разделе Как предотвратить SQL-инъекцию в PHP? (речь идет о готовых заявлениях, но это защита, которая дает вам защиту, а не подготовка).

Для XSS - если вы пишете в HTML в точке, где указан либо HTML, либо текст. Используйте htmlentities в том месте, где вы генерируете документ. Я бы не стал хранить данные в таком виде в базе данных (кроме случаев, когда это возможно в системе с редкой записью и частым чтением, где производительность процессора / время доступа к диску становились и возникали), тогда у меня была бы версия столбца raw_ и html_... или просто использовать memcached или подобное).

Если вы разрешаете пользователям вводить URL-адреса, вам нужно быть более осторожным, так как javascript:do_evil() является допустимым URI, который будет выполняться (например, как href для ссылки, на которую нажимают, или (в некоторых браузерах) src только что загруженного изображения).

Источник

htmlspecialchars() витки &, ', ", <, а также > в формат сущности HTML (&amp;, &quot;, так далее.)

htmlentities() превращает все применимые символы в их формат сущности HTML.

strip_tags() удаляет все теги HTML и PHP.

И то и другое htmlspecialchars() а также htmlentities() принять необязательный параметр, указывающий, как кавычки должны быть обработаны. Смотрите руководство PHP для деталей.

strip_tags() Функция принимает необязательный параметр, указывающий, какие теги не следует удалять.

 $var = strip_tags ($var, '<p><br />');

strip_tags() Функция удалит даже недействительные теги HTML, что может вызвать проблемы. Например, strip_tags() вытянет весь код, который он считает HTML-тегом, даже если он неправильно сформирован, например

<b I forgot to close the tag.
Источник

Вам нужно использовать только mysql_escape_string() при вставке в базу данных и htmlentites при отображении HTML. Этого достаточно, если вы хотите предотвратить простую атаку с использованием инъекций, но, без сомнения, существует множество других проблем безопасности, о которых вам следует знать при разработке веб-приложения, еще одной важной из которых являются подделки межсайтовых запросов.

Источник

Я бы не использовал htmlentities() при вставке данных в базу данных или запросе базы данных. Если данные в вашей базе данных хранятся в виде сущностей, тогда эти данные полезны только для чего-то, что понимает HTML-сущности.

Вы должны использовать различные механизмы экранирования для разных типов вывода, например, SQL - http://php.net/mysql_real_escape_string, HTML - http://php.net/htmlentities или http://php.net/htmlspecialchars, shell - http://php.net/escapeshellarg. Это потому, что "опасные" символы различны для каждого из них - не существует волшебного способа, которым вы можете сделать любые данные безопасными для любого носителя вывода.

Источник

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

По состоянию на 2017

  1. Вы никогда не должны использовать mysql_real_escape_string. Даже mysqli_real_escape_string слишком слаб, чтобы защитить вашу базу данных от SQL-инъекций. Вместо этого вы должны использовать PDO и аналогичные методы. (см. это руководство)

  2. XSS (здесь я имею в виду: strip_tags(), addslashes(), htmlspecialchars(), htmlentities()) - здесь наиболее проголосовавший ответ по-прежнему правильный, но я бы предложил прочитать эту статью

Источник

Взгляните на этот сайт PHP Security Consortium. Я нашел, что это хороший сайт для общего обзора безопасности PHP (SQL Injection и XSS включены).

Источник
Другие вопросы по тегам