Parseable NGINX accesslog файлы с разделителями
Что происходит, когда Вы делаете, "объясните выбор * от заказов" запрос? и "выбирают количество () от заказов"? Объясните, что оператор должен дать Вам некоторое понимание в том, что происходит с Вашим запросом (это объясняет, как сервер выполнит его и помогает Вам диагностировать узкое место), и количество () сообщит, если 42 000 Вы упомянули, находится все еще в том диапазоне.
There is no problem.
I am afraid that people inject
"in either requests, referrers or user-agents.
" is represented as \x22
Request:
$ curl 'localhost/"?"="' --header 'User-Agent: "'
line in log:
[27/Mar/2014:16:14:42 +0400] localhost 127.0.0.1 "GET /\x22?\x22=\x22 HTTP/1.1" 200 "-" "\x22" "-" "/index.html"
UPDATE
From nginx changelog
Changes with nginx 1.1.6 17 Oct 2011
*) Change: now the 0x7F-0x1F characters are escaped as \xXX in an
access_log.
Changes with nginx 0.7.0 19 May 2008
*) Change: now the 0x00-0x1F, '"' and '\' characters are escaped as \xXX
in an access_log.
Thanks to Maxim Dounin.
Помните, что некоторые поля генерируются системой, поэтому они безопасны. Если вы убедитесь, что эти поля находятся слева, а взломанные - справа (http_user_agent должен быть в конце, а http_referer перед этим, запрос должен быть перед этим), вы можете гарантировать, что большая часть данных верна, и добавив больше разделителей для синтаксического анализатора (необязательный крайний справа), чем может существовать без вставки, тогда ваш синтаксический анализатор обнаружит записи, которые были подвергнуты вставке.
Также я возобновил использование символа табуляции в качестве разделителя, так как я полагаю, что если кто-то попытается вставить его в URL-адрес, он будет экранирован на% 09