Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
подчёркивания в именах строк в заголовке запроса клиен та
On Wednesday, September 10, 2008 at 8:21:15, Igor Sysoev wrote:
>>> *) Добавление: теперь nginx разрешает подчёркивания в именах строк
>>> в заголовке запроса клиента.
>> BTW, в результате конструкция вида
>>
>> proxy_set_header X-Permit-Something "OK";
>>
>> (где OK или нет определяется скажем из ip-адреса клиента) с
>> последующей проверкой на бекенде в cgi-скрипте под Apache
>> как-нибудь вроде
>>
>> if ($ENV{HTTP_X_PERMIT_SOMETHING} eq 'OK') {
>> ...
>> }
>>
>> становится небезопасной, т.к. клиент может передать заголовок
>> X_Permit_Something ('_' вместо '-'), этот заголовок не будет убран
>> nginx'ом из запроса и в запросе к Apache будет стоять после
>> заголовка X-Permit-Something, добавленного nginx'ом.
>> Apache в свою очередь в переменную окружения HTTP_X_PERMIT_SOMETHING
>> поместит именно последний пришедший в запросе заголовок (т.е. заголовок от
>> клиента).
IS> Хуже того. Можно послать X_Real_IP. В общем, именно из-за таких
IS> неоднозначностей я и не хотел долгое время разрешать подчёркивание
IS> в заголовках, которое позволяется RFCом.
а ведь можно сделать так, чтобы поля заголовков никогда не перекрывались.
например, символ '_' полученный в запросе клиента транслировать в '__'.
тогда поле X_Permit_Something превратится в HTTP_X__PERMIT__SOMETHING
если backend неизменяем и ожидает переменную HTTP_X_PERMIT_SOMETHING
для таких случаев администратор может вручную сделать переопределение:
proxy_set_header X-Permit-Something $X__Permit__Something;
и на backend`е будет получена переменная HTTP_X_PERMIT_SOMETHING
из поля клиентского запроса X_Permit_Something, что и требовалось.
при этом backend`ы будут надежно защищены от возможных фальсификаций.
--
Best regards,
Gena
|
