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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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