Подтвердить что ты не робот

Странный URL-адрес, содержащий "A = 0 или" 0 = A в журналах веб-сервера

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

...news.php?lang=EN&id=23'A=0

или

...news.php?lang=EN&id=23'0=A

вместо

...news.php?lang=EN&id=23

Я нашел только одну страницу, которая упоминала об этом (https://forums.adobe.com/thread/1973913), где они предположили, что дополнительная строка запроса поступает из GoogleBot или кодировки ошибка.

Недавно я изменил свои сайты, чтобы использовать PDO вместо mysql_*. Может быть, это изменение вызвало ошибки? Любые подсказки были бы полезны.


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

Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 (.NET CLR 3.5.30729)

Это привело меня к следующим темам: pt-BR а также Странный параметр в URL-адресе - что они пытаются?

4b9b3361

Ответ 1

так как это очень старая версия FireFox, я заблокировал ее в файле htaccess -

RewriteCond %{HTTP_USER_AGENT} Firefox/3\.5\.2 [NC]
RewriteRule .* err404.php  [R,L]

Ответ 2

Это бот-тестирование уязвимостей SQL-инъекций, закрывая запрос с апострофом, а затем устанавливая переменную. Существуют также аналогичные инъекции, которые имеют дело с командами оболочки и/или проходами по пути файла. Является ли это "хорошим ботом" или плохим ботом, неизвестно, но если инъекция работает, у вас больше проблем. Там 99% вероятность, что ваш сайт не создает эти ссылки стиля, и вы ничего не можете сделать, чтобы не дать им обработать эти URL-адреса, если вы не заблокируете запрос (-и) с помощью простой строки регулярного выражения или более сложного WAF, такого как ModSecurity.

Блокировка на основе пользовательского агента не является эффективным углом. Вам нужно искать эвристику запроса и блокировать на основе этого. Некоторые примеры вещей, которые нужно искать в url/request/POST/referrer, как и utf-8, так и шестнадцатеричные символы:

  • двойные апострофы
  • двойные периоды, за которыми следует слэш в различных кодировках
  • слова типа "script", "etc" или "passwd"
  • пути, такие как dev/null, используемые с выходом pipe/echoing shell
  • % 00 символов в стиле байт, используемых для инициализации новой команды
  • http в URL-адресе более одного раза (если ваш сайт не использует его)
  • что-либо относительно cgi (если только ваш сайт не использует его)
  • случайные "корпоративные" пути для таких вещей, как coldfusion, tomcat и т.д.

Если вы не используете WAF, вот коньяк регулярных выражений, который должен захватить многие из них в URL-адресе. Мы используем его в PHP-приложениях, поэтому вам может понадобиться/нужно будет настроить некоторые экраны/взгляды в зависимости от того, где вы используете это. Обратите внимание, что это имеет .cgi, wordpress и wp-admin вместе с кучей других вещей в регулярном выражении, удалите их, если вам нужно.

$invalid = "(\(\))"; // lets not look for quotes. [good]bots use them constantly. looking for () since technically parenthesis arent valid
$period = "(\\002e|%2e|%252e|%c0%2e|\.)";
$slash = "(\\2215|%2f|%252f|%5c|%255c|%c0%2f|%c0%af|\/|\\\)"; // http://security.stackexchange.com/info/48879/why-does-directory-traversal-attack-c0af-work
$routes = "(etc|dev|irj)" . $slash . "(passwds?|group|null|portal)|allow_url_include|auto_prepend_file|route_*=http";
$filetypes = $period . "+(sql|db|sqlite|log|ini|cgi|bak|rc|apk|pkg|deb|rpm|exe|msi|bak|old|cache|lock|autoload|gitignore|ht(access|passwds?)|cpanel_config|history|zip|bz2|tar|(t)?gz)";
$cgis = "cgi(-|_){0,1}(bin(-sdb)?|mod|sys)?";
$phps = "(changelog|version|license|command|xmlrpc|admin-ajax|wsdl|tmp|shell|stats|echo|(my)?sql|sample|modx|load-config|cron|wp-(up|tmp|sitemaps|sitemap(s)?|signup|settings|" . $period . "?config(uration|-sample|bak)?))" . $period . "php";
$doors = "(" . $cgis . $slash . "(common" . $period . "(cgi|php))|manager" . $slash . "html|stssys" . $period . "htm|((mysql|phpmy|db|my)admin|pma|sqlitemanager|sqlite|websql)" . $slash . "|(jmx|web)-console|bitrix|invoker|muieblackcat|w00tw00t|websql|xampp|cfide|wordpress|wp-admin|hnap1|tmunblock|soapcaller|zabbix|elfinder)";
$sqls = "((un)?hex\(|name_const\(|char\(|a=0)";
$nulls = "(%00|%2500)";
$truth = "(.{1,4})=\1"; // catch OR always-true (1=1) clauses via sql inject - not used atm, its too broad and may capture search=chowder (ch=ch) for example
$regex = "/$invalid|$period{1,2}$slash|$routes|$filetypes|$phps|$doors|$sqls|$nulls/i";

Использование этого, по крайней мере с PHP, довольно прямолинейно с preg_match_all(). Вот пример того, как вы можете его использовать: https://gist.github.com/dhaupin/605b35ca64ca0d061f05c4cf423521ab

ПРЕДУПРЕЖДЕНИЕ: Будьте внимательны, если вы установите для этого автобан (то есть фильтр fail2ban). MS/Bing DumbBots (и другие) часто забрасывают URL-адреса, внося такие вещи, как странные тройные точки, из следующих усеченных URL-адресов или пытаются попасть в ссылку tel: как URi. Я не знаю почему. Вот что я имею в виду: ссылка с текстом www.example.com/link-too-long...truncated.html может указывать на правильный URL-адрес, но Bing может попытаться получить к нему доступ "как он выглядит" вместо того, чтобы следовать за href, в результате чего WAF-хит из-за двойных точек.