Весна Безопасность запомнить меня печенье Юникод символов неправильно

Question

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

Печенье находится ниже.

Name: remember-me 
Content: Pz8/Pz8/OjE0NjQ5ODcxMjQxMDk6YTc1MDMzNTM0ZmNhNjc3YmUwOTljZGNjN2EyYTk1NjM 
Domain: localhost 
Path: /gy 
Send For: Any kind of connection 
Accessible to Script: No (HttpOnly) 
Created: Friday, 20 May 2016 at 21:52:04 
Expires: Friday, 3 June 2016 at 21:52:04 

Содержание выше - формат base64. Декодированная строка ниже.

??????: 1464987124109: a75033534fca677be099cdcc7a2a9563

Первая часть имени пользователя, что китайские иероглифы, но показано, как ??????.

Я знаю, что для сохранения символов Unicode в cookie мы должны использовать класс URLEncoder для его кодирования сначала, а затем декодировать его после его чтения. Я новичок в Java и Spring, поэтому понятия не имею, как настроить помнить, что cookie обрабатывает символы Unicode.

Любая подсказка для решения проблемы будет оценена по достоинству. Благодаря!

Answer 1

Это ошибка весенней безопасности. Он вычисляет MD5 like this:

Hex.encode(digest.digest(data.getBytes())); 

с использованием версии 0 аргументов getBytes, который кодирует символы Unicode в байты, используя кодировку по умолчанию. Кодировка по умолчанию меняется, но ясно, что на вашем сервере это кодировка, которая не может содержать китайских символов.

Нельзя полагаться на кодировку по умолчанию. Это очень часто не UTF, поэтому не может содержать все символы Unicode. Кроме того, поскольку он не исправлен, он может разорвать токены при переходе с одного сервера на другой. Spring должен был установить явное кодирование UTF, например getBytes("UTF-8").

Это не единственное свойство помните меня, что меня беспокоит:

• он использует MD5, алгоритм хэширования, который давно уже его расцвете, и все более уязвимыми для атак. Это даже не использует HMAC-MD5, которые смягчили бы это (HMAC предназначен именно для этой цели)

• всех неподдерживаемых символов получают молча раздавил в тот же характер, ?, что означает, что хэш для пользователя 你好 будет то же, что и хэш для пользователя ☃☃. Поэтому теоретически возможно войти в систему как любой пользователь-жертва с не поддерживаемым символом в своем имени пользователя (или вопросительном знаке!), Создав другого пользователя с другим не поддерживаемым символом в своем имени пользователя, а затем изменив cookie, чтобы включить имя пользователя жертвы с хешем нового пользователя. (На практике, однако, (а) наличие поля «пароль» в хеше усложняет вопросы, хотя это тоже уязвимо для раздачи символов Unicode и (б) к счастью, сам файл cookie также неправильно декодируется с использованием кодировки по умолчанию, предотвращая один - от получения произвольных символов Unicode в контролере в первую очередь).

• он бросает строки вместе без какого-либо спасаясь для разделителей, поэтому странность происходит, когда компоненты имеют двоеточие. Вы, вероятно, не можете реально сделать большую часть атаки с тем, что непосредственно, но это shonky и attempt to work around it это славно наполовину arsed ,

Я бы не доверял этому коду для защиты своего веб-приложения; неутешительно видеть подобные вещи в библиотеке безопасности высокого профиля.