Я занимаюсь разработкой мобильного приложения, в котором я хочу внедрить простую аутентификацию пользователя, и, поскольку я новичок в гибридной мобильной разработке с ее интерфейсными ограничениями, я весьма испуган идеей хранения любых данных, связанных с бэкэндом. в форме localStorage / sessionStorage / ngCookies (как я видел, некоторые люди делают).
Итак, мой вопрос, насколько безопасными могут быть эти методы держать такие данные? Имеют ли пользователи приложения возможность доступа и изменения, скажем … sessionStorage, из самого приложения? Потому что это легко в Интернете.
Извините, если это глупый вопрос, я просто не хочу рисковать безопасностью, когда дело доходит до этого. Большое спасибо за любую помощь!
TLDR; Предполагается, что файлы cookie и хранилища хранятся в виде простого текста и доступны клиентскому скрипту, который поступает из того же домена. Предположим худшее; все может пойти не так с вашим скриптом из-за ошибок или XSS-атак. Если данные будут снова использованы и клиентом, и сервером, то, безусловно, подпишите их. Если данные относятся только к коду на стороне сервера, подпишите и зашифруйте его. Если данные предназначены только для распечатки материала на экран или оценки DOM, оставьте его в виде простого текста.
Давайте разберемся, что такое куки, сессионные и локальные хранилища, прежде чем приступить к реализации примера.
Печенье данные созданный сервером или клиентом, хранится в виде обычного текста браузерами, который отправляется при каждом http-запросе на сервер, если путь совпадает. Они хороши для хранения токенов аутентификации, метаданных, касающихся отслеживания, аналитики, настроек интерфейса веб-сайта, корзин покупок и многих других.
Хранилища — как указано их именем — место для хранения, назначенное вашему домену, и только скрипты из вашего домена и XSS-атаки может изменить это. Это означает, что если вы используете их для целей, перечисленных выше, вы должны вручную добавлять данные, хранящиеся в них, к вашим HTTP-запросам. Если ваш сайт зависит от множества асинхронных HTTP-вызовов, то не исключено использование таких хранилищ, как файлы cookie. В противном случае они полезны для кэширования таких вещей, как данные шаблона и ресурсы сайта.
Если вы используете куки для хранения пользовательских данных, которые необходимы для вашего сервера, такие куки могут быть зашифрованы на стороне сервера перед отправкой клиенту. Вы все еще можете получить доступ к таким куки с ngCookies
но единственный вред, который может быть причинен, состоит в том, что некоторый введенный код может сделать их недействительными. Если каким-то образом ваша схема шифрования будет раскрыта и они станут читабельными для злоумышленника, вы можете аннулировать их изменения, добавив подпись (созданную с помощью алгоритма безопасного хеширования) в каждое хранилище и проверяя свою подпись при каждом поиске. Давайте проиллюстрируем этот процесс.
$userState = json_encode($yourStateObjectOrAnAssociativeArray);
$sign = my_hash($userState);
$encryptedState = encrypt($userState);
setcookie("user" , $encryptedState);
setcookie("sign" , $sign);
Здесь мы закодировали наше состояние как JSON, а затем сначала сгенерировали хеш. Вы можете использовать некоторые SHA1, SHA256 и т. Д. С сохраненным ключом, который вы выбрали для my_hash()
функция. Ниже приведен пример, который является правильным, но вы не должны его использовать, так как даже я не должен знать ваш алгоритм.
// hash() is reserved so use something else
function my_hash($object) {
return sha1(md5($object) . "some giberish key that is stored as config data or in a db" . sha1($object))
}
Обратите внимание, что my_hash()
не очень безопасен, так как он использует статическую строку в качестве ключа и структуру генерации, которая не является сложной. В конце концов, это sha1()
какой-то случайно структурированной строки. Это достаточно для знака cookie, хотя.
Вы можете написать свой собственный encrypt()
/ decrypt()
создать пару, используя шифрование AES или какой-либо другой безопасный алгоритм по вашему выбору. Вот пример с этого сайта.
Теперь наш файл cookie сохранен и готов к отправке при следующем запросе. Ниже вы узнаете, как вы расшифровываете и проверяете ваши куки из приведенного выше примера.
$sign = $_COOKIE["sign"];
$encryptedState = $_COOKIE["user"];
$userState = decrypt($encryptedState); //If this fails, it indicates someone tried to replace your cookie by hand, it is a failed attack
$assoc = true; //If true, json_decode returns array, otherwise it returns an object
$yourStateObjectOrAnAssociativeArray = json_decode($userState, $assoc); //If this fails, it indicates someone tried to replace your cookie by hand, it is a failed attack
if($sign == my_hash($yourStateObjectOrAnAssociativeArray)) {
//Noone modified your cookie, you are safe
//Do something with it
}
else {
// Someone tried to replace your sign cookie to imitate your server but he failed
// or
// Someone managed to decrypt your cookie and modified it but failed to generate a valid sign (very unlikely)
// You are still safe
// Log this line and check every once in a while to detect unsuccessful hackers
}
Хорошая часть использования объекта состояния заключается в том, что его можно использовать для реализации многих видов ограничений и механизмов отслеживания. Например, хранение системного времени во время создания вашего cookie дает вам возможность истечь его позже. Внедрение IP-адреса клиента — это способ ограничения совместного использования файлов cookie в сетях.
Других решений пока нет …