Как работает безопасность WebRTC — просто и понятно

Допустим, вы бизнесмен и хотите разработать видеоконференцию или добавить видеочат в своё приложение. Как понять, что разработчик сделал всё безопасно? Какие гарантии можно дать пользователям? На эту тему много статей, но они технические — разобраться непросто. Мы объясним простыми словами.
Меры безопасности WebRTC-решения делятся на три части: те, что встроены в 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 не используют — будет лагать. Вместо него применяется более быстрый, но менее защищённый 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 не поддерживает сквозное шифрование. То есть если между А и Б есть посредник, например, прокси — придётся передать ключ прокси. Прокси получит видео и аудио, расшифрует их, снова зашифрует и отправит Б. Передача через SDES небезопасна: можно перехватить расшифрованные видео и аудио у посредника в момент, когда они уже расшифрованы, но ещё не зашифрованы заново.

2) Ключ — это уже не «тяжёлые» видео или аудио. Его можно зашифровать надёжным DTLS — с шифрованием ключа он справится быстро, лагов не будет. Такой способ называется гибридом DTLS- и SRTP. Чтобы защититься, используйте этот способ вместо SDES.

Защита IP-адреса — конфиденциальность местоположения по IP

IP-адрес — это адрес компьютера в интернете.

Чем опасно, если злоумышленник узнает ваш IP?

Представьте IP-адрес как ваш домашний адрес. Вор может украсть паспорт — узнать, где вы живёте, и прийти взламывать входную дверь.

Узнав ваш IP, хакер может начать искать уязвимости в вашем компьютере. Например, проверить открытые порты и выяснить, какие программы у вас установлены.

Например, это мессенджер. В сети появилась информация, что в нём нашли уязвимость, с помощью которой можно получить доступ к вашему компьютеру. Хакер может использовать её так же, как в предыдущем случае: когда вы установили непроверенную программу, и она начала записывать экран и звук, отправляя всё это злоумышленнику. Только в этот раз вы сами ничего не устанавливали — были осторожны. Но хакер загрузил вредоносную программу на ваш компьютер через уязвимость в мессенджере. Мессенджер — лишь пример. Уязвимость может быть в любой программе на вашем устройстве.

Другая опасность — по IP-адресу хакер может определить ваше физическое местоположение. Как в фильмах: время тянется в переговорах с террористом, чтобы выявить его позицию.

Как защитить IP-адрес от злоумышленников?

Полностью защититься от этого невозможно. Но есть два способа, как снизить риски:

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 и как защититься

1. Ошибки в CORS — обмен ресурсами между разными источниками

Сложные веб-приложения не могут удобно работать в условиях SOP. Даже компоненты одного сайта могут храниться на разных серверах — в разных источниках. Спрашивать пользователя разрешение каждый раз было бы раздражающим.

Поэтому разработчикам дана возможность добавлять исключения в SOP — Cross-Origin Resource Sharing (CORS). Разработчик должен через запятую перечислить источники-исключения или поставить «*» — разрешить всем.

В процессе разработки обычно существует несколько версий сайта: продакшен — та, что доступна реальным пользователям, пре-продакшен — для финальной проверки владельцем перед публикацией, тестовая — для тестирования и версия разработчика. У каждой версии свой URL. При переносе кода между версиями программисту приходится вручную менять URL в списке исключений политики одного источника (SOP). Чтобы ускорить работу, может возникнуть соблазн поставить «*». Но если забыть заменить «*» на конкретные URL при переходе на продакшен, политика SOP перестанет работать. В результате сайт станет уязвим для любых сторонних скриптов.

Как защититься от ошибок CORS

Разработчику — проверять на уязвимость к XSS: указывать исключения для SOP, а не «отключать» его, используя «*».

Пользователю нужно отзывать доступ к камере и микрофону, если он больше не нужен. В браузере хранится список разрешений — чтобы отозвать доступ, достаточно снять галочку.

2. Подмена сервера, с которым ваш сервер подключается по WebSocket

Что такое WebSocket?

Помните CORS — исключение из политики одного источника, которое нужно настраивать вручную? Есть ещё одно исключение, которое работает всегда, по умолчанию. Это 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. Дать пользователю больше возможностей защитить себя — разработать уведомления в интерфейсе вашей программы. Не рекомендуем этот способ для всех, потому что он неудобен для пользователя. Но если разрабатываете видеозвонки для банка или медучреждения, безопасность важнее удобства:

