2009-03-05 8 views
4

Он продолжает работать в моей голове последние пару дней, но я прочитал несколько статей о том, как сделать ваши сессии PHP более безопасными. Почти все эти статьи говорят, что вам нужно сохранить useragent в сеансе с дополнительной солью. Что-то вроде этого:PHP-сессии + Useragent с солью

$fingerprint = md5('SECRET-SALT'.$_SERVER['HTTP_USER_AGENT']); 

соль затруднит злоумышленнику угнать или любой сеанс. Но почему добавить соль каждый раз, когда вы проверить это следующим образом:

md5('SECRET-SALT'.$_SERVER['HTTP_USER_AGENT']) == $_SESSION [ 'fingerprint' ] 

Так почему бы соль сделать его более безопасным, так как злоумышленник все еще нуждается только UserAgent (который relativly небольшого набора различного useragents) и sessionid?

Вероятно, что-то маленькое, я с видом, но не могу понять его, сводит меня с ума ха-ха

Спасибо!

ответ

0

Я делаю это также partially protect from session impersonation attacks. Вам также необходимо указать IP-адрес.

Имейте в виду, что, когда браузер автоматически клиента обновляет изменения агента пользователя, и вы будете думать, что его сеанс был угнан;)

+0

, в том числе IP-адрес в сеансе отпечатка пальца, является плохим, поскольку он не позволяет пользователям законно изменять IP-адреса, например, линию DSL, которая отключает – Guss

+0

@Guss: когда это произойдет (или когда автообновление браузера агента пользователя), то я аннулировать сеанс. Не важно, пользователь должен повторно войти в систему. – cherouvim

0

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

+0

соль = хорошо: D см. Мой ответ – Mez

+0

Мне понадобилось время, чтобы набрать: D – Mez

+0

соль бесполезна, см. Мои комментарии к вашему ответу. – Guss

0

Имейте в виду, что если вы это сделаете, вы заставляете людей снова входить в систему, если они обновляют свой браузер. Это может быть хорошо, но просто убедитесь, что это ваше намерение.

Использование удаленного адреса пользователя также не имеет проблем. Многие люди используют один и тот же компьютер из разных мест. Мобильные устройства, ноутбуки используются дома и на работе, ноутбуки используются в горячих точках Wi-Fi и так далее. ИМХО, это плохая идея использовать IP-адрес таким образом, что для нового IP-адреса требуется логин , если вы не имеете дело с высокочувствительной информацией, такой как онлайн-банкинг. Это так?

Что вас беспокоит? Внешняя атака? Или в ситуации с общим хостом, что кто-то может прочитать вашу информацию о сеансе?

Если это последнее, решение прост: просто не храните ничего чувствительного в сеансе. Все важные данные должны храниться в базе данных.

С точки зрения создания секретной соли, вам нужно использовать что-то, что нельзя догадаться. Я бы выбрал нечто вроде случайной строки, созданной при создании пользователя. При необходимости воссоздайте его каждый раз, когда сеанс недействителен.

Что касается безопасности, вы сказали бы это сами: существуют ограниченные строки пользовательских агентов (менее сотни, вероятно, будут охватывать 99,99% пользователей). Соль просто увеличивает количество возможностей. При этом, если вы используете ту же соль для всех сеансов, то это всего лишь вопрос времени, прежде чем он будет найден с грубой силой.

7

Причина, по которой предлагается добавить соль, проста. Как правило, когда вы создаете этот «отпечаток пальца» - если вы используете только один элемент данных, который имеет ограниченный набор данных, тогда это облегчает для внешнего хакера генерировать это и захватывать сеанс.

В приведенном выше примере да, если у злоумышленника есть как «отпечаток пальца», так и агент «Пользователь», тогда они смогут захватить сеанс.

Добавление соли только делает его более трудным для атакующего для создания отпечатков пальцев, это случай «, если у них есть все, кроме одной части информации, то последняя часть информации бесполезна)

Я d предположите, что вы добавили еще несколько вещей, например, в vBulletin (проект, который я использовал для работы) хэш-код сеанса (который в основном совпадает с отпечатком пальца) генерируется с помощью следующего кода.

