Допустим, вы бизнесмен и хотите разработать видеоконференцию или добавить видеочат в свою программу. Как понять, что разработчик сделал безопасно? Какую защиту обещать пользователям? Статей много, но они технические — разобраться сложно. Объясняем простыми словами.
Меры безопасности WebRTC-продукта состоят из 3-х частей: те, что предлагает WebRTC, те, что обеспечивает браузер и те, которые программирует разработчик. Обсудим меры каждого вида, как их обходят (уязвимости WebRTC) и меры защиты.
Что такое WebRTC?
WebRTC — Web Real-Time Communications — это открытый стандарт, который описывает передачу потоковых аудиоданных, видеоданных и контента между браузерами или другими поддерживающими его приложениями в режиме реального времени.
WebRTC — проект с открытым исходным кодом, поэтому кто угодно может проверить его код на безопасность, как здесь.
WebRTC работает на всех устройствах, подключаемых к Интернету:
- во всех основных браузерах
- в приложениях для мобильных устройств — например, iOS, Android
- в настольных приложениях для компьютеров — например, на Windows и Mac
- на смарт-часах
- на смарт-ТВ
- на шлемах виртуальной реальности
Чтобы WebRTC работал на этих разных устройствах, создали библиотеку WebRTC.
Какие способы обеспечения безопасности предлагает WebRTC?
Шифрование данных, кроме аудио и видео: DTLS
В библиотеку WebRTC встроен протокол DTLS — Datagram Transport Layer Security. Он шифрует данные при передаче, в том числе ключи для передачи зашифрованных аудио и видео. Официальная документация DTLS от Инженерного Совета Интернета.
DTLS не надо предварительно “включать” или настраивать, потому что он встроен. Разработчику видеоприложения ничего не нужно делать — DTLS в WebRTC работает по умолчанию.
DTLS — расширение протокола защиты транспортного уровня TLS (Transport Layer Security), обеспечивающего асимметричное шифрование. Возьмем пример бумажного письма и посылки, чтобы понять, что такое симметричное и асимметричное шифрование.
Мы обмениваемся письмами. Обычное письмо может вскрыть работник почты, его могут украсть и прочитать. Мы захотели, чтобы никто не смог прочитать письма, кроме нас. Вы придумали способ шифрования: например, менять местами буквы. Чтобы я смог расшифровать ваши письма, вам придется описать, как расшифровать ваш шифр и отправить мне. Это — симметричное шифрование: и вы, и я шифруем письма и у нас у обоих есть алгоритм дешифровки — ключ.
Слабость симметричного шифрования — в передаче ключа. Его так же может прочитать почтальон или именно это письмо с ключом могут украсть.
Изобретение асимметричного шифрования стало серьезным математическим открытием. В нем для зашифровки используется один ключ, а для расшифровки — другой. Узнать ключ расшифровки, имея ключ зашифровки, нельзя. Поэтому ключ зашифровки называется публичным — его можно безбоязненно передавать кому угодно, им можно только зашифровать послание. А ключ расшифровки называется приватным - и он никому не передается.
Вместо того, чтобы зашифровывать письмо и слать мне ключ, вы шлете мне открытый замок, а ключ оставляете у себя. Я пишу вам письмо, кладу его в ящик, кладу туда же свой открытый замок — и защелкиваю на ящике ваш замок. Отправляю вам, а вы открываете ящик своим ключом, который никому не передавали.
В симметричном шифровании ключи сейчас одноразовые. Например, мы созвонились — ключи создались специально для звонка и удалились сразу, как мы повесили трубку. Поэтому асимметричное и симметричное шифрование одинаково безопасны после установки соединения и обмена ключами. Слабость симметричного шифрования — только в том, что ключ-дешифратор надо передать.
Но асимметричное шифрование намного медленнее симметричного. Математические алгоритмы сложнее, требуется больше действий. Поэтому используют асимметричное шифрование в DTLS только чтобы защищенно обменяться симметричными ключами. Сами данные шифруются симметричным шифрованием.
Как обойти DTLS?
Взлом шифра DTLS — сложная математическая задача. Считается, что это не сделать в разумное время без суперкомпьютера — да и с ним, возможно, тоже. Хакерам выгоднее искать другие уязвимости.
Единственный способ обойти DTLS — украсть приватный ключ: украсть ваш ноутбук или подобрать пароль к серверу.
В случае с видеозвонками через медиа сервер, сервер — это отдельный компьютер, на котором хранится его приватный ключ. Если получить к нему доступ — можно подслушать и подсмотреть звонок.
Так же можно получить доступ к вашему компьютеру. Например, вы ушли на обед и оставили включенный компьютер в кабинете. Злоумышленник входит в кабинет и загружает на ваш компьютер файл, который передаст ему ваш приватный ключ.
Но во-первых, тут как с воровством газа: чтобы украсть газ, надо сидеть у газопровода. Злоумышленнику надо иметь доступ к проводам, по которым передается от вас информация — или быть в той же Wi-Fi сети: например, сидеть в том же офисе. Но зачем такие сложности: можно просто закинуть на ваш компьютер файл, который будет писать экран и звук и отправлять это злоумышленнику. Такой зловредный файл вы и сами можете случайно скачать из интернета, если будете скачивать непроверенные программы с непроверенных сайтов.
Во-вторых, это уже не взлом DTLS шифрования — это взлом компьютера.
Как защититься от уязвимости DTLS?
- Не оставлять включенный компьютер без пароля без присмотра.
- Беречь пароль от компьютера. Если вы — владелец видеопрограммы — беречь пароль от сервера, где она установлена. Пароль надо регулярно менять. Нельзя использовать пароль, который вы используете где-то еще.
- Не скачивать непроверенные программы.
- Не скачивать ничего с непроверенных сайтов.
Шифрование аудио и видео: SRTP
DTLS шифрует все данные, кроме видео и аудио. DTLS защищенный, но из-за этого медленный. Видео и аудио — “тяжелый” вид данных. Поэтому для шифрования видео и аудио в реальном времени DTLS не использовать — будет лагать. Их шифрует более быстрый, но из-за этого менее надежный SRTP — Secure Real-time Transport Protocol. Официальная документация SRTP от Инженерного Совета Интернета.
Как обойти SRTP?
2 уязвимости SRTP:
1. Не шифруются заголовки пакетов
SRTP шифрует содержание пакетов RTP, но не заголовок. Любой, кто видит пакеты SRTP, сможет определить, говорит ли пользователь в данный момент. Сама речь не раскрывается, но это все равно можно использовать против говорящего. Например, сотрудники правоохранительных органов смогут понять, общался ли пользователь с преступником.
2. Можно перехватить ключи от шифра
Представим, пользователи А и Б обмениваются видео и аудио. Они хотят, чтобы никто не подсмотрел и не подслушал. Для этого надо видео и аудио зашифровать. Тогда, если их перехватят, злоумышленник ничего не поймет. Пользователь А шифрует свои видео-аудио. Теперь понять их не может никто, даже Б. А нужно передать Б ключ, чтобы Б расшифровал видео и аудио у себя. Но ключ тоже можно перехватить — в этом и есть уязвимость SRTP.
Как защититься от атак на SRTP?
1. Не шифруются заголовки пакетов
Есть предложенный стандарт, как шифровать заголовки пакетов в SRTP. На октябрь 2021 года это решение еще не вошло в SRTP, его статус — предложенный стандарт. Когда его включат в SRTP, его статус изменится на “одобренный стандарт”. Проверять статус можно здесь, под заголовком Status.
2. Можно перехватить ключи от шифра
Есть 2 метода обменяться ключами:
1) через SDES — Session Description Protocol Security Descriptions — Дескрипторы безопасности протокола SDP для потокового вещания
2) зашифровать DTLS
1) SDES не поддерживает шифрование end-to-end. То есть если между А и Б есть посредник, например, прокси — придется выдать ключ прокси. Прокси получит видео и аудио, расшифрует их, зашифрует обратно — и передаст Б. Передача через SDES не безопасна: можно перехватить расшифрованные видео и аудио у посредника в момент, когда они расшифрованы, но еще не зашифрованы обратно.
2) Ключ — это уже не “тяжелые” видео или аудио. Его можно зашифровать надежным DTLS — с шифрованием ключа он справится быстро, лагов не будет. Такой способ называется гибридом DTLS-SRTP. Чтобы защититься, используйте этот способ вместо SDES.
Защита IP-адреса — IP Location Privacy
IP-адрес — это адрес компьютера в интернете.
Чем опасно если злоумышленник узнает ваш IP?
Представьте IP как ваш домашний адрес. Вор может украсть паспорт — узнать, где вы живете и прийти взламывать входную дверь.
Узнав ваш IP, хакер может начать искать уязвимости в вашем компьютере. Например, запустить проверку портов и узнать, какие программы у вас установлены.
Например, это мессенджер. А в сети есть информация, что у этого мессенджера обнаружена уязвимость, с помощью которой можно залогиниться на ваш компьютер. Хакер может использовать ее как в случае выше: когда вы загрузили непроверенную программу и она начала записывать ваш экран и звук и отправлять их хакеру. Только в этом случае вы ничего не устанавливали сами, были осторожны. Но хакер загрузил на ваш компьютер эту программу через уязвимость мессенджера. Мессенджер — только пример. Может быть использована любая программа с уязвимостью на вашем компьютере.
Другая опасность — с помощью IP-адреса хакер может определить, где вы находитесь физически. Так в фильмах тянут время в переговорах с террористом, чтобы засечь его местоположение.
Как защитить IP адрес от злоумышленников?
Полностью защититься от этого нельзя. Но есть 2 способа как снизить риски:
1. Отложить обмен IP адресами до момента, когда пользователь снимет трубку. Так, если вы не примете звонок, то вторая сторона не узнает ваш адрес. Но если решите снять, то узнает. Это делается через подавление переговоров JavaScript с ICE, пока пользователь не возьмет трубку.
ICE — Internet Connectivity Establishment — установление подключения: он описывает протоколы и маршруты, необходимые, чтобы WebRTC связался с удалённым устройством. Подробнее про ICE читайте в нашей статье WebRTC in plain language.
Недостаток:
Помните, в соцсетях и Skype отображается, кто сейчас онлайн, а кто нет? Это сделать не получится.
2. Не использовать p2p связь, а использовать сервер-посредник. в этом случае собеседнику будет известен только IP адрес посредника, а не ваш.
Недостаток: Весь трафик пойдет через посредника. А это порождает другие проблемы с безопасностью, как выше в разделе про SDES.
Если посредник — это медиа сервер и он установлен на вашем сервере, он настолько же безопасен, насколько и ваш сервер, потому что находится под вашим контролем. Меры защиты вашего сервера смотрите ниже в разделе про SOP.
Какие способы обеспечения безопасности предлагают браузеры?
Эти способы — только для веб-приложений, работающих в браузере. Например, к мобильным приложениям на WebRTC это не относится.
SOP — Same Origin Policy
Same-origin policy — политика одного источника. Когда вы открываете сайт, на ваш компьютер скачиваются скрипты, нужные для работы этого сайта. Скрипт — программа, которая работает внутри браузера. Каждый скрипт скачивается откуда-то — с сервера, где он физически хранится. Это его источник. На одном сайте могут быть скрипты с разных источников. SOP означает, что скрипты, скачанные с разных источников, не имеют доступ друг к другу.
Пример: у вас сайт с видеочатом. На нем есть ваши скрипты — они хранятся на вашем сервере. И есть сторонние скрипты — например, скрипт для проверки правильности заполнения контактной формы. Ваш разработчик использовал его, чтобы не писать с нуля самому. У вас нет контроля над сторонним скриптом. Кто-то может взломать его: получить доступ на сервер, где он хранится, и заставить этот скрипт, например, запросить доступ к камере и микрофону пользователей на всех сайтах, где он используется. Атаки с помощью сторонних скриптов называются XSS — cross-site scripting (межсайтовый скриптинг).
Если бы не было SOP, сторонний скрипт просто получил бы доступ к камерам и микрофонам ваших пользователей. Их переговоры злоумышленник мог бы просмотреть и прослушать или записать.
Но SOP есть. Сторонний скрипт находится не на вашем сервере — в другом источнике. Поэтому у него нет доступа к данным на вашем сервере. Доступ к камере и микрофону вашего пользователя ему не доступен.
Но он может показать пользователю запрос дать доступ к камере и микрофону именно ему. Пользователь увидит табличку “Дать доступ к камере и микрофону?” еще раз, хотя он доступ уже давал. Это будет выглядеть странно, но пользователь может дать доступ, думая, что дает доступ вашему сайту. Тогда злоумышленник все же сможет смотреть и прослушивать его переговоры. Защита SOP в том, что без SOP доступ не запрашивался бы еще раз.
Доступ к камере и микрофону — лишь самый очевидный пример. То же самое касается и, например, шаринга экрана.
Еще хуже с текстовым чатом. Если бы не было SOP, можно было бы послать этот зловредный скрипт в чат. Скрипты в чате не отображаются: пользователь увидел бы пустое сообщение. А скрипт выполнился бы — и злоумышленник мог бы смотреть и слушать его переговоры и записывать их. С SOP скрипт не выполнится — потому что находится не на вашем сервере, а в другом источнике.
Как обойти SOP и как защититься
1. Ошибки в CORS — Cross-Origin Resource Sharing
Сложные веб приложения не могут удобно работать в условиях SOP. Даже компоненты одного вашего сайта могут храниться на разных серверах — в разных источниках. Спрашивать пользователя разрешение каждый раз раздражало бы его.
Поэтому разработчикам дана возможность добавлять исключения в SOP — Cross-Origin Resource Sharing (CORS). Разработчик должен через запятую перечислить источники-исключения или поставить “*” — разрешить всем.
В процессе разработки чаще всего есть разные версии сайта: версия продакшен — доступная настоящим пользователям, пре-продакшен — доступная владельцу сайта для финальной проверки перед выкладкой на продакшен, тестовая — для проверки тестировщиками, версия разработчика. URL всех версий разные. Программисту каждый раз при переносе версии в другую версию приходится заменять URL исключений из SOP. Есть соблазн поставить “*” для ускорения. Можно забыть заменить “*” на список исключений на продакшен версии — тогда SOP для вашего сайта не будет работать. Он станет уязвим для любых сторонних скриптов.
Как защититься от ошибок в CORS
Разработчику — проверять на уязвимость от XSS: вписывать исключения от SOP, а не “отключать” его, вводя “*”.
Пользователю — отзывать доступы к камере и микрофону, которые больше не нужны. В браузере хранится список разрешений: чтобы отозвать, надо снять галочку.
2. Подмена сервера, с которым ваш сервер соединяется по WebSocket
Что такое WebSocket?
Помните CORS — исключение из SOP, которое надо задать вручную? Есть еще одно исключение, которое действует всегда, по умолчанию. Это WebSocket.
Зачем такая небезопасная технология, спросите? Для общения в реальном времени. Технология запросов, на которую распространяется SOP, не позволяет общаться действительно в реальном времени, потому что она односторонняя.
Представьте, что вы едете в машине с ребенком на заднем сидении. Вы — это серверная сторона, ребенок — клиентская. Ребенок спрашивает вас периодически: мы приехали? Вы отвечаете “нет”. В технологии запросов, когда вы наконец приедете, вы не сможете сами сказать ребенку “приехали”. Вам придется дождаться, когда ребенок спросит. WebSocket позволяет вам самому сказать “приехали”, не дожидаясь вопроса.
Примеры из области программирования: видео и текстовые чаты. Если бы WebSocket не было, клиентской стороне приходилось бы периодически спрашивать: “мне есть входящие звонки?”, “мне есть сообщения в чате?”. Даже если спрашивать раз в 5 секунд, это уже задержка. Можно спрашивать чаще — раз в секунду, например. Но тогда повышается нагрузка на сервер, сервер должен быть серьезно мощнее, то есть дороже. Это неэффективно — поэтому придумали WebSocket.
В чем уязвимость WebSocket
WebSocket — это прямая связь с сервером. Но с каким? По-хорошему, с вашим. Но что если злоумышленник заменит ваш адрес сервера на свой? Да, его адрес сервера будет не в вашем источнике. Но соединение идет через WebSocket, значит, SOP его не проверяет и не защитит.
Что может случиться из-за такой замены? Клиентская сторона — ваш текстовый или видеочат — получит новое сообщение или входящий звонок. Отображаться будет, что пишет или звонит один человек, а на деле это будет злоумышленник. Вы можете получить сообщение от босса, например, “срочно пришли... пароль от моего Gmail аккаунта, отчет о прибыли за месяц” - да что угодно. Вам может позвонить злоумышленник, прикинувшись вашим боссом — и попросить что-то сделать. Если голоса похожи, вы и не задумаетесь, что это может быть не он — ведь звонок отображается как будто от него.
Как это можно сделать — вопрос творческий. Надо искать уязвимости в сайте. Пример — XSS. У вас сайт с видеочатом и контактной формой, сообщения из которой отображаются в панели администратора сайта. Хакер отправляет в контактную форму скрипт “замени адрес сервера на этот”. Скрипт отображается в панели администратора наравне со всеми сообщениями из контактной формы. Теперь он “внутри” вашего сайта — у него тот же источник. SOP его не остановит. Скрипт выполняется, адрес сервера меняется на другой.
Как защититься от подмены сервера, с которым ваш сервер соединяется по WebSocket
- Любые данные от пользователей фильтровать на скрипты
Если разработчик запрограммировал не принимать скрипты от пользователей — сообщение из контактной формы в примере выше не будет принято, и у злоумышленника не получится подменить ваш сервер на свой в соединении через WebSocket этим способом. Фильтровать на скрипты сообщения от пользователей надо всегда, это защитит не только от подмены сервера в WebSocket, но и от многих других проблем.
- Запрограммировать проверку, что соединение через webSocket установлено с нужным источником
Например, генерировать уникальное кодовое слово для каждого соединения через WebSocket. Такое кодовое слово отправляется не по WebSocket, а значит SOP работает. Если запрос на кодовое слово будет отправляться на сторонний источник, SOP не даст его отправить — ведь сторонний сервер находится в другом источнике.
- Обфускация кода
Обфускация кода — это его запутывание, приведение в непонятный вид, сохраняя его работу. Программисты пишут код понятно — по-крайней мере, должны :) Чтобы, если разработку переймет другой разработчик, он мог в этом коде разобраться, какая часть что делает, и работать с этим кодом. Например, программисты понятно называют переменные. Так, тот самый адрес сервера, с которым надо соединиться по WebSocket — тоже переменная, и она будет названа понятно, например, “адрес сервера для соединения по WebSocket”. После прогона кода через обфускацию, эта переменная будет называться, например, “С”. Стороннему программисту-злоумышленнику будет непонятно, какая переменная за что отвечает.
Механизм генерации кодового слова хранится в коде. Взломать его — дополнительные усилия, но возможно. Если сделать код нечитаемым, злоумышленнику будет не найти в коде этот механизм.
3. Взлом сервера
Если взломают ваш сервер — зловредный сторонний скрипт можно “положить” на ваш сервер. SOP не поможет: ведь теперь источник этого скрипта — ваш сервер. Этот скрипт сможет воспользоваться доступом к камере и микрофону, который пользователь уже дал вашему сайту. Скрипт все еще не сможет послать запись переговоров на сторонний сервер, но это и не нужно. У злоумышленника есть доступ на ваш сервер: он может просто взять запись оттуда.
Как могут взломать сервер — не вопрос безопасности WebRTC, поэтому за пределами этой статьи. Например, злоумышленник может просто украсть у вас логин-пароль от сервера.
Как защититься от взлома сервера
Из очевидного — беречь логин-пароль.
Если ваш сервер взломали, защититься от последствий нельзя. Но есть способы усложнить жизнь злоумышленнику.
1. Хранить весь контент пользователя в зашифрованном виде на сервере. Например, записи видеоконференций. Сам сервер должен уметь расшифровывать их. Значит, на сервере хранится способ расшифровки. Если сервер взломали, злоумышленник может его найти. Но на это ему потребуется время. Он не сможет просто заскочить на сервер, скопировать записи разговоров и уйти. Время, которое ему придётся провести на взломанном сервере, увеличится. Это даёт время владельцу сервера принять какие-то меры, например, найти активную сессию подключённого злоумышленника и отключить его от имени администратора и сменить пароль от сервера.
2. В идеале — не хранить на сервере контент пользователя. Например, позволять записывать конференции, но не сохранять их на сервере, а давать пользователю скачать файл. Как только файл скачан — он есть только у пользователя, на сервере его нет.
3. Дать пользователю больше возможностей защитить себя — разработать уведомления в интерфейсе вашей программы. Не рекомендуем этот способ для всех, потому что он неудобен для пользователя. Но если разрабатываете видеозвонки для банка или медучреждения, безопасность важнее удобства:
— Просить доступ к камере и микрофону перед каждым созвоном.
Если ваш сайт взломают и захотят позвонить кому-то от имени пользователя без его разрешения — пользователю покажется уведомление: “Дать доступ к камере и микрофону для звонка?”. Он этот звонок не инициировал, поэтому, скорее всего, пользователя это убережет: он нажмет “нет”. Это безопасно, но неудобно. Какой процент пользователей уйдет к конкуренту вместо того, чтобы кликать “разрешить” перед каждым звонком?
— Просить доступ к камере и микрофону для созвона с конкретными пользователями.
Звоните пользователю впервые? Увидите уведомление “Дать доступ к камере и микрофону для звонков ... Валерии Николаевой (например)?”. Это менее неудобно для пользователя, если он часто звонит одним и тем же. Но все еще проигрывает в удобстве программам, которые запрашивают доступ всего 1 раз.
Известный браузер из надежного источника
Что это?
Программа, с помощью которой вы заходите на сайты. В браузере работают видеоконференции. Пользуясь им, вы исходите из того, что браузер безопасен.
Как злоумышленники используют браузер?
Внедряют вредоносный код, который делает то, что нужно хакеру.
Как защититься?
- Не качать браузеры из непроверенных источников.
Вот список официальных сайтов для самых популярных браузеров:
Firefox
Opera
Google Chrome
Safari
Microsoft Edge - Не пользуйтесь неизвестными браузерами
Как и со ссылками. Если браузер выглядит подозрительно — не качать его.
Можно дать список надежных браузеров пользователям своего веб приложения. Хотя, если они у вас на сайте — они уже используют какой-то браузер… :)
О каких мерах безопасности должен думать сам разработчик?
WebRTC создавался с мыслью о безопасности. Но не всё зависит от WebRTC, ведь это лишь часть вашей программы, отвечающая за звонки. Если кто-то украдет пароль пользователя, WebRTC не защитит его, насколько бы безопасной эта технология не была. Разберём, как сделать ваше приложение безопаснее.
Сигнальный уровень
Signaling Layer отвечает за обмен данными, необходимыми для установки соединения. Как работает установление соединения, пишет разработчик — это происходит до того, как в игру вступает WebRTC и все ее шифрования. По-простому: когда вы сидите на сайте с видео звонками, и у вас всплывает поп-ап: “Вам звонок, принять / отклонить?” До того, как вы нажали “принять” — это сигнальный уровень, установление соединения.
Как злоумышленники могут использовать сигнальный уровень и как защититься?
Возможностей сделать это много. Разберём 3 основные: Man-in-the-Middle attack, Replay attack, Session hijacking.
- MitM (Man-in-the-Middle) attack
В контексте WebRTC, это перехват трафика до установления соединения — до того, как в силу вступят шифрования DTLS и SRTP, описанные выше. Между созванивающимися сидит злоумышленник. Он может подслушать и подсматривать переговоры или, например, отправить порнографическую картинку в вашу конференцию — это называется зумбомбинг.
Это может быть любой злоумышленник, подключенный к той же Wi-fi или проводной сети, что и вы — он может просматривать и прослушивать весь трафик, идущий в вашей Wi-fi сети или по вашему проводу.
Как защититься?
Использовать HTTPS, а не HTTP. HTTPS поддерживает шифрование SSL/TLS на протяжении сессии. Man-in-the-middle все еще сможет перехватить ваш трафик. Но трафик будет защифрован, и он его не поймет. Он сможет сохранить его и попытаться расшифровать, но сразу не поймет.
SSL — Security Sockets Layer — предшественник TLS. Он превращает HTTP в HTTPS, обеспечивая безопасность сайта. Раньше пользователи ходили по сайтам http и https, не видя разницы. Теперь https - обязательный стандарт: разработчикам приходится защищать свои сайты сертификатами SSL. Иначе браузеры не пустят пользователя на сайт: покажут то страшное сообщение “ваше соединение не защищено” — и только нажав “подробнее” пользователь может нажать “все равно перейти на сайт”. Не все пользователи нажмут “все равно перейти”, поэтому все разработчики теперь добавляют SSL сертификаты на сайты.
- Replay attack
Вы защитились от Man-in-the-middle с помощью HTTPS. Теперь злоумышленник слышит ваши сообщения, но не понимает. Но он их слышит! А значит, может повторить — replay. Например, вы дали команду “перевести 1000 рублей”. А злоумышленник, хоть и не понимает, повторяет “перевести 1000 рублей” — и без дополнительной защиты команда будет выполнена. С вас спишется 1000 рублей 2 раза, и вторая 1000 рублей будет отправлена туда же, куда и первая.
Как защититься?
Установить случайный ключ сессии. Этот ключ будет активен на протяжении одной сессии и им нельзя будет воспользоваться дважды. “Перевести 1000 рублей. АВС”. Если злоумышленник повторит “перевести 1000 рублей. АВС” — станет понятно, что это сообщение повторное и исполнять его не надо. Именно так мы сделали на проекте NextHuddle — сервисе видеоконференций для обучения. NextHuddle рассчитан на аудиторию в 5000 пользователей и 25 стримеров.
- Session hijacking
Похищение сессии — когда хакер завладевает вашей интернет-сессией. К примеру, вы звоните в банк. Назвали кто вы, дату рождения или секретное слово. “Хорошо, мы вас узнали. Что вы хотите?” — и тут злоумышленник забирает у вас телефонную трубку и говорит, что он хочет.
Как защититься?
Использовать HTTPS. Чтобы перехватить сессию, надо быть man-in-the-middle. Поэтому то, что защищает от man-in-the-middle, защищает и от перехвата сессии.
Выбор разряда шифрования DTLS
DTLS — протокол шифрования. В протоколе есть алгоритмы шифрования — например, AES. У AES есть разряды — 128 или более сложный и защищенный 256. В WebRTC их выбирает сам разработчик. Убедитесь, что для AES выбран разряд, дающий наивысшую степень защиты — 256.
Как это делается, можно прочитать, например, в документации Mozilla. Генерируется сертификат, при создании peerconnection передается этот сертификат.
Аутентификация и отслеживание участников
Задача разработчика — чтобы все, кто входят в комнату видеоконференции, имели на это разрешение.
Пример 1 — закрытые комнаты: например, платный видео урок с учителем. Разработчик должен запрограммировать проверку: заплатил ли пользователь за урок? Если заплатил, пустить его, а если нет — не пускать.
Это кажется очевидным, но мы не раз встречали случаи, когда можно скопировать URL такой платной конференции, послать ее любому человеку — он переходит и попадает в конференцию, хотя за урок не платил.
Пример 2 — открытые комнаты: например, бизнес-видеоконференции вида “присоединись без регистрации”. Это делается для удобства: когда не хочешь заставлять бизнес-партнера тратить время и регистрироваться. Просто шлешь ему ссылку, он переходит — и попадает в конференцию.
Если участников немного, владелец и сам увидит, если присоединился кто-то лишний. А если много — может не заметить. Один из выходов — разработчику запрограммировать ручное одобрение новых участников владельцем конференции.
Пример 3 — помощь пользователю защитить свои логин и пароль. Если злоумышленник получит логин и пароль пользователя, он сможет зайти в программу под ним.
Запрограммируйте логин через сторонние сервисы. Например, соцсети, Google login или Apple login на мобильных устройствах. Можно не использовать пароль, а слать код для входа на емейл или телефон. Это сократит количество паролей, которые пользователю нужно хранить. Украсть нужно будет не пароль от вашей программы, а пароль от третьестороннего сервиса — соцсети, мобильной учетной записи или емейла.
Можно использовать два способа сразу — например, логин-пароль от вашей программы плюс код подтверждения на телефон. Тогда, чтобы взломать учетную запись, нужно будет похитить два пароля, а не один.
Не все пользователи захотят так сложно и долго входить, чтобы позвонить. Можно дать выбор: один способ входа или два. Те, кому важна безопасность, выберут два, и будут благодарны.
Настройки доступа
Будем честны — мы далеко не всегда читаем диалоговые окна с настройками доступа. Если пользователь привык кликать ОК, приложение может получить разрешения, которые он не хотел давать.
Другая крайность — пользователь может удалить приложение, если сразу не поймёт, зачем у него просят доступы.
Решить просто — проявите заботу. Напишите доходчиво, какие разрешения дает пользователь и зачем.
Например, в мобильных приложениях: перед показом стандартного поп-апа с запросом доступа к геолокации, показать пояснение вида “В нашем чате созваниваются люди поблизости. Разрешите доступ к геолокации, чтобы мы показали вам собеседников рядом».
Демонстрация экрана
Любое приложение, которое даёт функцию демонстрации экрана, должно иметь предупреждение о том, что именно пользователь показывает.
Например, перед сессией скриншеринга, когда пользователь выбирает область экрана, которую будет демонстрировать. Сделайте уведомление-напоминалку, чтобы пользователь случайно не показал кусок экрана с теми данными, которые он не хочет показать. “Что хотите пошарить?” — и варианты: “ — весь экран, — только одно приложение — выберите какое, например только браузер”.
Если вы дали разрешение шарить экран сайту, и сайт взломали — взломщик может отправить вам скрипт, который откроет в вашем браузере какую-то веб страницу, пока вы шарите экран. Например, он знает, как формируются ссылки на сообщения в соцсети. Он сформировал ссылку на вашу переписку с конкретным человеком, которую хочет посмотреть. Он в соцсети под вами не залогинен — поэтому когда он перейдет по этой ссылке, он вашу переписку не увидит. Но если он взломал сайт, которому вы разрешили показывать экран, в следующий раз, когда вы покажете там экран — он выполнит скрипт, который откроет эту страницу с перепиской в вашем браузере. Вы поспешите закрыть ее, но поздно: скриншаринг уже передал ее злоумышленнику. Защита от этого — та же, что от взлома сервера — беречь пароли. Но это сделать сложно. Проще — не взламывать сайт, а прислать подставную ссылку, запрашивающую скриншаринг.
Где почитать подробнее о безопасности WebRTC
В интернете много статей о безопасности в WebRTC. С ними 2 проблемы:
- Они лишь выражают чье-то субъективное мнение. Наша статья — не исключение. Мнение может быть ошибочным.
- Большинство статей технические: не программисту не разобраться.
Как решить эти проблемы?
1. Используйте научный метод исследования: читайте первоисточники — публикации, подтвержденные чьим-то авторитетом. В научном труде это публикации в ВАК-журналах — перед публикацией в них работу должен одобрить другой ученый из Высшей Аттестационной Комиссии (ВАК). В ИТ это Консорциум Всемирной Паутины W3C и Инженерный Совет Интернета IETF. Работы перед публикацией одобряют технические специалисты из Google, Mozilla и подобных корпораций.
2. Документация выше верна, но написана настолько техническим языком, что не техническому человеку не разобраться. С большинством статей в интернете — так же. Поэтому мы написали эту. После ее прочтения:
— Основы вам станут понятны (надеемся). Может быть, и этого хватит для принятия решения.
— Если нет — первоисточники вам будет понять легче. Кооперируйтесь с вашим программистом — или приходите к нам за советом.
Заключение
Сам WebRTC безопасен. Но если разработчик приложения на основе WebRTC не позаботится о безопасности, его пользователи в безопасности не будут.
Так, в WebRTC все данные, кроме видео и аудио, шифруются DTLS, а аудио и видео — SRTP. Но многие параметры безопасности WebRTC выбирает разработчик видео приложения: например, как передавать ключи к SRTP — по высшему уровню защиты DTLS или нет.
Далее, WebRTC — это лишь способ передачи данных, когда соединение уже установлено. Что происходит с пользователями до установления соединения — полностью зависит от разработчика: как он запрограммирует, так и будет. Какие исключения из SOP задать, как пускать пользователей в конференцию, использовать ли HTTPS — все это на совести разработчика.
Пишите нам, проверим ваше видео приложение на безопасность.
Комментарии