2014-01-04 3 views
1

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

То, что я настроен как мера безопасности я взял браузер отпечатки пальцев на старте сессии:

$_SESSION['fingerprint'] = $_SERVER['HTTP_USER_AGENT']; 

Каждый раз, когда сеанс испрашивается я выполнить проверку

if($_SESSION['fingerprint'] != $_SERVER['HTTP_USER_AGENT']) // Handle accordingly 

Таким образом, с включенным httpOnly на сеансовом захвате не так уж и много, кроме обмана Wi-Fi-маршрутизаторов с незащищенным соединением или прослушиванием любого другого типа, где злоумышленник будет знать обо всех заголовках запросов, поэтому сложность отпечатка не делает вообще нет. Если злоумышленник должен был скопировать все заголовки запросов своей жертвы, как я могу защитить сеанс?

+1

http://4techs.org/83/how-to-prevent-session-hijacking/ Можете прочитать это. – Ali

+0

Можете ли вы подробнее объяснить, что вы пытаетесь выполнить? Использование одного параметра, например браузера, не очень безопасно. На самом деле это очень подменяет. –

+0

@Phillip Я только что дал это в качестве примера. Какая разница в том, сколько «параметров» я буду использовать, если злоумышленник будет знать всю информацию, отправленную его жертвой? –

ответ

2

Вы не можете. Единственная вещь, которая идентифицирует клиента, - это куча HTTP-заголовков, из которых являются куки-файлы. Копирование/подделка всех заголовков означает выдачу себя за пользователя. Больше ничего нельзя сделать по публичной анонимной связи. Если вам нужно что-то еще, вам придется начать раздавать фактические секреты клиенту вне диапазона, например, сертификаты клиент-SSL. Однако это не очень практично.

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

+0

Я в основном согласен, хотя стоит упомянуть, что проверка IP-идентификатора ('$ _SERVER ['REMOTE_ADDR']') обеспечит некоторый уровень защиты, поскольку, если эти данные подделаны, пакеты не будут возвращены в нужное место - конечно IP-адреса часто меняются в середине сеанса, поэтому это приведет к завершению законных сеансов, но это возможный подход, если по какой-либо причине SSL невозможно. Тем не менее, все, что необходимо для обеспечения безопасности, должно пройти через SSL. –

+3

Да, проверка IP-адресов не помогает в сценарии злоумышленника в Starbucks и будет иметь много ложных срабатываний. TCP/IP - это механизм доставки данных, он не имеет ничего общего с аутентификацией, поэтому я даже не упоминаю об этом. Если вы не используете SSL, вы начинаете с этого неправильно. – deceze

+0

Это заставляет меня задаться вопросом, как люди пользовались сеансами до того, как ssl вошел –

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