Используйте sprintf
:
sprintf('%08d', 1234567);
В качестве альтернативы вы также можете использовать str_pad
:
str_pad($value, 8, '0', STR_PAD_LEFT);
Шифрование значения сеанса будет иметь нулевой эффект. Файл cookie сеанса уже является произвольным значением, и его шифрование будет генерировать другое произвольное значение, которое можно обнюхать.
Единственным реальным решением является HTTPS. Если вы не хотите использовать SSL на своем сайте (возможно, у вас есть проблемы с производительностью), вы можете уйти с помощью только SSL, защищающего чувствительные области. Для этого сначала убедитесь, что ваша страница входа в систему - HTTPS. Когда пользователь входит в систему, установите безопасный файл cookie (то есть браузер будет передавать его только по ссылке SSL) в дополнение к обычному cookie сеанса. Затем, когда пользователь посещает одну из ваших «чувствительных» областей, перенаправляет их на HTTPS и проверяет наличие этого безопасного файла cookie.
EDIT: Этот ответ был первоначально написан в 2008 году. Сейчас 2016 год, и нет оснований не иметь SSL на всем сайте. Нет больше текстового HTTP!
Защита от:
$ip=$_SERVER['REMOTE_ADDER'];
$_SESSEION['ip']=$ip;
Попробуйте протокол Secure Cookie, описанный в этой бумаге Лю, Ковача, Хуанга и Гауды:
Как указано в документе:
Протокол безопасного файла cookie, который работает между клиентом и сервером, должен предоставить следующие четыре службы: аутентификация, конфиденциальность, целостность и анти-воспроизведение.
blockquote>Что касается простоты развертывания:
Что касается эффективности, наш протокол не требует поиска в базе данных или криптографии с открытым ключом. Что касается развертывания, наш протокол можно легко развернуть на существующем веб-сервере, и он не требует каких-либо изменений в спецификации cookie Интернета.
blockquote>Вкратце: это безопасный, легкий, работает для меня просто отлично.
Рассматривали ли вы чтение книги по безопасности PHP? Очень рекомендую
У меня был большой успех со следующим методом для сайтов, не сертифицированных SSL.
Я никоим образом не специалист по этому вопросу, немного опыта в этой конкретной теме, надеюсь, что некоторые из них помогают кому бы то ни было.
Давайте рассмотрим, что во время фазы входа клиент и сервер могут согласовать секретное значение соли. После этого сервер предоставляет значение счета с каждым обновлением и ожидает, что клиент ответит хэшем (секретная соль + кол-во). Потенциальный угонщик не имеет никакого способа получить это секретное значение соли и, следовательно, не может генерировать следующий хэш.
Существует множество способов создания защиты от захвата сеанса, однако все они либо уменьшают удовлетворенность пользователей, либо не защищены.
Чтобы снизить риск, вы также можете связать исходящий IP с сеансом. Таким образом, злоумышленник должен находиться в одной и той же частной сети, чтобы иметь возможность использовать сеанс.
Проверка заголовков реферирования также может быть опцией, но это более легко подделать.
AFAIK объект сеанса недоступен на клиенте, поскольку он хранится на веб-сервере. Однако идентификатор сеанса хранится как файл cookie, и он позволяет веб-серверу отслеживать сеанс пользователя.
Чтобы предотвратить захват сеанса с использованием идентификатора сеанса, вы можете сохранить хешированную строку внутри объекта сеанса, сделанную с использованием комбинация из двух атрибутов, удаленный адрр и удаленный порт, которые могут быть доступны на веб-сервере внутри объекта запроса. Эти атрибуты связывают пользовательский сеанс с браузером, в котором пользователь вошел в систему.
Если пользователь входит в систему из другого браузера или в режиме инкогнито в той же системе, IP-адрес останется прежним, но порт будут отличаться. Поэтому, когда приложение будет доступно, пользователю будет присвоен другой идентификатор сеанса веб-сервером.
Ниже приведен код, который я реализовал и протестировал, скопировав идентификатор сеанса с одного сеанса на другой. Это работает очень хорошо. Если есть лазейка, дайте мне знать, как вы имитировали ее.
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
HttpSession session = request.getSession();
String sessionKey = (String) session.getAttribute("sessionkey");
String remoteAddr = request.getRemoteAddr();
int remotePort = request.getRemotePort();
String sha256Hex = DigestUtils.sha256Hex(remoteAddr + remotePort);
if (sessionKey == null || sessionKey.isEmpty()) {
session.setAttribute("sessionkey", sha256Hex);
// save mapping to memory to track which user attempted
Application.userSessionMap.put(sha256Hex, remoteAddr + remotePort);
} else if (!sha256Hex.equals(sessionKey)) {
session.invalidate();
response.getWriter().append(Application.userSessionMap.get(sessionKey));
response.getWriter().append(" attempted to hijack session id ").append(request.getRequestedSessionId());
response.getWriter().append("of user ").append(Application.userSessionMap.get(sha256Hex));
return;
}
response.getWriter().append("Valid Session\n");
}
Я использовал алгоритм SHA-2 для хэширования значения, используя пример, приведенный в SHA-256 Hashing at baeldung
С нетерпением ждем ваших комментариев.
Убедитесь, что вы не используете инкрементные целые числа для идентификаторов сеанса. Гораздо лучше использовать GUID или другую длинную случайную последовательность символов.
Невозможно предотвратить захват сеанса на 100%, но с некоторым подходом мы можем сократить время атаки злоумышленника на сеанс.
Способ предотвращения захвата сеанса:
1 - всегда использовать сеанс с сертификатом ssl;
2 - отправлять cookie cookie только с httponly, установленным в true (запретить javascript для доступа к cookie сеанса)
2 - использовать идентификатор регенерации сеанса в логин и выход из системы (обратите внимание: не используйте регенерацию сеанса при каждом запросе, потому что если у вас есть последовательный запрос ajax, то у вас есть возможность создать несколько сеансов.)
3 - установить тайм-аут сеанса
4 - сохранить пользовательский агент браузера в переменной $ _SESSION, сравнить с $ _SERVER ['HTTP_USER_AGENT'] при каждом запросе
5 - установить токен-файл cookie и установить время истечения этого файла cookie равным 0 ( пока браузер не будет закрыт). Восстановите значение cookie для каждого запроса. (Для запроса ajax не регенерировать cookie-файл-токен). EX:
//set a token cookie if one not exist
if(!isset($_COOKIE['user_token'])){
//generate a random string for cookie value
$cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));
//set a session variable with that random string
$_SESSION['user_token'] = $cookie_token;
//set cookie with rand value
setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
}
//set a sesison variable with request of www.example.com
if(!isset($_SESSION['request'])){
$_SESSION['request'] = -1;
}
//increment $_SESSION['request'] with 1 for each request at www.example.com
$_SESSION['request']++;
//verify if $_SESSION['user_token'] it's equal with $_COOKIE['user_token'] only for $_SESSION['request'] > 0
if($_SESSION['request'] > 0){
// if it's equal then regenerete value of token cookie if not then destroy_session
if($_SESSION['user_token'] === $_COOKIE['user_token']){
$cookie_token = bin2hex(mcrypt_create_iv('16' , MCRYPT_DEV_URANDOM));
$_SESSION['user_token'] = $cookie_token;
setcookie('user_token', $cookie_token , 0 , '/' , 'donategame.com' , true , true);
}else{
//code for session_destroy
}
}
//prevent session hijaking with browser user agent
if(!isset($_SESSION['user_agent'])){
$_SESSION['user_agent'] = $_SERVER['HTTP_USER_AGENT'];
}
if($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']){
die('session hijaking - user agent');
}
note: не регенерировать файлы cookie Token с примечанием ajax request: приведенный выше код является примером. примечание: если пользователь выходит из системы, то токен cookie должен быть уничтожен, а также сеанс
6 - не рекомендуется использовать пользовательский ip для предотвращения захвата сессии, поскольку некоторые пользователи ip изменяются с каждым запросом. ЧТО ВЛИЯНИЕ ДЕЙСТВИТЕЛЬНЫХ ПОЛЬЗОВАТЕЛЕЙ
7 - лично я храню данные сеанса в базе данных, зависит от вас, какой метод вы принимаете
Если вы обнаружите ошибку в моем подходе, исправьте меня. Если у вас есть больше способов предотвратить сеанс hyjaking, пожалуйста, скажите мне.
// Collect this information on every request
$aip = $_SERVER['REMOTE_ADDR'];
$bip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$agent = $_SERVER['HTTP_USER_AGENT'];
session_start();
// Do this each time the user successfully logs in.
$_SESSION['ident'] = hash("sha256", $aip . $bip . $agent);
// Do this every time the client makes a request to the server, after authenticating
$ident = hash("sha256", $aip . $bip . $agent);
if ($ident != $_SESSION['ident'])
{
end_session();
header("Location: login.php");
// add some fancy pants GET/POST var headers for login.php, that lets you
// know in the login page to notify the user of why they're being challenged
// for login again, etc.
}
Что это значит, это «контекстная» информация о сеансе пользователя, фрагменты информации, которые не должны меняться в течение одного сеанса. Пользователь не будет одновременно на компьютере в США и в Китае, верно? Поэтому, если IP-адрес внезапно изменяется в пределах одного сеанса, что сильно подразумевает попытку захвата сеанса, поэтому вы защищаете сеанс, завершая сеанс и заставляя пользователя повторно аутентифицироваться. Это препятствует попытке взлома, злоумышленник также вынужден войти в систему вместо того, чтобы получить доступ к сеансу. Известить пользователя о попытке (ajax it it bit) и vola, Слегка раздражать + информированный пользователь и их сеанс / информацию защищены.
Мы бросаем User Agent и X-FORWARDED-FOR, чтобы сделать наш лучший способ захватить уникальность сеанса для систем, находящихся за прокси-серверами / сетями. Вы можете использовать больше информации, чем тогда, не стесняйтесь быть творческими.
Это не 100%, но это довольно эффективно.
. Вы можете сделать больше, чтобы защитить сеансы , истекает их, когда пользователь покидает веб-сайт и возвращается, чтобы заставить их снова войти в систему. Вы можете обнаружить, что пользователь ушел и вернулся, захватив пустой HTTP_REFERER (домен был введен в строке URL) или проверьте, соответствует ли значение в HTTP_REFERER вашему домену или нет (пользователь нажал внешнюю / созданную ссылку, чтобы перейти к вашему сайт).
Завершить сеансы, не позволяйте им оставаться действительными на неопределенный срок.
Не полагайтесь на файлы cookie, их можно украсть, это один из векторов атаки для сеанса угон.
$_SESSION['ident'] = $aip . $bip . $agent;
будет столь же безопасным.
– Dan Bray
9 May 2017 в 19:53
SSL помогает только при атаке нюханием. Если злоумышленник имеет доступ к вашему компьютеру, я предполагаю, что он также может скопировать ваш безопасный файл cookie.
По крайней мере, убедитесь, что старые файлы cookie теряют свою ценность через некоторое время. Даже успешная атака хиджака будет сорвана, когда cookie перестанет работать. Если у пользователя есть cookie из сеанса, который был зарегистрирован более месяца назад, заставьте их повторно ввести свой пароль. Убедитесь, что всякий раз, когда пользователь нажимает ссылку «выйти из системы» вашего сайта, старый UUID сеанса никогда не может использоваться снова.
Я не уверен, что эта идея будет работать, но здесь идет: добавьте серийный номер в ваш cookie сеанса, возможно, такую строку:
SessionUUID, Serial Num, Current Date / Время
Шифруйте эту строку и используйте ее в качестве файла cookie сеанса. Регулярно меняйте серийный номер - возможно, когда cookie имеет 5 минут, а затем переиздает файл cookie. Вы можете даже переиздать его на каждом просмотре страницы, если хотите. На стороне сервера сохраните запись последнего серийного номера, который вы выпустили для этого сеанса. Если кто-то отправляет cookie с неправильным серийным номером, это означает, что злоумышленник может использовать куки-файлы, которые они перехватили ранее, поэтому аннулирует UUID сеанса и просит пользователя повторно ввести свой пароль, а затем переиздать новый файл cookie.
Помните, что у вашего пользователя может быть более одного компьютера, поэтому у них может быть более одного активного сеанса. Не делайте то, что заставляет их регистрироваться при каждом переключении между компьютерами.