define('SESSION_IDHASH', md5($_SERVER['HTTP_USER_AGENT'] . $this->fetch_substr_ip($registry->alt_ip))); // this should *never* change during a session 

Кроме того, хеш сеанса генерируется с использованием

md5(uniqid(microtime(), true)); 

Они оба проверены при попытке идентифицировать сеанс

Так, чтобы угнать сессию, человек должен был бы знать следующее

  • Время (точно) на сервере, когда сессия была создана
  • строка пользователи браузера агент
  • IP-адрес пользователя

Они также должны были бы обмануть IP-адрес (или, по крайней мере, первые 2/3 октета), чтобы это сделать.

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

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

Например, что-то, что я сейчас пишу в python, я генерирую хэш для использования с защитой XSRF. Следующее - это то, что я использую.

self.key = sha1(
     self.user.username + 
     self.user.password + 
     settings.SECRET_KEY + 
     strftime("%a, %d %b %Y %H:%M:%S +0000", gmtime()) 
    ).hexdigest() 

Для этого требуется имя пользователя и пароль пользователя, текущее время и заданная соль. Это было бы трудно для злоумышленника генерировать из-за соли и времени (хотя, обратите внимание, что это только защищено тем фактом, что он изменяется после его использования, со временем это не займет много времени для кого-то взломать это для конкретного пользователя, если он не изменился)

+0

Солить хэш - это просто безвестность и на самом деле не увеличивает сложность атаки. Это удваивается, если вы пишете приложение с открытым исходным кодом. – Guss

2

Если я правильно понял, вы хотите предотвратить захват сеанса удаленным злоумышленником, который угадывает идентификаторы сеансов?

Если это не так, то вы серьезно находитесь вне своей глубины - злоумышленник, который может отслеживать трафик, также может имитировать пользовательский агент, а злоумышленник, который получает доступ к вашему хранилищу сеансов, имеет все шары в любом случае ,

Если вы сохраняете строку пользовательского агента для «блокировки» сеанса текущему пользовательскому агенту, то в хэшировании нет никакой точки - сравнение строк по полной строке пользовательского агента выполняется быстрее (затем хеширование, а затем сравнение) и не значительно дороже с точки зрения хранения.

Я не считаю, что хранение пользовательского агента обеспечивает достаточную дифференциацию - лучше было бы генерировать больший идентификатор (с большим количеством бит) во время начала сеанса (возможно, sha1 текущая отметка времени + имя пользователя + пользовательский агент + что-то), затем сохраните это как в файле cookie, так и в сеансе и сопоставьте его с каждым дополнительным запросом. Это не сильно меняет вектор атаки (вам все равно нужно угадать некоторое число), но его легко значительно увеличить количество бит, которое должно быть угадано для успешной атаки там, увеличивая сложность атаки.

0

Хорошо, к примеру, я использую следующий код вымышленный:

<?php 

// The sessionid cookie is now a certain hash 
if (array_key_exists ($_COOKIE [ 'sessionid' ])) 
{ 
    // Get the session from database 
    $db_sessid = $pdo -> getStuff ('session_database', $_COOKIE [ 'sessionid' ]); 

    if ($db_sessid !== null && $db_sessid [ 'fingerprint' ] == sha1 ('SOMESALT' . $_SERVER [ 'HTTP_USER_AGENT' ])) 
    { 
     set_cookie (...); // New sessionid and write also to DB 

     // User is now logged in, execute some user stuff 
    } 
    else 
    { 
     // Session doesn't exist, or the fingerprint does not match 
    } 
} 

Теперь злоумышленник только все еще нуждается в SessionID, который в куки (отправленные по HTTP заголовков) и UserAgent. Так что же еще вопрос дополнительной соли?

Проверка на IP-адрес также, на мой взгляд, не такая хорошая опция, некоторые провайдеры или прокси меняют их каждый запрос.

