Я изучаю PHP самостоятельно, и мне стало известно о функции strip_tags (). Это единственный способ повысить безопасность?

Question

Я новичок в PHP и следую учебному пособию здесь: Ссылка

Довольно страшно, что пользователь может написать php-код на входе и, по сути, прокрутить свой сайт, верно?

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

Так как я новичок в PHP (буквально взял его два дня назад), я могу выучить практически все, что угодно, даже не запутавшись.

Как еще можно предотвратить махинации на моем сайте? : D

Answer 1

Есть несколько вещей, которые следует учитывать при разработке приложения PHP, strip_tags() помогает только в одном из них. На самом деле strip_tags(), хотя и эффективен, может даже сделать больше, чем нужно: преобразование потенциально опасных символов с htmlspecialchars() должно быть даже предпочтительнее, в зависимости от ситуации.

Как правило, все сводится к двум простым правилам: фильтровать весь ввод, экранировать весь вывод. Теперь вам необходимо понять, что именно представляет собой ввод и вывод.

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

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

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

Особое внимание, если вы имеете дело с базой данных, должно быть уделено инъекциям SQL: этот тип атаки основан на том, что вы неправильно строите строки запросов, которые отправляете в базу данных, чтобы злоумышленник мог подделать их, пытаясь выполнить вредоносную инструкцию , Вы всегда должны использовать экранирующую функцию, такую ​​как mysql_real_escape_string() или, лучше, использовать подготовленные операторы с расширением mysqli или PDO .

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

НТН

РЕДАКТИРОВАТЬ : чтобы уточнить, под «фильтрацией входных данных» я имею в виду решить, что хорошо, а что плохо, а не изменять входные данные каким-либо образом. Как я уже сказал, я никогда не буду изменять пользовательские данные, если они не выводятся в браузер.

Answer 2

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

Важно отметить, что вы никогда не хотите напрямую работать со значениями $ _GET & $ _POST. Всегда отправляйте их значение локальной переменной и работайте с ней там. Существует несколько последствий для безопасности, связанных со значениями при прямом доступе (или вывод) $ _GET & $ _POST.

Это чепуха. Копирование значения в локальную переменную не более безопасно, чем прямое использование переменных $ _GET или $ _POST.

На самом деле, нет ничего небезопасного в каких-либо данных. Что важно, что вы делаете с ним . Существуют вполне законные причины, по которым у вас может быть переменная $ _POST, которая содержит ; rm -rf /. Это хорошо для вывода на страницу HTML или хранения в базе данных, например.

Единственный случай, когда это небезопасно, это когда вы используете команду типа system или exec. И это время, когда вам нужно беспокоиться о том, какие переменные вы используете. В этом случае вы, вероятно, захотите использовать что-то вроде белого списка или, по крайней мере, пропустите свои значения через escapeshellarg.

Аналогично отправке запросов в базы данных, отправке HTML в браузеры и т. Д. Экранируйте данные прямо перед отправкой в ​​другое место, используя соответствующий метод экранирования для пункта назначения.

Answer 3

strip_tags - не самая лучшая вещь для использования, она не защищает во всех случаях.

HTML Purify: http://htmlpurifier.org/

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

Answer 4

Ну, наверное, я не прав, но ... Во всей литературе, которую я читал, люди говорят, что гораздо лучше использовать htmlspellchars.

Кроме того, весьма необходимо для приведения входных данных. (например, для int, если вы уверены, что это идентификатор пользователя).

Хорошо, заранее, когда вы начнете использовать базу данных - используйте mysql_real_escape_string вместо mysql_escape_string для предотвращения SQL-инъекций (в некоторых старых книгах написано еще mysql_escape_string).

Answer 5

strip_tags удаляет каждый кусок HTML. более сложные решения основаны на белых списках (т. е. допускаются определенные HTML-теги). хорошая библиотека белого списка htmlpurifyer http://htmlpurifier.org/

и, конечно, на стороне базы данных используются такие функции, как mysql_real_escape_string или pg_escape_string