2013-06-21 2 views
4

Есть ли способ проверить, был ли cookie от пользователя A украден пользователем B на стороне сервера?Проверка на стороне сервера, если cookie украден

, например маркер куки/данные, созданные с помощью простой хэш-функции (sha1, например)

hash_of(user_agent,ip+proxy_ip,username,random_session_key) 

where user_agent is browser's user agent, 
    ip is the client IP address, 
    proxy_ip is the proxy's IP address the client use, 
    username is the username the user currently login, 
    random_session_key is a random number saved to database when a user logged in 

если куки были украдены и использованы другим человеком по локальной сети и локальной сети не используется какой-либо прокси, но NAT, и вор использовал точно такой же браузер (или обманывает пользовательский агент), как мы на стороне сервера это обнаруживаем?

+1

_ "и в локальной сети не используется прокси-сервер, а NAT, и вор использовал точно такой же браузер (или обманывает пользовательский агент), как мы на стороне сервера обнаруживаем это?" _ - совсем нет ... ? Чтобы различать две вещи друг от друга, вы должны иметь по крайней мере одну информацию о каждом из них, которая отличается. Если вы не можете найти такую ​​информацию, вы не можете разделить их. – CBroe

ответ

5

Да, есть способ. Он называется Secure Cookie Protocol.

Вы используете SSL правильно? (потому что, если вас нет, весь этот разговор бессмыслен).

Ну, вы шифруете файл cookie, но используете идентификатор сеанса SSL. Предполагая, что SSL дает вам адекватную защиту конечных точек (сильные шифры и т. Д.), SCP должен защищать ваши данные и давать вам возможность сообщать, когда другой сеанс SSL пытается использовать тот же файл cookie (потому что sessionid изменяется, и поэтому MAC изменится).

key = HMAC(user name|expiration time, secret_key) 
cookie = user name|expiration time|encrypt(data, key) 
cookie = cookie | HMAC(user name|expiration time|data|sessionid, key) 

Таким образом, вы создаете уникальный код проверки на основе идентификатора сеанса SSL.

Обратите внимание, что REMOTE_ADDR или агент пользователя никогда не факторы в. Единственными факторами это использует вещи, которые крайне нетривиальной подделать, если Вы не физически скомпрометированы ящик клиента ...

1

Если печенье было уволен, слишком поздно. Приложение должно надлежащим образом защищать свои секреты. Useragenet контролируется злоумышленником, проверяя, что это значение небезопасно по своей природе.

OWASP - Insufficient Transport Layer Security.

HTTPOnly Cookies "Secure" Cookies

Предотвратить XSS, CSRF, и ClickJacking и фиксация сеанса.

+0

Поздравляем с 1000 ответами, ладья! – MaxArt

+0

@MaxArt хорошо спасибо – rook

Смежные вопросы