Правила обеспечения безопасности веб-приложений
При разработке приложений уровня предприятия на PHP, самой болезненной, на мой взгляд, темой является аудит безопасности. По моему опыту, сложнее всего соответствовать требованиям к безопасности, применяемым в финансовых организациях.
Эти требования в целом практически одинаковые, но пройти наш первый аудит было непросто. Вот пример того, что от нас требовалось:
-
У каждой важной задачи должен быть четко обозначен исполнитель и проверяющий. Проще говоря, если я(исполнитель) делаю важный запрос, кто-то(проверяющий) должен проверить запрос и разрешить его выполнение.
-
Для каждой транзакции должна храниться история, включающая уникальный ID транзакции, участников транзакции, данные которые изменились (до и после транзакции) и время модификации данных.
-
Все используемые в PHP/ASP приложениях пароли к базам данных должны быть зашифрованы.
-
Если приложение "смотрит" в интернет, должна использоваться программа Tripwire для отслеживания изменившихся файлов.
-
Соединение с БД (и расшифровка паролей) должно происходить через DLL или скомпилированный скрипт.
-
Пароль не должен храниться в скомпилированном коде как текстовая строка. Он должен быть скрыт или разбит на несколько частей.
-
Пользователи должны сменить пароль при первом заходе в систему
-
Все пароли к БД должны быть зашифрованы любимым алгоритмом заказчика (напр. SHA-1, 3DES, AES, и т.д.)
-
Все пароли пользователей должны быть зашифрованы любимым алгоритмом заказчика (напр. SHA-1, 3DES, AES, и т.д.)
-
Учетные записи пользователей блокируются после n неудачных попыток захода. Исключение делается только для главной учетной записи администратора.
-
Администратор может запретить пользователям вход в систему.
-
Все критически важные пароли от наиболее важных учетных записей должны быть разделены и находиться у 2-х людей.
-
Все пароли должны содержать буквы и цифры, минимальная длинна пароля должна быть регулируемой.
-
Пользователи должны менять пароли каждые n дней, чаще всего каждые 30-90.
-
Пароли нельзя использовать повторно в течении n смен паролей. Самые высокие требования к количеству последовательно уникальных паролей которые я видел - 24.
-
Пароли не должны начинаться с n первых символов имени пользователя.
-
Идентификатор сессии должен меняться при каждом заходе пользователя (используйте regenerate_session_id()). Аудиторы могут проверить этот и следующий пункт при помощи прокси-сервера.
-
В cookie не должна храниться важная информация - только id сессии и ей подобные незначительные данные.
-
Тестируются cross-site scripting - атаки. Аудиторы для проверки вводили <script>alert('attack')</script> в наши поля ввода.
-
В системе должны иметься отчеты "Пользователи, неактивные n дней", "Неудачные попытки входа в систему", "Матрица доступа пользователей".
-
Производится аудит прав доступа к файлам и избыточный доступ лимитируется.
-
Никакие сервисы и задачи не должны запускаться с правами суперпользователя.
-
Время окончания сессий можно изменить, и браузер должен отключать пользователя по завершении этого времени. Это делается при помощи Javascript так как PHP не всегда сразу завершает сессии.
-
Администратор должен иметь возможность удаленно отключить пользователя от системы (это означает возможность удаления сессий, хранящихся в БД через графический интерфейс.
И это только защита приложений. Иногда нам помимо этого приходилось проходить аудит настроек операционной системы и базы данных.
