Какие соображения безопасности необходимо сделать для php Cms?

Question

Создать Cms просто, вы просто сохраняете свой контент в базе данных и предоставляете способ редактировать этот контент через саму веб-страницу.Правильно?

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

1. Содержание может быть изменено только вошедшим в систему пользователем.
2. Пользователю с данными для входа будет доверено не вставлять неверные данные.
3. Теги HTML не допускаются при вводе пользователем и удаляются перед использованием ввода.
4. Вместо использования HTML будет использоваться автономный набор кодов.Например, [b] текст выделен жирным шрифтом [/ b]

Answer 1

html-теги должны быть удалены или заменены html-объектами перед печатью для вывода, а не обязательно перед помещением в базу данных. Многие программы сохраняют редактируемые данные и предварительно отформатированные данные для повышения производительности. например, если кто-то помещает (я знаю, я знаю) bb-коды в форму, вы хотите сохранить одну версию, когда пользователь ввел ее, и одну версию, которая проанализировала bb-код и очистил html. Удаление html из содержимого выполняется только для того, чтобы пользователи не могли размещать вредоносный JavaScript-код на своей странице, предоставляя им доступ к информации или изменяя систему без учетных данных. см. xxs или межсайтовый скриптинг.

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

хитроумно убедиться, что запрос идет от предполагаемого вошедшего в систему пользователя. например, если вы вошли на сайт своего банка, и я отправил вам электронное письмо с тегом изображения <img src="www.yourbank.com?func=transfer&account=1234&amount=10000" />. Вы заставите меня перевести свои деньги? не допускайте запросов, которые изменяют системные данные из GET для начинающих, но это может происходить через сообщения, если задействованы JavaScript или вирусы. люди также часто сохраняют идентификатор экземпляра формы с каждой формой, которую они отправляют вошедшему в систему пользователю в сеансе, а также в самой форме. Затем они проверяли поступающие запросы по этому списку экземпляров форм, игнорируя те, которые он сам не отправлял. см. csrf или xsrf.

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

очистить все загрузки файлов. если кто-то загрузит файл с именем some.jpg.php, который является допустимым jpg, но содержит PHP-код, содержащий мета-примечания jpgs. загрузчик может реально захватить ваш сервер. по крайней мере, обязательно используйте свои собственные расширения файлов для загружаемых файлов. некоторые даже предлагают хранить все загруженные файлы в приватном месте, а затем настраивать сценарий файлового сервера для обслуживания этих файлов с помощью PHP. некоторые даже предлагают сканировать загруженные файлы на наличие вирусов. проверка типа MIME не защищена.

убедитесь, что настройки PHP и сервера настроены с учетом передового опыта.

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

Answer 2

1. Конечно.
2. Пользователь должен никогда не быть доверенным.Войти в систему или нет.
3. Нет необходимости удалять теги HTML, просто закодируйте введенные пользователем данные в объекты HTML, чтобы они не искажали фактический HTML.Данные от пользователя должны никогда быть доверенными.
4. Вы можете использовать уценку.Данные от пользователя должны никогда не быть доверенными.

Я упоминал, что не доверял пользователям?

Answer 3

В сочетании с SpiceMan,

Также проверяйте свои пользовательские входы, пользователь или кто-то другой, или бот. Под проверкой я подразумеваю пробежать и убедиться, что нет кода, способного к инъекции, который пытается обмануть вашу безопасность. Также убедитесь, что входные данные всегда находятся в пределах того, что вы хотите, чтобы они были. Например, вы хотите двойную проверку почтового индекса, прежде чем делать что-либо еще, чтобы увидеть, является ли введенное значение на самом деле числовым. Не полагайтесь на JavaScript для обработки вашей проверки. Если вы это сделаете, сделайте то же самое с вашим PHP на бэкэнде. Веб-форма не является единственным способом размещения вашей формы в БД. Если это там, и кто-то хочет, они найдут способ сделать это. Единственное, что вы действительно можете сделать, так это затруднить им доступ. В надежде, что они обойдут стороной.