В течение многих лет я сталкивался со сценариями, в которых некоторые (хотя и не все) уязвимости сами по себе не могли поставить под угрозу целостность системы, однако комбинация уязвимостей могла бы легко это сделать ( все уязвимости, очевидно, должны быть устранены). Есть небольшие вопросы / разъяснения, которые я ищу, хотя основной вопрос выделен жирным шрифтом в нижней части. Контекст этого вопроса касается обеспечения максимальной безопасности при одновременном рассмотрении производительности как важного вторичного фактора.
Я провел стресс-тестирование, и одному из инструментов удалось вывести эту ошибку:
session_start (): идентификатор сессии слишком длинный или содержит недопустимые символы, допустимые символы: a-z, A-Z, 0-9 и '-,'
Отлично, у меня есть три варианта:
- Запустите дорогостоящее регулярное выражение .
- Запустите также дорогую проверку базы данных на текущий IP, чтобы проверить, совпадает ли сохраненный сеанс.
- Убедитесь, что файл сеанса уже существует на сервере (например, с использованием таких вещей, как
ini_get('session.save_path')).
Чтобы избежать регулярных выражений и использования некоторой базовой логики и хронологического потока, пожалуйста, исправьте меня, если я что-то упускаю (это не сам вопрос):
- Если cookie не существует, тогда PHP выберет и установит имя для сеанса, отрицая необходимость initial для регулярного выражения.
- Как только cookie сеанса был отправлен клиенту, клиент отправляет cookie в заголовках , потенциально изменяя имя сеанса, и именно здесь начинается эта потенциальная начальная угроза.
- Полагаю, что PHP не может изначально генерировать битые / недопустимые имена сеансов, поэтому, если файл не существует, который соответствует cookie сеанса, то он либо просрочен, либо может считаться недопустимым, игнорируется и новый cookie сеанса генерироваться.
На этом этапе можно сделать предположение, хотя оно может и не пройти рецензирование: простая проверка, существует ли файл и имеет ли он длину строки , может быть минимальной требуемой проверкой. Однако я все еще рассматриваю следующие сценарии:
- Каковы известные уязвимости, которые могут прямо или косвенно позволить злоумышленнику получить доступ к созданию или изменению существующих файлов cookie сеансов в каталоге сессий PHP?
- Можем ли мы установить и проверить разрешения CHMOD для этого каталога, и это обходится дешевле, чем регулярное выражение?
- Какие связанные, хотя неизвестные факторы влияют на этот сценарий?
Теперь, если в другом месте на сервере есть уязвимость, которая каким-то образом разрешает доступ к каталогу сессий PHP, второстепенным вопросом будет то, какие разрешения CHMOD должен быть установлен для этого каталога сессий?
Какой самый дешевый подход для проверки правильности сеансовых cookie в PHP?
Некоторые люди могут не заботиться о «затратах» или броске другого запроса к базе данных или еще одного регулярного выражения, поскольку отношение в этих сценариях «достаточно быстрое», однако оно также не позволяет разработчику расширять свое понимание языка с которыми они работают. Мысли, пожалуйста?