безопасность сеанса в php

Question

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

Так может ли хакер как-то изменить эту переменную, чтобы серверная часть предоставила ему доступ к некоторым параметрам?

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

Answer 1

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

согласно Википедии

Существует четыре основных метода, используемых для захвата сеанса:

1. Фиксация сеанса, когда злоумышленник устанавливает идентификатор сеанса пользователя на известный ему, например, отправляя пользователю электронное письмо со ссылкой, содержащей конкретный идентификатор сеанса. Теперь злоумышленнику нужно только дождаться входа пользователя в систему.

2. Переадресация сеанса, когда злоумышленник использует перехват пакетов для чтения сетевого трафика между двумя сторонами для кражи cookie сеанса. Многие веб-сайты используют шифрование SSL для страниц входа в систему, чтобы злоумышленники не видели пароль, но не используют шифрование для остальной части сайта после проверки подлинности. Это позволяет злоумышленникам, которые могут считывать сетевой трафик, перехватывать все данные, отправляемые на сервер, или веб-страницы, просматриваемые клиентом. Поскольку эти данные включают cookie-файл сеанса, он позволяет ему выдавать себя за жертву, даже если сам пароль не скомпрометирован. 1 Незащищенные точки доступа Wi-Fi особенно уязвимы, так как любой, кто использует сеть, обычно может читать большую часть веб-трафика между другими узлами и точкой доступа.

3. В качестве альтернативы злоумышленник с физическим доступом может просто попытаться украсть ключ сеанса, например, получив содержимое файла или памяти соответствующей части компьютера пользователя или сервера.

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

Хотя есть несколько решений, чтобы остановить этот вид угона, например, для второго, использующего SSL или https, было бы целесообразно избежать этого. однако, если вы хотите добавить больше безопасности для вашей сессии, то я столкнулся с одним решением - разрешить передачу seesionId только через Cookies, а также создать и дополнительный маркер сеанса, который передается через URL. и только запрос, содержащий действительный токен Session, может получить доступ к сеансу.

Ниже приведен пример, демонстрирующий пример, взятый из Orielly PHP CookBook.

ini_set('session.use_only_cookies', true); 
session_start();
//Create a random salt value
$salt = 'Hjkhkjh9089&j98098';
$tokenstr = (str) date('W') . $salt; 
//Create a md5 hash to be used for token.
$token = md5($tokenstr);
if (!isset($_REQUEST['token']) || $_REQUEST['token'] != $token) { 
    // prompt for login
    exit; 
}
$_SESSION['token'] = $token; 
output_add_rewrite_var('token', $token); 

Что теперь делает output_add_rewrite_var, добавляет еще одну пару имя / значение в механизм перезаписи URL через метод Get. Узнайте больше о функции здесь. output_add_rewrite_var

чтобы узнать больше о безопасности сеансов, предлагаю прочитать эту статью http://hungred.com/useful-information/solutions-session-attacks/

надеюсь, это поможет вам понять уязвимости сессий и как их исправить.

Answer 2

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

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

Answer 3

Честно говоря, если вы не владеете методами аутентификации, я бы предложил использовать установленного поставщика (или аналогичного, такого как Google , Facebook , Twitter и т. Д. С помощью oAuth), у которых есть специалисты в данной области. Зачем пытаться заново изобрести колесо, когда есть крупные компании с полевыми экспертами, которые предоставляют именно эту услугу? Использование этих провайдеров также даст вам представление о том, как обеспечить безопасную аутентификацию для ваших систем.