— Просить доступ к камере и микрофону перед каждым созвоном.

Если ваш сайт взломают и злоумышленники попытаются позвонить кому-то от имени пользователя без его согласия — пользователь увидит уведомление: «Дать доступ к камере и микрофону для звонка?». Он сам этот звонок не начинал, поэтому, скорее всего, откажет — нажмёт «Нет». Это безопасно, но неудобно. Какой процент пользователей перейдёт к конкуренту, чтобы не нажимать «Разрешить» перед каждым звонком?

— Просить доступ к камере и микрофону для проведения созвона с определёнными пользователями.

Звоните пользователю впервые? Увидите уведомление: «Дать доступ к камере и микрофону для звонков... Валерии Николаевой (например)?». Это менее неудобно для пользователя, если он часто звонит одним и тем же. Но всё ещё уступает по удобству программам, которые запрашивают доступ всего один раз.

Известный браузер из надёжного источника

Что это?

Программа, с помощью которой вы заходите на сайты. В браузере работают видеоконференции. Используя его, вы считаете, что браузер безопасен.

Как злоумышленники используют браузер

Внедряют вредоносный код, который выполняет нужные хакеру действия.

Как защититься?

• Не скачивайте браузеры из непроверенных источников.
  Вот список официальных сайтов для самых популярных браузеров:
  Firefox
  Opera
  Google Chrome
  Safari
  Microsoft Edge
• Не пользуйтесь неизвестными браузерами
  Как и со ссылками — если браузер выглядит подозрительно, не скачивайте его.
  Можно дать пользователям своего веб-приложения список надёжных браузеров. Хотя, если они у вас на сайте — они уже используют какой-то браузер… :)

О каких мерах безопасности должен думать сам разработчик?

WebRTC создавался с учётом безопасности. Но безопасность зависит не только от WebRTC — это лишь часть вашего приложения, отвечающая за звонки. Если злоумышленник получит пароль пользователя, WebRTC не сможет его защитить, сколько бы безопасной ни была сама технология. Разберём, как сделать ваше приложение надёжнее.

Сигнальный уровень

Signaling Layer отвечает за обмен данными, необходимыми для установления соединения. Как работает установление соединения, объясняет разработчик — это происходит до того, как включается WebRTC и все её шифрования. По-простому: когда вы находитесь на сайте с видеозвонками, и появляется всплывающее окно: «Вам звонят, принять или отклонить?» — до вашего нажатия на «принять» работает сигнальный уровень, именно он отвечает за установление соединения.

Как злоумышленники могут использовать уровень сигнала и как от этого защититься?

Возможностей сделать это много. Разберём три основные: атака «человек посередине» (Man-in-the-Middle), повторная атака (Replay) и перехват сессии (Session hijacking).

• MitM (Man-in-the-Middle) attack

В контексте WebRTC, это перехват трафика до установления соединения — до того, как начнёт работать шифрование DTLS и SRTP, описанное выше. Между собеседниками находится злоумышленник. Он может подслушивать разговор или, например, отправить в вашу конференцию порнографическое изображение — это называется зумбомбингом.

Это может быть любой злоумышленник, подключённый к той же Wi-Fi или проводной сети, что и вы — он может просматривать и перехватывать весь трафик в вашей Wi-Fi сети или по кабелю.

Как защититься?

Используйте HTTPS, а не HTTP. HTTPS обеспечивает шифрование SSL/TLS на протяжении всей сессии. Атакующий по типу «человек посередине» всё ещё может перехватить ваш трафик, но он будет зашифрован и непонятен. Перехватчик сможет сохранить данные и попробовать расшифровать их позже, но сразу прочитать не сможет.

SSL — Security Sockets Layer — предшественник TLS. Он превращает HTTP в HTTPS, обеспечивая безопасность сайта. Раньше пользователи заходили на сайты по протоколам http и https, не замечая разницы. Сейчас HTTPS — обязательный стандарт: разработчикам нужно защищать свои сайты SSL-сертификатами. Иначе браузеры не пропустят пользователя: покажут тревожное сообщение «ваше соединение не защищено», и только нажав «Подробнее», можно будет перейти на сайт, кликнув «Перейти в любом случае». Не все пользователи решаются на этот шаг, поэтому все разработчики теперь устанавливают SSL-сертификаты на свои сайты.

