Контрабанда HTTP-запросов кратко

Что происходит при атаке контрабандой HTTP-запроса?

Современные веб-приложения часто используют цепочки HTTP-серверов между пользователями и конечную логику приложения. Пользователи отправляют запросы на внешний сервер (иногда называемый балансировщиком нагрузки или обратным прокси-сервером), и этот сервер направляет запросы на один или несколько внутренних серверов. Этот тип архитектуры становится все более распространенным, а в некоторых случаях неизбежным, в современных облачных приложениях.

Когда интерфейсный сервер пересылает HTTP-запросы на внутренний сервер, он обычно отправляет несколько запросов по одному и тому же внутреннему сетевому соединению, поскольку это гораздо более эффективно и эффективно. Протокол очень прост: HTTP-запросы отправляются один за другим, а принимающий сервер анализирует заголовки HTTP-запросов, чтобы определить, где заканчивается один запрос и начинается следующий:

В этой ситуации крайне важно, чтобы интерфейсные и фоновые системы согласовывали границы между запросами. В противном случае злоумышленник может отправить двусмысленный запрос, который по-разному интерпретируется интерфейсной и серверной системами:

Здесь злоумышленник заставляет часть своего запроса переднего плана быть интерпретированным внутренним сервером как начало следующего запроса. Он эффективно добавляется к следующему запросу и может мешать тому, как приложение обрабатывает этот запрос. Это атака по контрабанде запросов, которая может иметь разрушительные последствия.

Как возникают уязвимости в контрабанде HTTP-запросов?

Большинство уязвимостей, связанных с контрабандой HTTP-запросов, возникают из-за того, что спецификация HTTP предоставляет два разных способа указать, где заканчивается запрос: 

заголовок и 

заголовок.

Заголовок прост: он определяет длину тела сообщения в байтах. Например:

Заголовок может использоваться для указания того, что использует тело сообщения фрагментированного кодирования. Это означает, что тело сообщения содержит один или несколько фрагментов данных. Каждый чанк состоит из размера чанка в байтах (выраженного в шестнадцатеричном формате), за которым следует новая строка, за которой следует содержимое чанка. Сообщение заканчивается фрагментом нулевого размера. Например:

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

и 

заголовки присутствуют, то 

заголовок должен быть проигнорирован. Этого может быть достаточно, чтобы избежать двусмысленности, когда в игре находится только один сервер, но не когда два или более серверов объединены в цепочку. В этой ситуации проблемы могут возникнуть по двум причинам:

• Некоторые серверы не поддерживают 
  Transfer-Encoding
  заголовок в запросах.
• Некоторые серверы, которые поддерживают 
  Transfer-Encoding
  заголовок, могут не обрабатывать его, если заголовок каким-то образом запутан.

Если внешние и внутренние серверы ведут себя по-разному по отношению к (возможно, запутанному) 

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

Как выполнить атаку контрабанды HTTP-запроса

Атаки на контрабанду запросов включают в себя размещение как 

заголовка, так и 

 заголовка в одном HTTP-запросе и манипулирование ими, чтобы внешние и внутренние серверы обрабатывали запрос по-разному. Точный способ, которым это делается, зависит от поведения двух серверов:

• CL.TE: внешний сервер использует 
  Content-Length
  заголовок, а внутренний сервер использует 
  Transfer-Encoding
  заголовок.
• TE.CL: внешний сервер использует 
  Transfer-Encoding
  заголовок, а внутренний сервер использует 
  Content-Length
  заголовок.
• TE.TE: интерфейсные и фоновые серверы поддерживают 
  Transfer-Encoding
  заголовок, но один из серверов может быть вынужден не обрабатывать его, каким-либо образом запутывая заголовок.

Уязвимости CL.TE

Здесь интерфейсный сервер использует 

заголовок, а внутренний сервер использует 

заголовок. Мы можем выполнить простую атаку контрабанды HTTP-запроса следующим образом:

Интерфейсный сервер обрабатывает 

заголовок и определяет, что тело запроса имеет длину 13 байтов до конца 

. Этот запрос перенаправляется на внутренний сервер.

Внутренний сервер обрабатывает 

заголовок и обрабатывает тело сообщения с использованием чанкованного кодирования. Он обрабатывает первый блок, который указан как нулевая длина, и поэтому обрабатывается как завершение запроса. Следующие байты, 

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

TE.CL уязвимости

Здесь интерфейсный сервер использует 

заголовок, а внутренний сервер использует 

заголовок. Мы можем выполнить простую атаку контрабанды HTTP-запроса следующим образом:

Интерфейсный сервер обрабатывает 

заголовок и обрабатывает тело сообщения с использованием чанкованного кодирования. Он обрабатывает первый блок длиной 8 байтов до начала следующей строки 

. Он обрабатывает второй блок, который указан как нулевая длина, и поэтому обрабатывается как завершение запроса. Этот запрос перенаправляется на внутренний сервер.

Внутренний сервер обрабатывает 

заголовок и определяет, что тело запроса имеет длину 3 байта, до начала следующей строки 

. Следующие байты, начиная с 

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

Поведение TE.TE: запутывание заголовка TE

Здесь и внешний, и внутренний серверы поддерживают 

заголовок, но можно заставить один из серверов не обрабатывать его, каким-либо образом запутывая заголовок.

Есть потенциально бесконечные способы запутать 

заголовок. Например:

Каждый из этих методов включает тонкий отступ от спецификации HTTP. Реальный код, который реализует спецификацию протокола, редко придерживается его с абсолютной точностью, и для разных реализаций характерно допускать различные отклонения от спецификации. Чтобы обнаружить уязвимость TE.TE, необходимо найти какой-то вариант 

заголовка, который обрабатывает только один из внешних или внутренних серверов, а другой игнорирует его.

В зависимости от того, будет ли это 

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

Как предотвратить уязвимости, связанные с контрабандой HTTP-запросов

Уязвимости в контрабанде HTTP-запросов возникают в тех случаях, когда интерфейсный сервер пересылает несколько запросов на внутренний сервер по одному и тому же сетевому соединению, а протокол, используемый для внутренних соединений, несет в себе риск того, что два сервера не согласятся относительно границ между Запросы. Ниже перечислены некоторые общие способы предотвращения возникновения уязвимостей в контрабанде HTTP-запросов.

• Отключите повторное использование внутренних подключений, чтобы каждый внутренний запрос отправлялся через отдельное сетевое подключение.
• Используйте HTTP / 2 для внутренних подключений, так как этот протокол предотвращает неоднозначность границ между запросами.
• Используйте одно и то же программное обеспечение веб-сервера для внешних и внутренних серверов, чтобы они согласовали границы между запросами.

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