Я не заинтересован в совместимости с браузером.
Я хочу знать, могу ли я перенести свое состояние с сессий PHP Controlled (Server-Side) на локальное хранилище HTML 5, контролируемое JavaScript (Client-Side), я получу или потеряю безопасность.
Я думаю, что я получил бы безопасность, потому что теперь вместо того, чтобы иметь идентификатор пользователя, находящийся в файле cookie, который обычно является файлом или базой данных sql, которая легко доступна … она не находится внутри какого-то внутреннего хранилища браузера. + bc это более новая технология, я бы надеялся, что в нее будет вложена больше безопасности.
Я могу получить или потерять безопасность, перейдя с сеансов PHP на локальное хранилище JavaScript. (Это касается таких вещей, как идентификатор пользователя, page_id и т. Д., Текущее состояние, которое остается после перезагрузки и дольше, если необходимо).
У меня есть JavaScript-решение, которое я хочу заменить своими сеансами PHP. Вот почему я спрашиваю. Я не забочусь о совместимости браузера.
Вот информативный сайт о локальном хранилище. Но Безопасность не упоминалась.
Оба типа локального хранилища (localStorage и Cookies) используют какой-то идентификатор, который, очевидно, хранится на клиенте.
Оба используют хеш-механизм, чтобы защитить его от изменения другому пользователю.
Локальное хранилище более безопасно, чем файлы cookie (см. Здесь ).
И, очевидно, вам нужно написать протоколы сеансов, если вы хотите переместить свой идентификатор пользователя из файлов cookie на localStorage.
Оба могут быть украдены, чтобы подделать другого пользователя. Хотя менее вероятно с localStorage.
И для создания надежной вам понадобится техника отпечатка пальца, которая поможет справиться с вышеуказанной проблемой.
У меня есть JavaScript-решение, которое я хочу заменить своими сеансами PHP.
Нет. Не делай этого. Сеансы хранятся на стороне сервера. Файл cookie, отправленный в браузер, обычно является идентификатором для этой записи. Сеанс хранит пользовательские данные. Пользователь может легко изменить практически все, что хранится на стороне клиента. Поэтому, если пользователь изменяет сеанс, чтобы указать на другого пользователя, безопасность больше не будет выполняться.
LocalStorage НЕ предназначен для хранения сеансов. Придерживайтесь сессий PHP или любого другого механизма сеанса, который реализуется на стороне сервера.
Обновить
Но тот же самый недостаток безопасности присутствует … пользователь может войти в систему как один человек … скрипка с session_id сеанса и стать кем-то еще … возиться с session_id … приравнивается к тому, кто вы выглядите к серверу? … это было бы так же, как возиться с зашифрованным user_id в local_storage.
Нет. Предположим, я выясню алгоритм, с которым вы шифруете. И я знаю, что другой пользователь говорит UserB. Я включил его имя пользователя, используя этот алгоритм. Если я каким-то образом перезапишу свой localStorage с помощью этой зашифрованной строки, я теперь его. Практически это практически невозможно. Подумайте об этом, так как это 100 пользователей, а 128 байтов – это идентификатор. Вы уверены, что сможете справиться с ним и изменить его на другую запись, которая существует в таблице сеансов?
Локальное хранилище лучше всего подходит для данных, которые вы хотите кэшировать на клиенте (более постоянным), а затем с обычным кешем браузера. Единственным способом «более безопасного» является то, что вы хотите разрешить пользователю работать с данными, которые никогда не отправляются на сервер .
Если вас беспокоит захват сеанса, предпочтительным решением будет использование https / ssl и шифрование всего трафика между вами и клиентом. Есть общий обзор проблемы и решений по википедии (нам потребуется дополнительная информация, чтобы дать вам что-то гораздо более конкретное, чем это).
Вы не получите или не потеряете безопасность, как в большинстве браузеров, все данные, установленные сайтами, хранятся в одной папке