Как предотвратить атаки инъекций кода в PHP?

 mysql_real_escape_string used when insert into database htmlentities() used when outputting data into webpage htmlspecialchars() used when?? strip_tags() used when ?? addslashes() used when ?? 

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 

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

если вы htmlentitiy / htmlspecialchar свой вывод, текст будет там как есть. если вы strip_tag, он просто удаляет теги и отображает их:

 pictures of kittens here 

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

addslashes

процитировать руководство по php:

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

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

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

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

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

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

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

htmlspecialchars () превращает &, ', ", <и> в формат сущности HTML (&," и т. д.)

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. 

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

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

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

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

Вы должны использовать различные механизмы экранирования для разных типов вывода, например SQL – mysql_real_escape_string () , HTML – htmlentities () или htmlspecialchars () , shell – escapeshellarg () . Это связано с тем, что символы, которые являются «опасными», различны для каждого из них – нет волшебного способа сделать какие-либо данные безопасными для любого выходного носителя.

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

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

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

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