Правила обеспечения безопасности веб-приложений

При разработке приложений уровня предприятия на 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 не всегда сразу завершает сессии.

• Администратор должен иметь возможность удаленно отключить пользователя от системы (это означает возможность удаления сессий, хранящихся в БД через графический интерфейс.

И это только защита приложений. Иногда нам помимо этого приходилось проходить аудит настроек операционной системы и базы данных.