Благодаря до сих пор (-:.

+0

Соленый хэш не имеет преимуществ в этом случае. – Gumbo

+0

Как я могу заставить его иметь преимущество? Потому что почти в каждой статье говорится, что это важно, но не объясняет, почему и как сделать это для хорошего использования. – Scee

3

Если вы находитесь на вашем собственном сервере, шифрования сеансовых переменных не имеет смысла, потому что они не получают из сервера См Linead ответ What do I need to store in the php session when user logged in? для получения дополнительной информации. Если вы находитесь на общем сервере, вам может потребоваться зашифровать все переменные сеанса, помимо идентификатора сеанса, потому что они хранятся в файлах temp, доступных для чтения на том же веб-сервере, что и все ваши соседи.

В любом случае, если вы действительно обеспокоены безопасностью, вы лучше со своим (виртуальным или нет) сервером, поэтому опасность будет поступать только из-за пределов вашего сервера.

Некоторые примеры риска для ваших сессий:

  • Ваш сервер отправляет идентификатор сессии в URL, а пользователь перейдет по ссылке на badguys.com Они получат в серверных переменных в Referer (полный URL, включая идентификатор сеанса), браузер и IP-адрес вашего пользователя. Если вы не проверяете IP-адреса, или ваш пользователь использует открытый прокси-сервер, им нужно только установить такую ​​же версию браузера, вставить URL-адрес, и они будут выполнены.
  • Пользователь переходит на общедоступный ПК, регистрируется и уходит, не закрывая сеанс (эй, он ведь человек). Следующий парень в строке открывает браузер, проверяет историю и находит открытый сеанс. Тьфу.

Так, некоторые меры, которые можно принять, по моему обычному предпочтению:

  1. Не посылать идентификатор сессии в URL; включить session.use_only_cookies в PHP. Минусы: пользователю необходимо включить файлы cookie.
    • Об опасных действиях (сменить пароль, сделать заказ ...), снова запросить пароль. Вы можете делать это периодически тоже. Минусы: Раздражающе.
    • Время ожидания сессии. Минусы: в большинстве сайтов это заставит пользователей часто входить в систему, раздражая их.
    • Использовать SSL (только для того, чтобы избежать атаки «человек в середине»). Минусы: Медлен. Глупые сообщения браузера. Нужен SSL на сервере.
    • Проверьте IP. Минусы: Неэффективно для посетителей, использующих общедоступный прокси. Раздражает динамические IP-адреса.
    • Проверьте агент пользователя (браузер).Минусы: почти бесполезно, UA легко получить и тривиально подражать.

(я сам собой разумеющийся, вы еще PHP сконфигурированы для обеспечения максимальной безопасности).

Некоторые более экстремальные меры:

  • поддерживать постоянное соединение между сервером и браузером, например, используя апплет Java. Нет связи, нет сеанса. Минусы: пользователю нужны Java, ActiveX или все, что вы используете. Сессия закрывается браузером (это может быть хорошо). Не работает на очень медленных соединениях. Более высокая загрузка на сервере. Вам нужно открыть порты, иметь специальный сервер для апплета.
  • То же самое, но с использованием асинхронных запросов (например, AJAX), чтобы очень часто обновлять сеанс и очень короткий тайм-аут. Или обновить скрытый IFRAME. Минусы: пользователю нужен JavaScript. Не работает на очень медленных соединениях. Более высокая загрузка на сервере.
  • То же самое, но перезагрузка всей страницы. Минусы: пользователю нужен JavaScript. Автоматическая перезагрузка при чтении страницы очень раздражает.

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

1

Я вижу одну цель - солить отпечаток пальца. Если плохой парень получает ваш сеанс-db (бог знает почему), но не вашего кода, он не мог «догадаться» о вашем методе отпечатка пальца, пытаясь использовать против него обычных агентов-пользователей.

+0

Стоит отметить, что вы ни в коем случае не должны доверять * никому * Скажите, вы управляете бизнесом и нанимаете не того человека делать что-то * с вашим сервером - в зависимости от того, к чему у них есть доступ, они могут красть сеансы по своему усмотрению. –

 Смежные вопросы

  • Нет связанных вопросов^_^