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

Question

У нас есть веб-приложение, которое передает параметры в URL по следующим направлениям:

www.example.com/ViewCustomer?customer=3945

Довольно часто мы увидим попытки получить доступ только к:

www.example.com/ViewCustomer

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

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

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

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

Редактировать: Наши журналы показывают это:

 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

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

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

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

Answer 2

Теперь я думаю, что это на самом деле ошибка tomcat getParameter () завершается с ошибкой на POST с кодировкой передачи: chunked .

Answer 3

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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