Avez-vous remarqué des hits parasites sur vos pages Web sans paramètres?

Question

Nous avons une application Web qui transmet les paramètres dans l'url de la manière suivante:

www.example.com/ViewCustomer?customer=3945

Rarement souvent, nous verrons des tentatives d'accès uniquement:

www.example.com/ViewCustomer

Ou le système enregistre cette erreur comme non valide et renvoie un "Une erreur est survenue, contactez le support technique avec le numéro de trace XXX". type de page.

Nos journaux incluent les informations de session. Il s’agit donc d’une personne ayant ouvert une session avec une session valide, ce qui signifie qu’elle s’est connectée avec un nom d’utilisateur et un mot de passe.

Ils ont peut-être simplement tapé cela dans la barre d'adresse, mais cela semble se produire trop souvent pour cela. Une autre alternative est que nous avons un bug dans notre code, mais nous avons enquêté et parfois, il n’ya qu’un seul endroit et c’est tout à fait correct. Nous n'avons jamais eu un utilisateur se plaindre de quelque chose qui ne fonctionne pas et résultant en ceci. Tout est sous SSL.

Quelqu'un d'autre a-t-il vécu cela? Certains navigateurs envoient-ils parfois ce type de requêtes douteuses?

Modifier: Nos journaux montrent ceci:

 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

Je pense à présent qu'il s'agissait d'un bogue Tomcat getParameter () échoue lors du test POST. avec transfert-encodage: chunked .

Answer 2

Vos journaux incluent-ils les informations sur le référent? Si des informations sont présentes, cela pourrait aider à identifier l'erreur. Si ce n’est pas le cas, cela pourrait indiquer qu’une " édition de l’URL " tentative. (Certes, je ne sais pas dans quelle mesure SSL changerait cela.)

Les navigateurs font parfois des liens de pré-extraction , mais je ne sais pas s'ils s'en débarrasseraient du paramètre - et il semble peu probable qu'ils le fassent pour HTTPS.

Avez-vous une idée du type de navigateur utilisé pour ces requêtes?

Answer 3

J'ai vu cela avec l'application Web que nous prenons en charge - une requête GET errante hors du bleu pour un utilisateur déjà connecté, détruisant l'état côté serveur et entraînant une erreur lors de la requête POST légitime ultérieure.

Étant donné que dans notre cas, les URL utilisent un identificateur de session avec ré-écriture d'URL, ces GET ont parfois aussi un ancien identifiant de session.

Dans le fichier journal spécifique qui a conduit à résoudre ce problème, la chaîne de l'agent était différente de la requête de l'agent (bien que valide) par rapport au reste de la même session.

Je suis convaincu qu’au lieu du navigateur lui-même, c’est un plugin / une extension. Il est possible qu'un proxy le fasse ou même un malware.

Nous avons résolu ce problème en interdisant les requêtes GET à l'URI en question.

Cependant, je suis maintenant confronté à un problème similaire: une requête POST apparaît de nulle part là où il ne devrait pas, et la seule différence réside dans l'option "accepter". en-tête.

Answer 4

Recherchez dans votre journal la chaîne de l'agent et vérifiez si ces demandes sont effectuées par un moteur de recherche.

Answer 5

Je sais que je supprime parfois le paramètre simplement pour vérifier ce qui est là. Je suis sûr que je ne suis pas le seul.

Answer 6

Certains robots d'analyse non fiables modifient l'agent utilisateur en agent utilisateur et pages d'exploration du navigateur. Cela peut aussi être un tel cas.

De plus, la plupart des robots essaient de substituer d'autres valeurs aux paramètres de requête pour récupérer des pages non liées.