Предотвращение CSRF для веб-сокетов

В настоящее время я рассматриваю уязвимости CSRF в веб-сокетах.

Я уже заблокировал все междоменные запросы веб-сокетов, однако существуют скрипты (например, этот плохой мальчик на питоне ), чтобы обойти такие меры безопасности.

Стоит ли включать токен в index.html пользователя, который должен быть включен в вызов socket.io.connect() в виде строки запроса? Таким образом на сервере мы можем проверить, что токен соответствует нашим ожиданиям, и в противном случае заблокировать запрос на подключение.

Спасибо за все советы!


socket.io websocket csrf csrf-protection
person user1161657    schedule 03.09.2012    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Почему бы вам не настроить обработчик авторизации для ваших соединений socket.io? Вы можете отклонять/принимать соединения на основе информации, собранной во время рукопожатия.

См. https://github.com/LearnBoost/socket.io/wiki/Authorizing для получения более подробной информации об этом.

person 3rdEden    schedule 03.09.2012
comment
Но при авторизации должен ли быть включен токен csrf? Авторизация вызывается, когда используется вызов socket.io.connect() - person user1161657; 03.09.2012
comment
Вы можете предоставить io.connect параметры URL и добавить туда токен.. io.connect('http://example.com?token=' + mytoken') - person 3rdEden; 04.09.2012
comment
Эй, 3rdEden, что бы ты сделал лучше? а) отправлять токен _csrf в каждом сообщении на сервер? или б) отправить токен _csrf только в socket.io.connect()? Просто из любопытства - person Herman Junge; 15.02.2013
comment
Каковы риски появления токена csrf в URL-адресе? А Человек посередине? Не лучше ли проверять csrf только в сообщениях, а не при первом подключении? - person Herman Junge; 16.02.2013
comment
В большинстве случаев будет достаточно токена во время соединения. Я не вижу причин, по которым вы должны отправлять его для каждого сообщения, поскольку вы уже авторизовали соединение. - person 3rdEden; 16.02.2013
comment
@3rdEden Может быть, потому что CSRF — это использование того факта, что вы уже авторизованы, чтобы делать вредоносные вещи от вашего имени? - person Yaron U.; 13.03.2015

arrow_upward
1
arrow_downward

Я использую socket.io с django. Способ, которым я обрабатываю авторизацию, заключается в том, что я сначала требую, чтобы пользователи вошли в систему, используя обычную форму HTTP, которая включает токен CSRF. После успешного входа в систему устанавливается файл cookie сеанса, и пользователь перенаправляется в приложение socket.io.

В моем коде авторизации подключения я проверяю файл cookie и подтверждаю, что пользователь вошел в систему, возвращая «401 Not Authorized», если проверка не удалась.

Также можно установить файл cookie CSRF и проверить его вместо этого, если вы не хотите, чтобы пользователи сначала входили в систему, или вы можете передать токен CSRF в качестве параметра URL во время авторизации, как указал @3rdEden.

person Tony Abou-Assaleh    schedule 07.09.2012
comment
Вы можете передать токен CSRF во время соединения, а не просто проверять файл cookie авторизации. WebSockets отправляют заголовки даже между доменами, что отличается от того, как CORS работает с XHR. christian-schneider.net/CrossSiteWebSocketHijacking.html - person tilgovi; 15.01.2015
comment
минус! как отмечает filgovi, создание соединения socket.io с вашим сайтом с сайта злоумышленника все равно отправит файл cookie сеанса, и, таким образом, Javascript злоумышленника имеет полный доступ к соединению socket.io в качестве пользователя. - person Codebling; 01.11.2016