![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerВесь интернет буквально бурлит в TLS найдена уязвимость на уровне протокола.
Что же это собственно, за уязвимость? (подробности на английском)
)
Некто, кто ухитрился вклиниться между легитимным клиентом и сервером может перехватив исходный пакет TLS хэндшейка, его задержать, а вместо этого сам установить TLS-соединение с сервером,
передать туда какие-то данные, а потом пропустить исходный пакет, зашифровав его ключами своего соединения. Сервер воспримет это как совершенно легитимный повторный хэндшейк. Договорится уже с клиентом (атакующий должен все дальнейшие пакеты передавать между клиентом и сервером as is).
В процессе нового хэндшейка сервер может потребовать у клиента сертификат и аутентифицировать его.
Вот после этого и начинается засада.
Протокол TLS считается прозрачным для протоколов прикладного уровня. И если у нас в середине протокола случился повторный хэндшейк, по инициативе ли клиента, по инициативе ли сервера, прикладной уровень знать об этом не обязан.
Поэтому в большинстве реализаций HTTPS, после повторого хэндшейка с запросом сертификата, права доступа, соответствующие этому сертификату применяются ко всем данным, переданным по данному соединению, включая и те, которые прилетели до повторного хэндшейка.
Плюс еще особенности HTTP/1.x, позволяющие насовать в запрос сколько угодно непонятных серверу заголовков, которые тот должен проигнорировать.
Если атакующий до повторного хэндшейка передал пакет данных, не содержащий в конце перевода строки, то первая строка запроса клиента, переданная после хэндшейка приклеится к последней строке запроса нехорошего человека. И будет воспринята сервером как один запрос. Который надо выполнить с правами клиента.
Кстати, не обязательно чтобы авторизация требовала сертификата. Basic-Auth сработает точно так же (при условии что атакующему не надо подменять тело запроса, а только первую строчку.
Увидеть результаты запроса атакующий не сможет. Потому что сервер их отдаст зашифрованные теми ключами, которые клиент с ним согласовал при повторном хэндшейке.
Но вот если запрос содержит URL, по которой сервер может изменить какие-то данные, то это может и получиться.
Отсюда мораль:
1. Никогда не делайте на TLS-сайтах форм для изменения данных, передаваемых методом GET.
2. Никогда не делайте на TLS-сайтах такого web-приложения, в котором разные URL с одним и тем же набором POST-параметров могут привести к разным действиям.
3. Обращайте внимание на нестандартные заголовки в запросе. Может иногда стоит отдать клиенту лишний раз 400.
Со всеми остальными протоколами по-моему, значительно проще. Там нет необходимости обрабатывать с новыми правами данные переданные до повторного хэндшейка.
Что же это собственно, за уязвимость? (подробности на английском)
)
Некто, кто ухитрился вклиниться между легитимным клиентом и сервером может перехватив исходный пакет TLS хэндшейка, его задержать, а вместо этого сам установить TLS-соединение с сервером,
передать туда какие-то данные, а потом пропустить исходный пакет, зашифровав его ключами своего соединения. Сервер воспримет это как совершенно легитимный повторный хэндшейк. Договорится уже с клиентом (атакующий должен все дальнейшие пакеты передавать между клиентом и сервером as is).
В процессе нового хэндшейка сервер может потребовать у клиента сертификат и аутентифицировать его.
Вот после этого и начинается засада.
Протокол TLS считается прозрачным для протоколов прикладного уровня. И если у нас в середине протокола случился повторный хэндшейк, по инициативе ли клиента, по инициативе ли сервера, прикладной уровень знать об этом не обязан.
Поэтому в большинстве реализаций HTTPS, после повторого хэндшейка с запросом сертификата, права доступа, соответствующие этому сертификату применяются ко всем данным, переданным по данному соединению, включая и те, которые прилетели до повторного хэндшейка.
Плюс еще особенности HTTP/1.x, позволяющие насовать в запрос сколько угодно непонятных серверу заголовков, которые тот должен проигнорировать.
Если атакующий до повторного хэндшейка передал пакет данных, не содержащий в конце перевода строки, то первая строка запроса клиента, переданная после хэндшейка приклеится к последней строке запроса нехорошего человека. И будет воспринята сервером как один запрос. Который надо выполнить с правами клиента.
Кстати, не обязательно чтобы авторизация требовала сертификата. Basic-Auth сработает точно так же (при условии что атакующему не надо подменять тело запроса, а только первую строчку.
Увидеть результаты запроса атакующий не сможет. Потому что сервер их отдаст зашифрованные теми ключами, которые клиент с ним согласовал при повторном хэндшейке.
Но вот если запрос содержит URL, по которой сервер может изменить какие-то данные, то это может и получиться.
Отсюда мораль:
1. Никогда не делайте на TLS-сайтах форм для изменения данных, передаваемых методом GET.
2. Никогда не делайте на TLS-сайтах такого web-приложения, в котором разные URL с одним и тем же набором POST-параметров могут привести к разным действиям.
3. Обращайте внимание на нестандартные заголовки в запросе. Может иногда стоит отдать клиенту лишний раз 400.
Со всеми остальными протоколами по-моему, значительно проще. Там нет необходимости обрабатывать с новыми правами данные переданные до повторного хэндшейка.
