#php
Вопрос:
У меня есть внутреннее веб-приложение на основе PHP, для которого я создал простую систему входа в систему, и я использую session_start() для инициализации объекта $_SESSION и проверки других страниц в веб-каталоге, был ли пользователь зарегистрирован или нет. Если нет, дайте стандарт 403, если так, загрузите страницу.
Теперь у нас есть настройка веб-страницы-это стандартная согласованная главная страница, на которой размещен логин и меню навигации для доступа к другим страницам. Основная часть этой главной страницы и все ее содержимое изменяются с помощью параметров POST/API, чтобы указать, какая страница должна отображаться, например: www.example.com/frontPage.php?page=someOtherWebpage
Он находится на frontPage.php страница, на которой я создаю сеанс и разрешаю пользователю войти в систему перед загрузкой соответствующего содержимого основной страницы. Отсюда между $_POST и $_SESSION я могу получить доступ к необходимой информации, чтобы решить, разрешен ли пользователю доступ к различным частям веб-каталога.
Теперь вот где я не уверен, правильно ли я это делаю. Для поддержания целостности безопасности на каждой отдельной веб-странице в корневом каталоге также есть функция session_start (), поэтому она может извлекать $_SESSION и проверять, является ли переменная, объявленная мной как «ЗАРЕГИСТРИРОВАННАЯ», истинной или ложной. Если ложь, 403 и т. Д. Это было сделано для того, чтобы человек, у которого нет логина, но который каким-то образом получает доступ или знает прямой URL-адрес некоторых из этих веб-страниц, не мог получить доступ к нему без входа в систему. Мне кажется, что это правильное решение, и на данный момент оно работает так, как будто я пытаюсь перейти непосредственно на любую страницу в моем веб-каталоге без входа в систему, я получаю 403. Возможно, есть лучший или более стандартизированный способ сделать это, и я, конечно, открыт для предложений, и более «стандартизированный» способ может стать решением моей проблемы, которую я, наконец, опишу.
Когда пользователь входит в систему, у нас нет точного времени, но где-то между 15-45 минутами он должен снова войти в систему. На frontPage.php Я попытался установить cookie_lifetime на день в секундах (86400), я также проверил свой файл php.ini на наличие этих настроек:
oci8.persistent_timeout — для разрешения постоянных подключений в режиме ожидания мы установили значение -1, чтобы указать навсегда
session.cookie_lifetime — конфигурация сервера по умолчанию для времени жизни файлов cookie в настоящее время установлена на 0, то есть до перезапуска браузера.
сессия.gc_maxlifetime — вывоз мусора максимальный срок, когда данные, хранящиеся является мусор и почистили (это там, где я ожидаю, что мне нужно внести изменения, но я не достаточно хорошо знаком с мусором чистки знать, как это взаимодействует с файлами cookie и их жизни) его в настоящее время установлена до 1440 минут или 24, так что это входит в ожидаемые сроки
Является ли gc_maxlifetime параметром конфигурации, который я хочу увеличить, чтобы предотвратить пинок кого-либо из-за бездействия? Или есть что-то изначально неправильное в том, как мы настраиваем наши сеансы? Или какая-то другая причина или вариант, которые я не рассматривал/о которых не знаю?
Если для кого-то важен ответ, мы используем LDAP для входа в систему, связываемся с нашим локальным рекламным сервером и проверяем группы пользователей, пропусков и объявлений.
Я ценю любые ответы, которые кто-либо может дать.
Спасибо.
Комментарии:
1. Однажды мы настроили скрипт AJAX на странице, где мы хотели, чтобы пользователи сохраняли свою сессию дольше. JS будет пинговать сервер так много раз каждые столько-то минут, удлиняя сеанс до пары часов, когда он находится на определенной странице. Все остальные, или когда они были на других страницах, соблюдали более короткий тайм-аут простоя.
2. Джаред, это неплохая мысль. Однако это заставляет меня задуматься о том, как сбор мусора и время ожидания «простоя» взаимодействуют друг с другом. Но я думаю, что самая большая проблема заключается в том, что, когда один из моих пользователей, который сидел на странице в течение X неактивного времени, затем переходит на вторую страницу в процессе тестирования, затем, когда он пытается проверить статус входа, нечего вытаскивать, потому что GC удалил его. Однако я не уверен, удаляет ли GC только данные, связанные с неактивными сеансами? Если сохранение активной сессии с помощью AJAX предотвращает GC, то это может сработать.
Ответ №1:
Обычно сеансы должны быть кратковременными (по умолчанию используется 30 минут). Проблема, с которой вы, как правило, сталкиваетесь при более длительном сроке службы сеанса, заключается в том, что они становятся уязвимыми для столкновений. Особенно на загруженном сервере с большим количеством сеансов. PHP не имеет защиты от коллизий сеансов. Эта проблема может быть использована с помощью простой DoS-атаки, скажем, путем скручивания любой страницы на вашем сайте, которая генерирует сеанс в цикле. Если они могут заполнить ваше хранилище сеансов достаточным количеством сеансов, они увеличивают вероятность столкновения и, таким образом, получения уже активного сеанса. PHP не будет проверять наличие случайно сгенерированного идентификатора сеанса. Таким образом, если session_start() произойдет сгенерировать тот же идентификатор сеанса, что и существующий, он вернет пользователю уже существующий идентификатор сеанса, тем самым предоставив ему доступ к этим данным сеанса.
Существует также возможность проблемы фиксации сеанса, при которой пользователь может получить сеанс, который не проверяет идемпотентные данные. Вы можете использовать session_create_id() , чтобы помочь предотвратить этот тип уязвимости в PHP 7.1.
функция session_create_id() используется для создания нового идентификатора сеанса для текущего сеанса. Он возвращает идентификатор сеанса без столкновений.
Если сеанс не активен, проверка на столкновение опущена.
Идентификатор сеанса создается в соответствии с настройками php.ini.
Важно использовать один и тот же идентификатор пользователя вашего веб-сервера для сценария задачи GC. В противном случае у вас могут возникнуть проблемы с разрешениями, особенно с обработчиком сохранения файлов.
Хотя никакой защиты от столкновений не предусмотрено. Просто смягчение последствий. Поэтому обычно идея состоит в том, чтобы держаться gc.max_lifetime на достаточно низком уровне и учитывать, что это также может повлиять на такие вещи, как DoS-атаки на проблему сборки мусора, которая в PHP довольно плоха в обработчике сохранения сеанса файла по умолчанию.
Комментарии:
1. Итак, в контексте смягчения (насколько это возможно) атак на наше веб-приложение, каков наилучший способ поддерживать сеансы активными дольше, чем обычные 30 минут, не создавая «слишком много» или «слишком жестких» уязвимостей? Контекст заключается в том, что мы часто запускаем тесты с этого сайта. Примерно каждые 45 минут или около того необходимо получать доступ к программе, чтобы взаимодействовать с указанными заданными тестами. Я бы предпочел, чтобы моим ребятам не приходилось входить в систему каждые 45 минут. Увеличение gc_max_lifetime делает это, но вы помогли мне понять, что мне, возможно, придется пересмотреть свое решение.
2. Что ж, если вы учитываете частоту столкновений хэша (проблема с днем рождения) и максимальное время жизни сеанса thr, вы найдете приятное место, основываясь на средней загрузке ваших серверов. Допустим, вы получаете в среднем 1 тыс. запросов в секунду. Если бы у вас были настройки сеанса php по умолчанию (32-битный хэш с 30-минутным gc.max_lifetime), то вероятность столкновения составляет примерно 1 из 100 тыс. Обычно это довольно безопасно для обычного веб — сайта. Но допустим, нагрузка увеличивается на порядок, а срок службы mac также увеличивается до 24 часов. Теперь внезапно ваша вероятность столкновения снижается до 1 из 250 req.
3. Таким образом, идея состоит в том, чтобы держаться как можно дальше от более длительного времени работы сеанса и меньших пространств энтропии (размер хэша, алгоритм хэширования, источник энтропии) по мере увеличения нагрузки.
4. Это невероятно полезный вклад, так что спасибо, что уделили мне время, Шериф. К счастью, это веб-приложение очень маленькое. Используется в основном только нашей инженерной лабораторией, и при этом менее чем 10 людьми. Он также недоступен за пределами нашей сети без преднамеренной проникающей работы.
5. Пожалуйста. Тогда вы должны быть в порядке с увеличением срока службы, просто постарайтесь не задерживаться на 24 часа, так как это обычно самое приятное.