Lote de 400 erros nos logs do Apache

Question

Temos dificuldade em depurar 400 erros em nosso site. Temos muitos erros assim:

10.0.0.1 - - [08/Oct/2018:14:28:07 +0200] 
"GET /les-news/palmares/detail/article/la-lettre-de-motivation-ideale-pour-une-demande-de-stage-5224/ 
HTTP/1.1" 400 131844 
"https://www.google.com/" 
"Mozilla/5.0 (Linux; Android 7.0; TECNO K7 Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.91 Mobile Safari/537.36"

Um usuário relatou o problema por e-mail e foi corrigido ao redefinir seus cookies em seu navegador para que outros cookies de redefinição não fossem suficientes (mas não podemos ter certeza de que foi feito corretamente).

A plataforma é complicada e controlada por um balanceador de carga F5 , dependendo do caminho a solicitação para encaminhar para diferentes servidores.

O que eu gostaria no início é ser capaz de reproduzir o erro, porque ao acessar a URL não temos nada e tudo funciona bem.

Percebemos que a maior parte do erro vem do Android / Chrome: cerca de 85% de todos os 400 erros.

Aqui está um registro completo:

timestamp   October 8th 2018, 16:26:52.000
version     1
 _id        BmQSVGYB5vF-Dw_g1gVi
 _index     f5_access-2018.10.08
 _score     - 
t _type     doc
t agent     Mozilla/5.0 (Linux; Android 8.1.0; MI 8 Build/OPM1.171019.026) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.91 Mobile Safari/537.36
client_ip   10.0.0.1
client_port     41,068
facility    local2
host        mydomain.fr
httpversion     1
id      2,503,307,391
length      0
logsource   mydomain.network.local
message     virtual=/Common/mydomain.fr_HTTP client_ip=10.0.0.1 client_port=41068 lb_server=10.153.161.12:80 host=mydomain.fr request_port=80 username= request="GET / HTTP/1.1" server_status=400 content_length=0 resp_time=23 user_agent="Mozilla/5.0 (Linux; Android 8.1.0; MI 8 Build/OPM1.171019.026) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.91 Mobile Safari/537.36" referer=http://mydomain.fr/article/100-millions-d-euros-sciences-po-lance-la-plus-grande-levee-de-fonds-de-son-histoire_095255b4-caef-11e8-896c-7d05c73a49da/ ID=2503307391 timestamp=2018-10-08T16:26:52+0200 pool=/Common/POOL_ETUDIANT_v2_nocache
pool        POOL_MYDOMAIN_v2_nocache
program     f5_access
referer     http://mydomain.fr/article/100-millions-d-euros-sciences-po-lance-la-plus-grande-levee-de-fonds-de-son-histoire_095255b4-caef-11e8-896c-7d05c73a49da/
request     /
request_port    80
server_ip   10.0.0.1
server_port     80
severity    Informational
status      400
stdstatus   4xx
stdvirtual  mydomain_fr_HTTP
tags        f5_access
time        23
timestamp   October 8th 2018, 16:26:52.000
type        f5_access
verb        GET
virtual     mydomain.fr_HTTP

    

Answer 1

Isso é provavelmente causado pelo cliente, não pelo servidor (bem, indiretamente, pode ser). Se não é apenas um URL mal formado (um que é bloqueado por 400 antes de ser capaz de acionar 404), em 99% dos casos isso é causado por

• cookies corrompidos (podem, por exemplo, ser causados por extensões)
• cookies bloqueados
• muitos cookies (alguns navegadores bloqueiam grandes quantidades de cookies)
• cliente tentando uma solicitação enganosa (presumo involuntariamente)

Se você quiser testar a suposição de cookie bloqueado, bloquear cookies no seu navegador e verificar se você recebe um erro 400, o resto é um pouco mais complicado, veja: link

Como você já disse que foi corrigido com a atualização dos cookies, presumo que esteja relacionado a cookies.

Editar:

Eu tenho outro ângulo: a solicitação foi sobre http (não criptografada) e inclui um referenciador com a solicitação GET que inclui a string "username". Isso faz com que os usuários que visitam o site com esse referenciador em seu cabeçalho sejam identificáveis, ainda mais, a solicitação pode ser visualizada por um homem no meio em texto não criptografado.

Desde que o Google iniciou uma espécie de guerra contra o tráfego http não criptografado, presumi que o Chrome causa alguns problemas. Esta é apenas uma suposição, porém, não posso confirmar isso ou fazer o backup. Mas vale a pena tentar desde que você deve criptografar seu tráfego anywas.

Você tem https configurado no seu servidor e, em caso afirmativo, você pode tentar reproduzir o mesmo erro ao usar https?