Re: Ограничение доступа по аргументу в query string

[Maxim Dounin]

Hello!

On Thu, May 25, 2017 at 05:17:22PM -0700, Станислав wrote:

> Привет,
> 
> Появилась такая задача - если от клиента в query string присутствует 
> аргумент "controller", nginx должен что-то делать (например разрывать 
> соединение). Было сделано такое:
> 
> if ($arg_controller) {
>        return 444 ;
> }
> 
> Работало, нашли как это можно обойти: curl -s -L -D - 
> http://localhost/testme.php?controller=&controller=heresmysecretkeyword
> 
> Nginx не будет делать "return 444" так как аргумент controller пустой 
> (не определен), второй аргумент с таким же именем nginx игнорирует. 
> Данные передаются бэкэнду таким способом:
> 
> location = /testme.php {
> .....
>      fastcgi_param QUERY_STRING controller=$secret_var&$args;
> .....
> }
> 
> Где $args приобретает форму: controller=&controller=heresmysecretkeyword
> 
> Бэкэнд перезаписывает аргумент последним аргументом в query string, и в 
> код интерпретируемым бэкэндом передается heresmysecretkeyword .
> 
> Сталкивался кто-то с такой ситуацией? Как можно это пофиксить если нет 
> возможности трогать сам бэкэнд. Пока только в голову приходит проверять 
> регулярным выражением $args на присутствие нежелаемого аргумента. Не 
> очень хочу юзать тут regex :/

Лучше всего - на пытаться завязывать безопасность на аргументы 
запроса, тем более - на их разбор nginx'ом через переменные 
$arg_*.  Разбор аргументов запроса не стандартизирован, и это 
может много где выйти боком: как в вашем случае по разному может 
обрабатываться случай нескольких аргументов, или же бекенд может 
понимать более одного разделителя (скажем, php обычно поддерживает 
не только "&", но и ";"), и так далее.

Если очень надо - выясняйте подробности обработки аргументов 
бекендом и фильтруйте по $args.  Но, как уже сказано выше, лучше 
всего вообще не пытаться этого делать.

-- 
Maxim Dounin
http://nginx.org/