Вы заметили бродячие хиты на своих веб-страницах, у которых нет параметров?

Question

У нас есть веб-приложение, которое передает параметры в URL вдоль линий этого:

www.example.com/ViewCustomer?customer=3945 

Разумно часто, мы видим попытки доступа просто:

www.example.com/ViewCustomer 

Или система регистрирует это как недействительные и отправляет обратно сообщение «Произошла ошибка, обратитесь в службу поддержки с номером номера трассировки XXX».

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

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

Неужели кто-нибудь еще испытал это? Иногда некоторые браузеры посылают эти виды хитроумных запросов?

Edit: Наши журналы показать это:

user-agent = Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648) 

Answer 1

Теперь я думаю, что это была ошибка tomcat getParameter() fails on POST with transfer-encoding: chunked.

Answer 2

ли ваши журналы содержат информацию о ссылающейся? Если имеется какая-либо информация, это может помочь определить ошибку. Если этого не произошло, это может указывать на попытку «редактирования URL». (Я не знаю, сколько SSL могло бы изменить любое из этого, по общему признанию.)

Браузеры иногда бывают prefetch links, но я не знаю, избавятся ли они от параметра - и маловероятно, чтобы они сделайте это для HTTPS.

У вас есть образец того, какие браузеры используются для этих запросов?

Answer 3

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

Answer 4

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

Answer 5

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

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

Answer 6

Я видел это с помощью веб-приложения, которое мы поддерживаем, - безвредный запрос GET для синего пользователя, уже зарегистрированного пользователя, разрушающего состояние на стороне сервера и приводящего к ошибке при последующем законном запросе POST.

Поскольку в нашем случае URL-адреса используют URL-переписывание, прикрепленное sessionid к URL-адресу, такие GET также иногда имеют старый sessionid.

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

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

Мы преодолели эту проблему, запретив запросы GET к рассматриваемому URI.

Однако теперь я имею дело с аналогичной проблемой, когда запрос POST появляется откуда бы то ни было, где это не должно быть, и единственное отличие заключается в заголовке «accept».