• Replay attack

Вы защитились от атаки «человек посередине» с помощью HTTPS. Теперь злоумышленник слышит ваши сообщения, но не может их прочитать. Но он их слышит! А значит, может повторить — так называемая атака повторной передачи (replay). Например, вы отправили команду: «перевести 1000 рублей». А злоумышленник, хоть и не понимает содержание, повторяет: «перевести 1000 рублей» — и без дополнительной защиты эта команда будет выполнена. С вас спишут 1000 рублей дважды, и вторая сумма будет отправлена по тому же адресу, что и первая.

Как защититься?

Установить случайный ключ сессии. Этот ключ будет действовать только в течение одной сессии и использовать его можно только один раз. Например: «Перевести 1000 рублей. АВС». Если злоумышленник повторит запрос «Перевести 1000 рублей. АВС», система поймёт, что это дублирующее сообщение, и не выполнит его. Именно так мы реализовали защиту на проекте NextHuddle — сервисе видеоконференций для обучения. NextHuddle рассчитан на 5000 пользователей и 25 стримеров.

• Session hijacking

Похищение сессии — это когда хакер завладевает вашей интернет-сессией. Например, вы звоните в банк, называете своё имя, дату рождения или секретное слово. Вам говорят: «Хорошо, мы вас узнали. Что вы хотите?» — и тут злоумышленник берёт трубку и говорит, что он хочет.

Как защититься?

Используйте HTTPS. Чтобы перехватить сессию, нужно оказаться посредине между пользователем и сервером. Поэтому защита от такого вмешательства автоматически защищает и от перехвата сессии.

Выбор разряда шифрования DTLS

DTLS — это протокол шифрования. В нём используются алгоритмы шифрования, например, AES. У AES есть разные варианты — 128 и более защищённый 256. В WebRTC выбор делает разработчик. Убедитесь, что выбран вариант AES с разрядностью 256 — он обеспечивает максимальную защиту.

Как это делается, можно прочитать, например, в документации Mozilla. Генерируется сертификат, при создании peerconnection передаётся этот сертификат.

Аутентификация и отслеживание участников

Задача разработчика — обеспечить, чтобы все, кто заходит в комнату видеоконференции, имели на это разрешение.

Пример 1 — закрытые комнаты: например, платный видеоурок с учителем. Разработчику нужно запрограммировать проверку: оплатил ли пользователь урок? Если оплатил — пустить, если нет — не пускать.

Это кажется очевидным, но мы не раз сталкивались с ситуацией, когда можно скопировать URL платной конференции, отправить его кому угодно — человек переходит по ссылке и попадает в конференцию, хотя за участие не платил.

Пример 2 — открытые комнаты: например, бизнес-видеоконференции типа «присоединись без регистрации». Это делается для удобства: не нужно заставлять бизнес-партнёра регистрироваться. Просто отправляешь ссылку — человек переходит и сразу попадает в конференцию.

Если участников немного, владелец сам увидит, если кто-то лишний подключился. А если их много — может и не заметить. Один из вариантов — разработчику добавить возможность ручного одобрения новых участников владельцем конференции.

Пример 3 — помощь пользователю защитить логин и пароль. Если злоумышленник узнает логин и пароль, он сможет войти в программу от имени пользователя.

Запрограммируйте вход через сторонние сервисы. Например, через соцсети, Google или Apple на мобильных устройствах. Можно обойтись без пароля — отправлять код для входа на email или телефон. Это уменьшит количество паролей, которые пользователю нужно запоминать. Украсть придётся не пароль от вашего приложения, а пароль от стороннего сервиса — соцсети, учётной записи на устройстве или электронной почты.

Можно использовать два способа сразу — например, логин и пароль от программы плюс код подтверждения на телефон. Тогда для взлома учётной записи злоумышленнику нужно будет получить два пароля, а не один.

‍

Не все пользователи захотят долго и сложно проходить авторизацию, чтобы просто позвонить. Можно предложить выбор: один или два способа входа. Те, кому важна безопасность, выберут двухфакторный — и будут благодарны.

