Не так давно стало известно об уязвимости в iMessage. Как обнаружил незави- симый исследователь Росс Маккиллоп (Ross McKillop), предварительный про- смотр URL раскрывает данные об IP-адресе пользователя, версии ОС и дру- гие данные об устройстве. Причина заключалась в том, что при построении превьюшки запросы отправлялись непосредственно с устройства. Таким об- разом, когда iMessage запрашивал данные о каком-либо сайте, то раскрывал адрес пользователя и сведения о его устройстве.
Более корректная архитектура мессенджера предполагает предваритель- ное кеширование контента на своих серверах и дальнейшую загрузку уже от- туда, как это реализовано, например, в Facebook, Twitter и Skype. Давай раз- беремся, как строится preview по URL в Viber и какие последствия может иметь маленький недочет в проектировании ПО.
Для начала просто отправим сообщение, содержащее корректный URL картинки, размещенной на нашем сервере, например http://host/img.jpg, и посмотрим логи.
{sender_ip} "HEAD /img.jpg HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.6.0 Chrome/45.0.2454.101 Safari/537.36"
{sender_ip} "GET /img.jpg HTTP/1.1" 200 45468 "-" "Dalvik/1.6.0 (Linux; U; Android 4.4.2; GT-N7100 Build/KOT49H)"
{reciever_ip} "GET /img.jpg HTTP/1.1" 200 45468 "-" "Viber/6.5.3.266 CFNetwork/808.1.4 Darwin/16.1.0"
Как видим, iMessage не был исключением, и Viber аналогично скомпромети- ровал IP-адрес получателя сообщения (reciever_ip). Но что будет, если под ви- дом картинки мы попробуем выполнить redirect получателя в произвольном направлении? Вернем код ответа сервера 301 и в HTTP-заголовках укажем поле Location: http://somehost.ru.
{sender_ip} "HEAD /img.jpg HTTP/1.1" 302 0 "-" "Mozilla/5.0
(Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML,
like Gecko) QtWebEngine/5.6.0 Chrome/45.0.2454.101 Safari/537.36"
Лог отличается от предыдущего отсутствием GET-запросов от отправителя и получателя сообщения. С чем это может быть связано? Попробуем в ответ на HEAD вернуть настоящий заголовок картинки, а для GET выполнить перена- правление:
{sender_ip} "HEAD /img.jpg HTTP/1.0" 200 - "-" "Mozilla/5.0
(Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML,
like Gecko) QtWebEngine/5.6.0 Chrome/45.0.2454.101 Safari/537.36"
{sender_ip} "GET /img.jpg HTTP/1.0" 302 - "-" "Dalvik/1.6.0
(Linux; U; Android 4.4.2; GT-N7100 Build/KOT49H)"
{reciever_ip} "GET /img.jpg HTTP/1.0" 302 - "-" "Viber/6.5.3.266
CFNetwork/808.1.4 Darwin/16.1.0"
На этот раз Viber успешно перенаправил обоих участников переписки — это говорит о том, что Viber выполняет верификацию картинки с помощью началь- ного HEAD-запроса.
А теперь давай проведем эксперимент с cookie. Разместим на сервере простой скрипт для генерации картинки со значением из cookie, увеличивая его на единицу при каждом запросе:
http://joxi.ru/l2ZRQebuwaxyW2 смотрите скрин
В .htaccess добавим записи:
http://joxi.ru/eAOYNDBSx75Kem
Отправим два сообщения со ссылками на наш хост, например:
http://somehost.ru/c_08.jpg
и
http://somehost.ru/c_09.jpg
Как видно http://joxi.ru/a2XZGObS17Gkzr, от сообщения к сообщению Viber собирает и хранит выданные ему cookies.
Более корректная архитектура мессенджера предполагает предваритель- ное кеширование контента на своих серверах и дальнейшую загрузку уже от- туда, как это реализовано, например, в Facebook, Twitter и Skype. Давай раз- беремся, как строится preview по URL в Viber и какие последствия может иметь маленький недочет в проектировании ПО.
Для начала просто отправим сообщение, содержащее корректный URL картинки, размещенной на нашем сервере, например http://host/img.jpg, и посмотрим логи.
{sender_ip} "HEAD /img.jpg HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.6.0 Chrome/45.0.2454.101 Safari/537.36"
{sender_ip} "GET /img.jpg HTTP/1.1" 200 45468 "-" "Dalvik/1.6.0 (Linux; U; Android 4.4.2; GT-N7100 Build/KOT49H)"
{reciever_ip} "GET /img.jpg HTTP/1.1" 200 45468 "-" "Viber/6.5.3.266 CFNetwork/808.1.4 Darwin/16.1.0"
Как видим, iMessage не был исключением, и Viber аналогично скомпромети- ровал IP-адрес получателя сообщения (reciever_ip). Но что будет, если под ви- дом картинки мы попробуем выполнить redirect получателя в произвольном направлении? Вернем код ответа сервера 301 и в HTTP-заголовках укажем поле Location: http://somehost.ru.
{sender_ip} "HEAD /img.jpg HTTP/1.1" 302 0 "-" "Mozilla/5.0
(Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML,
like Gecko) QtWebEngine/5.6.0 Chrome/45.0.2454.101 Safari/537.36"
Лог отличается от предыдущего отсутствием GET-запросов от отправителя и получателя сообщения. С чем это может быть связано? Попробуем в ответ на HEAD вернуть настоящий заголовок картинки, а для GET выполнить перена- правление:
{sender_ip} "HEAD /img.jpg HTTP/1.0" 200 - "-" "Mozilla/5.0
(Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML,
like Gecko) QtWebEngine/5.6.0 Chrome/45.0.2454.101 Safari/537.36"
{sender_ip} "GET /img.jpg HTTP/1.0" 302 - "-" "Dalvik/1.6.0
(Linux; U; Android 4.4.2; GT-N7100 Build/KOT49H)"
{reciever_ip} "GET /img.jpg HTTP/1.0" 302 - "-" "Viber/6.5.3.266
CFNetwork/808.1.4 Darwin/16.1.0"
На этот раз Viber успешно перенаправил обоих участников переписки — это говорит о том, что Viber выполняет верификацию картинки с помощью началь- ного HEAD-запроса.
А теперь давай проведем эксперимент с cookie. Разместим на сервере простой скрипт для генерации картинки со значением из cookie, увеличивая его на единицу при каждом запросе:
http://joxi.ru/l2ZRQebuwaxyW2 смотрите скрин
В .htaccess добавим записи:
http://joxi.ru/eAOYNDBSx75Kem
Отправим два сообщения со ссылками на наш хост, например:
http://somehost.ru/c_08.jpg
и
http://somehost.ru/c_09.jpg
Как видно http://joxi.ru/a2XZGObS17Gkzr, от сообщения к сообщению Viber собирает и хранит выданные ему cookies.