Каковы последствия использования «низкой» безопасности в CakePHP? - PullRequest
7 голосов
/ 23 декабря 2009

У меня была проблема с аутентификацией в cakephp, когда при регистрации учетных данных с внешнего сайта аутентификация работала, а затем сразу терялась, а сайт снова запрашивал информацию для входа.

Этот парень определил, что сессия cookie CakePHP изменялась. Его решение состояло в том, чтобы установить низкий уровень безопасности.

Похоже, что при средней или высокой безопасности Cake делает двойную проверку для реферер ... но с низким уровнем безопасности отлично работает при нажатии на аутентификацию защищенные ссылки с внешних сайтов, таких как hotmail или yahoo

Это решение также сработало для меня, но что я теряю, устанавливая для CakePHP «низкий» уровень безопасности?

Ответы [ 4 ]

7 голосов
/ 24 декабря 2009

При высоком уровне безопасности новый идентификатор сеанса генерируется при каждом запросе. В этом случае практически невозможно создать решение с единым входом для двух приложений путем совместного использования файла cookie сеанса, поскольку Cake будет постоянно менять идентификатор сеанса без уведомления другого приложения.

Когда уровень безопасности средний (или выше), session.referer_check включен.

Когда безопасность низкая, у вас нет ни одной из перечисленных выше функций, но она по-прежнему так же безопасна, как и любой обычный веб-сайт / CMS PHP.

2 голосов
/ 23 декабря 2009

Главное, что я знаю, это тайм-аут сеанса, согласно комментариям app / config / core.php, в котором тайм-аут сеанса будет умножен на меньшее число.

Книга подтверждает это,

Уровень безопасности CakePHP. Время ожидания сеанса, определенное в «Session.timeout», умножается в соответствии с настройками здесь. Допустимые значения: 'высокий' = х 10 «средний» = х 100 «низкий» = х 300 'high' и 'medium' также включают session.referer_check Идентификаторы сеанса CakePHP также генерируются между запросами, если для параметра «Security.level» задано значение «высокий».

Ссылка: http://book.cakephp.org/view/44/CakePHP-Core-Configuration-Variables

Так что другая вещь выглядит проверкой реферера.

session.referer_check содержит подстроку, которую вы хотите проверить для каждого HTTP Referer. Если клиент отправил Referer, а подстрока не была найдена, встроенный идентификатор сеанса будет помечен как недействительный. По умолчанию используется пустая строка.

Итак, судя по всему, вещи, которые вы теряете, - это способность точно определить, с кем и с какими сессиями вы имеете дело.

Я столкнулся с подобной проблемой потери сеансов, и во многих ответах указывалось на использование $ this-> requestAction (), так как это в основном вывело бы запрос из приложения, так что это может выглядеть как другой сеанс, созданный с высоким уровнем безопасности. .

Другая вещь, которую вывалили многие ответы Google, это отключение Session.checkAgent в вашем app / config / core.php, так как это означало, что сессия не будет проверяться. Это по крайней мере предотвратило потерю информации о сеансе между запросами страниц.

:)

1 голос
/ 24 декабря 2009

две вещи происходят при установке на «низкий»

1) время ожидания больше

2) если сессионный хай-джекинг легкий, то будет проще! поскольку сеанс не восстанавливается между запросами, как при значении 'high'!

и ничего больше.

кстати, вы можете изменить для конкретной страницы уровень безопасности или время ожидания сеанса, или и то и другое ... так что это не отменный выбор

0 голосов
/ 23 декабря 2009

Я полагаю, что единственное значение установки этого значения на низкое состоит в том, что время сеанса умножается на 300, а не на 10 или 100 для высокого и среднего значения соответственно, и обратитесь к сеансу и проверьте, что у вас возникла проблема.

Обновление: Если вы ранее установили этот параметр на высокий, вы также потеряете регенерацию идентификатора сеанса между запросами.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...