Настройки доступа

Будем честны — мы далеко не всегда внимательно читаем диалоговые окна с настройками доступа. Если пользователь привык просто нажимать «ОК», приложение может получить разрешения, которые он не хотел предоставлять.

Другая крайность — пользователь может удалить приложение, если сразу не поймёт, зачем ему нужны эти разрешения.

Решить просто — проявите заботу. Напишите понятно, какие разрешения вы просите у пользователя и зачем они нужны.

Например, в мобильных приложениях: перед показом стандартного поп-апа с запросом доступа к геолокации — покажите пояснение вроде: «В нашем чате общаются люди поблизости. Разрешите доступ к геолокации, чтобы мы показывали вам собеседников рядом».

Демонстрация экрана

Любое приложение, которое позволяет демонстрировать экран, должно предупреждать пользователя о том, что именно он показывает.

Например, перед сессией скриншеринга, когда пользователь выбирает область экрана, которую будет демонстрировать. Сделайте уведомление-напоминалку, чтобы пользователь случайно не показал данные, которые он не хочет раскрывать. «Что хотите показать?» — и варианты: «— весь экран, — только одно приложение — выберите, какое, например, только браузер».

Если вы разрешили сайту делиться экраном, а сам сайт взломали — злоумышленник может отправить вам скрипт, который откроет в вашем браузере какую-то веб-страницу, пока вы делитесь экраном. Например, он знает, как формируются ссылки на сообщения в соцсети. Он создаёт ссылку на вашу переписку с конкретным человеком, которую хочет посмотреть. Но он не залогинен под вами — поэтому, перейдя по этой ссылке, он не увидит переписку. Однако если он взломал сайт, которому вы разрешили делиться экраном, то в следующий раз, когда вы снова начнёте делиться экраном на этом сайте, он выполнит скрипт, который откроет нужную страницу в вашем браузере. Вы быстро закроете её, но будет уже поздно: скриншот уже передан злоумышленнику. Защита от этого — та же, что и от взлома сервера: беречь пароли. Но это непросто. Поэтому проще не взламывать сайт, а прислать подставную ссылку, запрашивающую доступ к экрану.

Где почитать подробнее о безопасности WebRTC

В интернете много статей о безопасности в WebRTC. У них две проблемы:

1. Они лишь выражают чьё-то субъективное мнение. Наша статья — не исключение. Мнение может оказаться ошибочным.
2. Большинство статей — технические, без опыта в программировании разобраться сложно.

Как решить эти проблемы?

1. Используйте научный метод исследования: читайте первоисточники — публикации, признанные авторитетными. В научной сфере это статьи в журналах, входящих в список ВАК: перед публикацией работу должен одобрить другой учёный из Высшей аттестационной комиссии. В ИТ — это стандарты, утверждённые Консорциумом Всемирной паутины W3C и Инженерным советом Интернета IETF. Перед публикацией такие документы проходят проверку у технических специалистов из Google, Mozilla и других компаний.

2. Документация выше верна, но написана настолько техническим языком, что непонятна человеку без технической подготовки. С большинством статей в интернете — та же ситуация. Поэтому мы написали эту. После её прочтения:

— Основы вам станут понятны (надеемся). Возможно, этого будет достаточно, чтобы принять решение.

— Если нет — первоисточники вам будет понятнее. Координируйтесь с программистом — или обратитесь к нам за советом.

Заключение

‍

Сам WebRTC безопасен. Но если разработчик приложения на основе WebRTC не позаботится о безопасности, его пользователи окажутся в опасности.

Так, в WebRTC все данные, кроме видео и аудио, шифруются с помощью DTLS, а аудио и видео — с помощью SRTP. Но многие параметры безопасности в WebRTC выбирает разработчик видео-приложения: например, как передавать ключи для SRTP — через защищённый канал DTLS или нет.

Далее, WebRTC — это лишь способ передачи данных, когда соединение уже установлено. Что происходит с пользователями до установления соединения — полностью зависит от разработчика: как он запрограммирует, так и будет. Какие исключения из SOP задать, как пускать пользователей в конференцию, использовать ли HTTPS — всё это решает разработчик.

Пишите нам, проверим ваше видео-приложение на безопасность.