Внимание: Все описанные ниже действия являются вымыслом. Все совпадения случайны, соблюдайте разумность и этику!
Моя жена проходила продвинутые фонетические курсы английского языка и спросила меня, можно ли скачать учебные видео, поскольку после курса доступ к ним будет закрыт.
Стандартными плагинами для браузера скачать видео не получалось, и, поскольку, до этого опыта работы с подобными сервисами у меня не было (кроме использования их по прямому назначению), мне пришлось потратить вечер, дабы понять, как же работает этот чудо-плеер.
Поковыряв код плеера и изучив запросы в Burp Suite, я определил, что при каждой загрузке нового видео плеер на сайте скачивает файл манифеста и оттуда получает данные на файл плейлиста в формате m3u8.
Открыв данный файл в блокноте, мы увидим отдельные ссылки на видео и на аудио. Да, эти данные хранятся отдельно друг от друга, но плеер комбинирует их в выводимом на экран видео. Таким образом, через плеер мы можем менять качество картинки, язык озвучки и т.п.
Имея данный плейлист, мы можем использовать программу FFmpeg, которая "соберёт" нам видео и аудио в единый файл и сохранит на компьютере.
Разобравшись с видео, я мог бы забросить этот сервис, но меня привлекла реклама этого видеосервиса и то, как они позиционируют свой продукт.
Данная компания рекламирует себя как российский аналог Vimeo. Компания продаёт свои услуги, сильно ориентируясь на онлайн-школы или преподавателей с авторскими курсами.
Одним из своих преимуществ сервис считает свой плеер с защитой от скачивания и приватными настройками.
Но я же получил доступ к видео, значит, не всё так гладко на сервисе, это и было отправной точкой моего небольшого исследования.
Однако совершенно случайно я наткнулся на видео, которое загрузили разработчики сервиса, где они в режиме конференции общались с представителем какого-то онлайн издания и рассказывали о преимуществах своего сервиса, дальнейших планах развития и прочих фишках, которые должны выделять их на фоне остальных сервисов. Видео было открыто абсолютно для всех, кто введёт правильный номер в адресной строке браузера.
Вдумайтесь в это: сами разработчики сервиса забыли ограничить доступ к видео с довольно чувствительной информацией, что уж говорить про пользователей, которые могут преподавать, скажем, рисование. Они тем более могут над этим не задуматься. Но вернёмся к изучению платформы.
Дабы понять, какие настройки приватности существуют у сервиса, я зарегистрировал тестовый аккаунт и начал изучать панель администратора. К моему удивлению, на момент первой проверки владелец видеоматериалов мог поставить только 3 режима доступа к видео:
Мысль довольно интересная, поскольку ранее полученные видео я как раз просматривал со страниц курса, который, правда, был зарегистрирован на одной популярной отечественной платформе по созданию онлайн-школ.
Изучив чуть более внимательно логи в Burp Suite, я обратил внимание, что в пакетах, отправляемых с сайта школы, к сайту плеера присутствует дополнительный хедер Referer, а значение этого заголовка содержало адрес страницы, с которой мы собирались просматривать видео.
Получив дополнительную информацию, я повторно проверил предыдущие 30 тестовых ссылок, добавив в Referer только домен второго уровня на эту популярную платформу по созданию онлайн-школ. И теперь я смог получить доступ дополнительно ещё к 5 плеерам, а, заменив, в Referer адрес на ещё один известный портал с онлайн уроками, я получил доступ ещё к 3-м видео.
То есть, из 30 тестовых ссылок я смог получить доступ к 18-ти, просто имея на руках номера видео (которые идут по порядку) и угадав Referer.
Но меня это не очень устраивало, поскольку на данной платформе размещались видео не только онлайн-школ, да и вариант с перебором различных доменов в Referer мне казался не самым оптимальным. К тому же, у нас оставался 3-й режим приватности, когда никто не должен иметь доступа к просмотру видео.
И тут я хочу заострить внимание на одном очень показательном случае, доказывающем, насколько важно быть внимательным при анализе имеющихся данных. Сколько раз я сам себя загонял в дебри, когда, решая задания на курсах WAPT и SQLiM нашей школы (можете считать это рекламой) или задания на курсе подготовки к сдаче OSCP (а это рекламой не считайте), я что-то упускал из виду. Даже самая мелкая деталь, которая ускользнёт от вас, может быть очень важной, и без неё вы либо застрянете на одном месте очень надолго, либо вообще полностью увязните и уже не выберетесь.
Решив, что разработчики сервиса один раз уже использовали значение из HTTP заголовка Referer в качестве проверочного механизма, я решил перепроверить запросы, которые отправляет плеер для получения файла M3U8. И каково было моё удивление, когда я обнаружил в GET запросе на получение файла m3u8 Referer, в котором был указан адрес самого видеосервиса. То есть, без этого Referer сайт выдавал нам ошибку 403, а с "правильным" Referer легко отдавал любой файл m3u8.
Окрылённый данным открытием, я кинулся проверять мои 30 тестовых ссылок и, к моему удивлению, по 28 из них я мог скачать файл M3U8. Остальные 2 ссылки сообщали, что файлов не существует, то есть, их попросту удалили с видеохостинга.
Для подтверждения своих выводов я загрузил несколько тестовых видео на видеохостинг и убедился, что теперь никакие настройки приватности не мешают мне скачивать файл M3U8.
А поскольку у нас есть замечательный инструмент ffmpeg, мы можем получить доступ к любому конфиденциальному видео, просто его скачав, и никакой онлайн плеер нам не нужен!
Сделав вывод, что любой пользователь может скачивать абсолютно любое видео, даже то, которое никто не должен был видеть, я решил, что это довольно интересная брешь в системе безопасности сервиса и ей можно поделиться с разработчиками. Подумал вдруг спасибо скажут. (ага, потом догонят и ещё раз скажут)
Но после этого у меня возникла большая дилемма. Дело было в том, что компания, владеющая данным видеосервисом, зарегистрирована в России и, к сожалению, в нашей стране за информирование о найденных уязвимостях чаще бьют по рукам, чем говорят спасибо.
Поразмыслив неделю и посоветовавшись с коллегами с этого форму, я всё же решил написать одному сооснователю компании в LinkedIn. Но дабы немного обезопасить себя решил зайти с вопросом издалека: уточнил у него про наличие закрытой программы Bug Bounty и про возможность изучить сервис на уязвимости.
Через день он мне ответил, что сервис только-только начал развиваться, компания молодая, бюджетов и программ на поиск уязвимостей у них нет, но, если я найду что-то интересное, то могу с ними поделиться - они подумают, что с этим можно будет сделать. После чего выдал мне адрес корпоративной почты и предложил отправить отчёт на неё.
Собрав все данные, что у меня имелись, я подготовил небольшой отчёт, отправил его на указанную почту и стал ждать.
После 10 дней без ответа я напомнил о себе и мне сообщили, моя найденная уязвимость — это неуязвимость.
В этот момент я не очень хорошо понимал, о чём он говорит и решил, что, возможно, мой отчёт был недостаточно хорош и не отражал сути проблемы. Возможно, изучив его, они не поняли, что проблема не в том, что видео можно скачать, а в том, что можно получить доступ к закрытому контенту путём скачивания видео.
Для подготовки контраргументов я решил потратить ещё пару дней на изучение сервиса. И к моему удивлению, на сервисе появилось ещё 2 механизма ограничения доступа к видео!
Первый из новых механизмов представлял собой доступ к видеоплееру по уникальной ссылке. Владельцу видео предлагалось создать уникальную ссылку вида
Второй механизм представлял из себя доступ к просмотру видеоплеера только после ввода пароля. Тут всё довольно просто, ввёл пароль – смотри видео.
Загрузив ещё пару тестовых видео, я убедился, что и новые механизмы ограничения доступа никак не влияют на возможность получения файла M3U8 через указания "правильного" Referer.
Собрав новые данные и расписав более подробно информацию о потенциальных утечках авторского контента с их платформы, я отправил им повторное письмо.
Примерно через неделю я получил от них ответ, в котором они ссылались на свою статью про использование механизма DRM для стримингового видео.
И только после этого я понял, что не проверил самое главное. Во время тестов я не пробовал скачивать видео с помощью полученных файлов m3u8. Разработчики сообщили мне, что на некоторые видео, по запросу пользователя, включается DRM защита и, даже имея ссылки на видео и аудио потоки, мы не сможем их скачать.
Получив ссылку на видео с включенной DRM защитой, я потратил несколько дней, но так и не смог её обойти или получить возможность просмотра видео в обход механизмов разграничения.
Конечно, когда мы натыкаемся на видео с включенной DRM защитой от скачивания, остаётся вариант получить доступ к видео плееру, угадав Referer и, тем самым, просто посмотреть видео онлайн. Однако сработает только при совпадении двух условий:
Статистика получилась очень интересная. Мной было проверено 1500 ссылок, из которых 1207 (80,5%) были рабочие, то есть, файлы не были удалены с видеохостинга, и мне успешно удалось скачать файлы m3u8.
Далее, эти ссылки на файлы плейлистов m3u8 проверялись на наличие DRM защиты с помощью FFmpeg. FFmpeg не умеет качать видео с DRM защитой и будет выдавать ошибку, если мы подсунем ему файл с ссылками на закодированные потоки.
Ну и в качестве дополнения я проверял возможность просмотра видео без скачивания. От сайта я мог получить только 4 состояния:
Статистика по данной выборке показывает, что более 80% видео с уникальным контентом, доступ к которому владелец скорее всего хотел-бы ограничить и не распространять его среди людей не оплативших курсы, доступны.
Да, это не так удобно как открыть плеер и начать смотреть видео. Да, мы не сможем никак узнать название видео или о чём оно до того, как его скачаем.
Но по факту мы видим потенциальную возможность утечки пользовательского контента.
Понятное дело, что жестко опираться на данную статистику мы не можем, у меня была сделана не такая большая выборка. Плюс, конечно, в ней, скорее всего, есть какие-то тестовые или левые видео, которые не несут ценности и не могут быть рассмотрены в виде потенциальной потери интеллектуальной собственности авторов.
Но, тем не менее, исходя из этой статистики, мы можем сделать вывод, что пользователи не очень часто используют DRM защиту. Возможно, потому, что эта функция платная (но это не точно), возможно, из-за незнания о наличии такой функции. Однако, в отличие от того же Youtube, куда пользователи могут загружать совершенно разные видео, данный сервис позиционирует себя как платформу для размещения видеоуроков разных онлайн-школ или частных преподавателей (и не только). То есть, контент на нём может считаться более ценным, чем просто видео с котиками.
В данный момент я вижу только один вариант, который позволит авторам максимально обезопасить свой контент от просмотра (не скачивания, копирования или записи с экрана) левыми людьми – включить DRM защиту на все видео + включить настройки приватности в режим «Доступ по уникальной ссылке». Но даже так я не могу утверждать на 100%, что видео будет в безопасности. Возможно, кто-то другой сможет расковырять данный сервис больше, чем я.
Видимо, разработчики считают, что полная ответственность за хранение и разграничение доступа к видео несут авторы контента, поскольку все необходимые механизмы для организации приватного доступа есть.
Изучив публичные репорты Vimeo на портале H1 я прикинул, что мог бы, наверное, получить за подобную уязвимость около 500 баксов:
Хотя, если честно, я был бы рад даже простой благодарности в моём профиле LinkedIn от официального профиля компании этого сервиса за попытку сделать их продукт безопаснее.
На мой вопрос о возможности публикации данного исследования я прямого запрета не получил, но всё же решил, что не буду публично сообщать название данного видео сервиса.
Но, как говорится, нет худа без добра. Это был мой первый опыт в ковырянии публичного сервиса на наличие уязвимостей, мои почки всё ещё целые и функционируют, а товарищ майор не бегает за мной с бутылкой, так что я считаю, что это - отличный результат)
К сожалению, российский IT-бизнес всё ещё не готов к работе с подобного рода проблемами. Последствия от инцидентов с ИБ в нашей стране особо никого не волнуют. И если крупные IT-компании спокойно выходят сухими из воды, оплатив мизерный штраф за утечку персональных данных и особо не получив репутационных потерь, то и мелкие, начинающие свой путь, IT-компании не будут об этом задумываться. Как в нашей стране обычно происходит - всё спускают на авось)
Хотя, кто знает, возможно, информация о подобных уязвимостях в руках компании конкурента могла бы быть использована для подрыва репутации сервиса, и тогда стартап мог бы загнуться на ранних этапах своего становления.
Надеюсь, данный рассказ приоткрыл небольшую завесу поиска уязвимостей для начинающих.
Помните, что ковырять чужие сервисы без разрешения нельзя!
P. S. К слову о HTTP заголовках: вы слышали, что они бывают уязвимы для SQL-инъекции? У нас на курсе «SQL-injection Master» есть отдельный блок, посвящённой этой теме. Тема непростая, но очень интересная!
Почитать о курсах можно на сайте школы или по ссылкам ниже
0. Введение
Эта история началась совершенно случайно.Моя жена проходила продвинутые фонетические курсы английского языка и спросила меня, можно ли скачать учебные видео, поскольку после курса доступ к ним будет закрыт.
Стандартными плагинами для браузера скачать видео не получалось, и, поскольку, до этого опыта работы с подобными сервисами у меня не было (кроме использования их по прямому назначению), мне пришлось потратить вечер, дабы понять, как же работает этот чудо-плеер.
Расширение M3U8 – это файл плейлиста, используемый различными программами воспроизведения аудио и видео файлов. Используется тот же формат, что и в файле M3U, только текст хранится в кодировке UTF-8.
Один из самых распространённых способов использования формата M3U — создание плейлистов, содержащих одну единственную запись, ведущую на потоковое мультимедиа-вещание в Интернете. Такой файл предоставляет возможность легко обменяться ссылкой на потоковое вещание по электронной почте, через файлообменные сети или прямой загрузки видеопотока в веб-плеер.
Один из самых распространённых способов использования формата M3U — создание плейлистов, содержащих одну единственную запись, ведущую на потоковое мультимедиа-вещание в Интернете. Такой файл предоставляет возможность легко обменяться ссылкой на потоковое вещание по электронной почте, через файлообменные сети или прямой загрузки видеопотока в веб-плеер.
Открыв данный файл в блокноте, мы увидим отдельные ссылки на видео и на аудио. Да, эти данные хранятся отдельно друг от друга, но плеер комбинирует их в выводимом на экран видео. Таким образом, через плеер мы можем менять качество картинки, язык озвучки и т.п.
Имея данный плейлист, мы можем использовать программу FFmpeg, которая "соберёт" нам видео и аудио в единый файл и сохранит на компьютере.
Разобравшись с видео, я мог бы забросить этот сервис, но меня привлекла реклама этого видеосервиса и то, как они позиционируют свой продукт.
Данная компания рекламирует себя как российский аналог Vimeo. Компания продаёт свои услуги, сильно ориентируясь на онлайн-школы или преподавателей с авторскими курсами.
Одним из своих преимуществ сервис считает свой плеер с защитой от скачивания и приватными настройками.
Но я же получил доступ к видео, значит, не всё так гладко на сервисе, это и было отправной точкой моего небольшого исследования.
1. Этап первый
Первым делом я обратил внимание, что все адреса на видео имеют числовой идентификатор, состоящий из 8 цифр. Поэтому первым делом сразу напрашивался IDOR: проверив порядка 30 ссылок, мне удалось получить доступ примерно к 10 плеерам, остальные ссылки приводили меня к странице с ошибкой, которая сообщала, что доступ к видео ограничен.Однако совершенно случайно я наткнулся на видео, которое загрузили разработчики сервиса, где они в режиме конференции общались с представителем какого-то онлайн издания и рассказывали о преимуществах своего сервиса, дальнейших планах развития и прочих фишках, которые должны выделять их на фоне остальных сервисов. Видео было открыто абсолютно для всех, кто введёт правильный номер в адресной строке браузера.
Вдумайтесь в это: сами разработчики сервиса забыли ограничить доступ к видео с довольно чувствительной информацией, что уж говорить про пользователей, которые могут преподавать, скажем, рисование. Они тем более могут над этим не задуматься. Но вернёмся к изучению платформы.
Дабы понять, какие настройки приватности существуют у сервиса, я зарегистрировал тестовый аккаунт и начал изучать панель администратора. К моему удивлению, на момент первой проверки владелец видеоматериалов мог поставить только 3 режима доступа к видео:
- Доступ к видеоплееру для всех
- Доступ к видеоплееру с определенного домена
- Никому не показывать
Мысль довольно интересная, поскольку ранее полученные видео я как раз просматривал со страниц курса, который, правда, был зарегистрирован на одной популярной отечественной платформе по созданию онлайн-школ.
Изучив чуть более внимательно логи в Burp Suite, я обратил внимание, что в пакетах, отправляемых с сайта школы, к сайту плеера присутствует дополнительный хедер Referer, а значение этого заголовка содержало адрес страницы, с которой мы собирались просматривать видео.
Заголовок запроса Referer содержит URL исходной страницы, с которой был осуществлён переход на текущую страницу. Заголовок Referer позволяет серверу узнать, откуда был осуществлён переход на запрашиваемую страницу. Сервер может анализировать эти данные, записывать их в логи или оптимизировать процесс кеширования.
Получив дополнительную информацию, я повторно проверил предыдущие 30 тестовых ссылок, добавив в Referer только домен второго уровня на эту популярную платформу по созданию онлайн-школ. И теперь я смог получить доступ дополнительно ещё к 5 плеерам, а, заменив, в Referer адрес на ещё один известный портал с онлайн уроками, я получил доступ ещё к 3-м видео.
То есть, из 30 тестовых ссылок я смог получить доступ к 18-ти, просто имея на руках номера видео (которые идут по порядку) и угадав Referer.
Но меня это не очень устраивало, поскольку на данной платформе размещались видео не только онлайн-школ, да и вариант с перебором различных доменов в Referer мне казался не самым оптимальным. К тому же, у нас оставался 3-й режим приватности, когда никто не должен иметь доступа к просмотру видео.
И тут я хочу заострить внимание на одном очень показательном случае, доказывающем, насколько важно быть внимательным при анализе имеющихся данных. Сколько раз я сам себя загонял в дебри, когда, решая задания на курсах WAPT и SQLiM нашей школы (можете считать это рекламой) или задания на курсе подготовки к сдаче OSCP (а это рекламой не считайте), я что-то упускал из виду. Даже самая мелкая деталь, которая ускользнёт от вас, может быть очень важной, и без неё вы либо застрянете на одном месте очень надолго, либо вообще полностью увязните и уже не выберетесь.
Решив, что разработчики сервиса один раз уже использовали значение из HTTP заголовка Referer в качестве проверочного механизма, я решил перепроверить запросы, которые отправляет плеер для получения файла M3U8. И каково было моё удивление, когда я обнаружил в GET запросе на получение файла m3u8 Referer, в котором был указан адрес самого видеосервиса. То есть, без этого Referer сайт выдавал нам ошибку 403, а с "правильным" Referer легко отдавал любой файл m3u8.
Окрылённый данным открытием, я кинулся проверять мои 30 тестовых ссылок и, к моему удивлению, по 28 из них я мог скачать файл M3U8. Остальные 2 ссылки сообщали, что файлов не существует, то есть, их попросту удалили с видеохостинга.
Для подтверждения своих выводов я загрузил несколько тестовых видео на видеохостинг и убедился, что теперь никакие настройки приватности не мешают мне скачивать файл M3U8.
А поскольку у нас есть замечательный инструмент ffmpeg, мы можем получить доступ к любому конфиденциальному видео, просто его скачав, и никакой онлайн плеер нам не нужен!
Сделав вывод, что любой пользователь может скачивать абсолютно любое видео, даже то, которое никто не должен был видеть, я решил, что это довольно интересная брешь в системе безопасности сервиса и ей можно поделиться с разработчиками. Подумал вдруг спасибо скажут. (ага, потом догонят и ещё раз скажут)
Но после этого у меня возникла большая дилемма. Дело было в том, что компания, владеющая данным видеосервисом, зарегистрирована в России и, к сожалению, в нашей стране за информирование о найденных уязвимостях чаще бьют по рукам, чем говорят спасибо.
Поразмыслив неделю и посоветовавшись с коллегами с этого форму, я всё же решил написать одному сооснователю компании в LinkedIn. Но дабы немного обезопасить себя решил зайти с вопросом издалека: уточнил у него про наличие закрытой программы Bug Bounty и про возможность изучить сервис на уязвимости.
Через день он мне ответил, что сервис только-только начал развиваться, компания молодая, бюджетов и программ на поиск уязвимостей у них нет, но, если я найду что-то интересное, то могу с ними поделиться - они подумают, что с этим можно будет сделать. После чего выдал мне адрес корпоративной почты и предложил отправить отчёт на неё.
Собрав все данные, что у меня имелись, я подготовил небольшой отчёт, отправил его на указанную почту и стал ждать.
После 10 дней без ответа я напомнил о себе и мне сообщили, моя найденная уязвимость — это неуязвимость.
2. Второй этап
Сооснователь компании сообщил мне, что доступ к файлу m3u8 не является уязвимостью, что вообще защититься на 100% от утечки видео нельзя. Ведь можно записать видео с экрана, или вообще поставить видео камеру напротив монитора. Но, в отличие от Vimeo, у них на сервисе есть механизмы, блокирующие скачивание видео.В этот момент я не очень хорошо понимал, о чём он говорит и решил, что, возможно, мой отчёт был недостаточно хорош и не отражал сути проблемы. Возможно, изучив его, они не поняли, что проблема не в том, что видео можно скачать, а в том, что можно получить доступ к закрытому контенту путём скачивания видео.
Для подготовки контраргументов я решил потратить ещё пару дней на изучение сервиса. И к моему удивлению, на сервисе появилось ещё 2 механизма ограничения доступа к видео!
Первый из новых механизмов представлял собой доступ к видеоплееру по уникальной ссылке. Владельцу видео предлагалось создать уникальную ссылку вида
https://имявидеосервиса/номервидео/наборсмиволов
и распространять её. Таким образом, видеоплеер могли посмотреть только те пользователи, которые имели данную уникальную ссылку.Второй механизм представлял из себя доступ к просмотру видеоплеера только после ввода пароля. Тут всё довольно просто, ввёл пароль – смотри видео.
Загрузив ещё пару тестовых видео, я убедился, что и новые механизмы ограничения доступа никак не влияют на возможность получения файла M3U8 через указания "правильного" Referer.
Собрав новые данные и расписав более подробно информацию о потенциальных утечках авторского контента с их платформы, я отправил им повторное письмо.
Примерно через неделю я получил от них ответ, в котором они ссылались на свою статью про использование механизма DRM для стримингового видео.
И только после этого я понял, что не проверил самое главное. Во время тестов я не пробовал скачивать видео с помощью полученных файлов m3u8. Разработчики сообщили мне, что на некоторые видео, по запросу пользователя, включается DRM защита и, даже имея ссылки на видео и аудио потоки, мы не сможем их скачать.
Конечно, когда мы натыкаемся на видео с включенной DRM защитой от скачивания, остаётся вариант получить доступ к видео плееру, угадав Referer и, тем самым, просто посмотреть видео онлайн. Однако сработает только при совпадении двух условий:
- У видео включен режим доступа только с определенного домена
- Мы угадаем нужный домен
3. Выводы и статистика
Поняв свой косяк, я решил заручиться цифрами статистики и написал небольшой скрипт, который проверял большой список ссылок на возможность скачивать файл плейлиста m3u8, а после пробовать скачивать видео. Таким образом я хотел понять картину, насколько сильно покрывается защита контента авторов на видеосервисе.Статистика получилась очень интересная. Мной было проверено 1500 ссылок, из которых 1207 (80,5%) были рабочие, то есть, файлы не были удалены с видеохостинга, и мне успешно удалось скачать файлы m3u8.
Далее, эти ссылки на файлы плейлистов m3u8 проверялись на наличие DRM защиты с помощью FFmpeg. FFmpeg не умеет качать видео с DRM защитой и будет выдавать ошибку, если мы подсунем ему файл с ссылками на закодированные потоки.
Ну и в качестве дополнения я проверял возможность просмотра видео без скачивания. От сайта я мог получить только 4 состояния:
- Плеер загружается и есть возможность посмотреть видео (видео общедоступно)
- Плеер загружается, но для просмотра просит ввести пароль (включена защита по паролю)
- Плеер не загружается, сайт выдаёт ошибку доступа к видео (видео доступно по специальной ссылки, или доступно с определенного домена, или вообще никому не доступно для просмотра)
- Сайт выдаёт ошибку, что файла не существует (скорее всего файл был удален владельцем)
Статистика по данной выборке показывает, что более 80% видео с уникальным контентом, доступ к которому владелец скорее всего хотел-бы ограничить и не распространять его среди людей не оплативших курсы, доступны.
Да, это не так удобно как открыть плеер и начать смотреть видео. Да, мы не сможем никак узнать название видео или о чём оно до того, как его скачаем.
Но по факту мы видим потенциальную возможность утечки пользовательского контента.
Некоторые видео с DRM защитой были доступны к прямому просмотру плеера просто по номеру видео - странное решение.
Понятное дело, что жестко опираться на данную статистику мы не можем, у меня была сделана не такая большая выборка. Плюс, конечно, в ней, скорее всего, есть какие-то тестовые или левые видео, которые не несут ценности и не могут быть рассмотрены в виде потенциальной потери интеллектуальной собственности авторов.
Но, тем не менее, исходя из этой статистики, мы можем сделать вывод, что пользователи не очень часто используют DRM защиту. Возможно, потому, что эта функция платная (но это не точно), возможно, из-за незнания о наличии такой функции. Однако, в отличие от того же Youtube, куда пользователи могут загружать совершенно разные видео, данный сервис позиционирует себя как платформу для размещения видеоуроков разных онлайн-школ или частных преподавателей (и не только). То есть, контент на нём может считаться более ценным, чем просто видео с котиками.
В данный момент я вижу только один вариант, который позволит авторам максимально обезопасить свой контент от просмотра (не скачивания, копирования или записи с экрана) левыми людьми – включить DRM защиту на все видео + включить настройки приватности в режим «Доступ по уникальной ссылке». Но даже так я не могу утверждать на 100%, что видео будет в безопасности. Возможно, кто-то другой сможет расковырять данный сервис больше, чем я.
4. Заключение
К сожалению, к моменту сбора статистики диалог с разработчиками сервиса уже был завершен, мои доводы о том, что часть контента не находится под защитой DRM и что с помощью скачивания видео можно получить доступ к видео с включенными настройками приватности, не были восприняты с должной серьезностью.Видимо, разработчики считают, что полная ответственность за хранение и разграничение доступа к видео несут авторы контента, поскольку все необходимые механизмы для организации приватного доступа есть.
Изучив публичные репорты Vimeo на портале H1 я прикинул, что мог бы, наверное, получить за подобную уязвимость около 500 баксов:
-
Ссылка скрыта от гостей
-
Ссылка скрыта от гостей
-
Ссылка скрыта от гостей
На мой вопрос о возможности публикации данного исследования я прямого запрета не получил, но всё же решил, что не буду публично сообщать название данного видео сервиса.
Но, как говорится, нет худа без добра. Это был мой первый опыт в ковырянии публичного сервиса на наличие уязвимостей, мои почки всё ещё целые и функционируют, а товарищ майор не бегает за мной с бутылкой, так что я считаю, что это - отличный результат)
К сожалению, российский IT-бизнес всё ещё не готов к работе с подобного рода проблемами. Последствия от инцидентов с ИБ в нашей стране особо никого не волнуют. И если крупные IT-компании спокойно выходят сухими из воды, оплатив мизерный штраф за утечку персональных данных и особо не получив репутационных потерь, то и мелкие, начинающие свой путь, IT-компании не будут об этом задумываться. Как в нашей стране обычно происходит - всё спускают на авось)
Хотя, кто знает, возможно, информация о подобных уязвимостях в руках компании конкурента могла бы быть использована для подрыва репутации сервиса, и тогда стартап мог бы загнуться на ранних этапах своего становления.
Надеюсь, данный рассказ приоткрыл небольшую завесу поиска уязвимостей для начинающих.
Помните, что ковырять чужие сервисы без разрешения нельзя!
P. S. К слову о HTTP заголовках: вы слышали, что они бывают уязвимы для SQL-инъекции? У нас на курсе «SQL-injection Master» есть отдельный блок, посвящённой этой теме. Тема непростая, но очень интересная!
Почитать о курсах можно на сайте школы или по ссылкам ниже
Последнее редактирование: