Подсказки относительно cookie со знаком вместо сессий
У вас есть что-то похожее на код ниже:
int j = 0;
int i1 = j*5+ ++j;
System.out.println("j =" + j);
System.out.println("i1 =" + i1);
Вам нужно отредактировать свой код так:
int j = 0;
int i1 = ++j*5 + j;
System.out.println("j =" + j);
System.out.println("i1 =" + i1);
Ваш окончательный вывод для «i1 =» + i1) будет быть 6. Проблема в том, что в вашем первом примере кода вы не увеличиваете J перед тем, как умножить его на 5, поэтому вы увеличиваете его только на +1, потому что вы на самом деле не увеличиваете j, пока не умножите 0 * 5. (0 * 5) + 1 = 1. Я просто увеличил j (в форме префикса), чтобы он увеличился на 1, и теперь вы умножаете (1 * 5) + 1.
2 ответа
Почему беспокойство?
Я не использовал бы эту технику для уязвимых данных. Это может быть полезно в сочетании с очередной сессией, хотя - можно дать клиенту cookie с нормальным идентификатором сессии, но также и включать все те пары ключ/значение, в которых приложение нужно на каждой странице. Таким образом, можно постараться не поражать устройство хранения данных сессии для каждого запроса страницы.
Необходимо стремиться сохранять объем данных довольно трудным, так как он будет отправлен с каждым запросом.
Имея это в виду, вперед...
Подписание данных с хешем
Если данные не уязвимы, можно подписать значения с хешем sha1, сделанным из комбинации пар ключ/значение и общего секрета. например.
$values=array(
'user_id'=>1,
'foo'=>'bar'
);
$secret='MySecretSalt';
$plain="";
foreach($values as $key=>$value)
{
$plain.=$key.'|'.$value.'|';
}
$plain.=$secret;
$hash=sha1($plain);
Теперь дайте клиенту cookie со всеми значениями и хешем. Можно проверить хеш, когда cookie представлен. Если хеш, который Вы вычисляете от значений, представленных клиентом, не соответствует ожидаемому хешу, Вы знаете, что в значения вмешались.
Шифрование уязвимых данных
Для уязвимых данных необходимо будет зашифровать значения. Проверьте mcrypt расширение, которое предлагает много криптографических функций.
Воровство cookie
Относительно кражи cookie, если Вы помещаете удостоверения пользователя в cookie и доверяете ему, затем кто-то, кто получает тот cookie, может исполнить роль того пользователя, пока пароль не изменяется. Хорошая практика должна помнить, как Вы аутентифицировали пользователя, и только предоставьте определенные полномочия, если пользователь явно вошел в систему. Например, для форума Вы могли бы позволить кому-то отправить, но не изменить их банковские реквизиты как адрес электронной почты.
Существуют другие методы для cookie "автовхода в систему", включая предоставление таких cookie символической стоимости, которая Вы только позволяете использоваться однажды. Вот хорошая статья о той технике.
Вы могли также посмотреть включая клиентский IP в cookie со знаком, и если он не соответствует IP, представляющему cookie, Вы заставляете их входить в систему снова. Это обеспечивает больше защиты, но не будет работать на людей, очевидный IP-адрес которых продолжает изменяться. Вы могли сделать это дополнительной функцией и дать пользователю способ отказаться. Просто неактивная мысль, я не видел сделанный на практике :)
Для хорошей статьи, которая объясняет воровство сессии, налет и фиксация видят Сессии и Cookie, который предлагает еще несколько методов для попытки, такие как использование заголовка Агента пользователя как дополнительная подпись.
Я сделал CookieStorage точно с этой целью. Все сохраненные значения надежно подписаны с Вашим закрытым ключом через хеширование RIPEMD160 (и посолились со временем), и дополнительно зашифровал с RIJNDAEL256.
Каждое значение снабжено меткой времени, которая восстановима.
Пример со знаком.
Зашифрованный пример.
Если Вы предпочитаете, можно использовать хешировать/шифровать/дешифровать функции по Вашему выбору.